A competitive fee must be added to every Bitcoin transaction. Failure to do so can result in loss of time, money, or both. But overpayment can also cost you money. Fees may seem irrational or unnecessarily complex. This article breaks fees down in detail, and includes a discussion of how using segwit can reduce fees.

Fees Gone Wild

Bitcoin fees can be counterintuitive. Consider two examples based on reports from actual users.

Alice, a successful blogger, displays a QR code to accept Bitcoin donations (this is a bad idea from the perspective of privacy). Once every month, she sweeps the accumulated funds into her Electrum wallet. She usually pays a fee amounting to 1.5% of the balance. One month, Alice receives hundreds of small donations, an unusually high number. Unlike previous monthly transfers, this one requires a fee of 90% even though the balance was no different from the others.

Bob is a sporadic Bitcoin user who has watched fees rise since 2016. Although he has increased the amount he pays in fees, he doesn’t know how to calculate an acceptable fee. While browsing Overstock one day, Bob notices a limited-time 50% discount on quality bedsheets. A payment Bob made last week went without a hitch, but today Bob’s payment becomes stuck. He misses the deal and eventually needs to ask for a refund after the transaction finally does confirm.

Although the root cause in both cases may differ, the outcome is the same. A user who has come to expect one behavior from Bitcoin sees the opposite for no apparent reason. The root cause in both cases is lack of understanding around fees.

Basis

Bitcoin transaction fees work differently from fees charged by banks. A bank levies fees based on the amount of currency being transacted. The Bitcoin network, in contrast, levies fees based on the amount of data being published.

A transaction fee depends on two factors: the size (length in bytes) of the transaction; and the prevailing fee density. Fee density (sometimes referred to as “fee rate” or “feerate”) is a floating value that rises and falls in response to network transaction volume. A fee density is usually expressed in terms of the number of satoshis required per byte of transaction data (satoshis/byte).

Because the size of a transaction reflects its internal structure, fee estimation requires some knowledge of how transactions work, at least at a high level. Automatic fee assignment by wallets has come a long way, but the state-of-the-art is still catching up to market realities. Users wanting to avoid losses may need to estimate fees manually as a sanity check.

Transactions

A transaction is a message that transfers ownership of one or more digital coins. Each coin to be spent appears as a transaction input. An input references the single coin it spends, and provides a response to an authentication challenge. A new coin to be created by a transaction appears as an output. An output defines a face value for the new coin, and sets up an authentication challenge. In most transactions, the authentication challenge consists of one or more digital signatures, but other challenges may also be used. To better conceptualize transactions, a visual language can be used.

Count and length fields vary in length due to a space-saving technique known as variable length integers. A variable length integer requires more space as the value to be encoded increases. A value less than or equal to 253 (0xfd) encodes a value as a single byte. A first value of 253 signals that the next two bytes contain the length, which may take any value from zero to 65,535 (0xffff). Likewise, a first byte of 254 (0xfe) signals that the next four bytes contain the length (up to 0xffffffff). Finally, a first byte of 255 (0xff) signals that the next eight bytes encode the value.

Base Transaction Fields. Counts and lengths vary in length to accommodate large values, but rarely exceed one byte.

Name	Length (bytes)	Description
Version	4	The transaction format version. Currently 2.
Input Count	1-9	The number of inputs.
Outpoint	36	The parent transaction’s ID concatenated with the output’s zero-based index.
Input Script Length	1-9	The length of the input script, in bytes.
Input Script	variable	The authentication response for the output to be spent.
Sequence	4	Used with time locks.
Output Count	1-9	The number of outputs. Larger counts require more bytes.
Value	8	The face value of the output, in satoshis.
Output Script Length	1-9	The length of the output script, in bytes.
Output Script	variable	The authentication challenge for the new coin.
Lock Time	4	A timestamp or block index past which the transaction becomes valid.

Fortunately, most variable length integers used in transactions require only one byte. This rule of thumb can be used to simplify the estimation of transaction size.

Estimating Transaction Size

The preceding table and figure make it clear that even before inputs and outputs are added, a transaction will have a fixed overhead size. To determine that size, we add four values: the lengths of the version and lock time fields (4 bytes each); and the minimum lengths of the input and output counts (one byte each). This yields a 10 byte overhead. To remain consistent with current documentation, the number of bytes required to encode a transaction is referred to here as “size.” However, the more precise term “length” will be used here to refer to the data requirements of individual members.

The most common type of transaction uses an authorization template known as pay-to-public-key-hash (P2PKH). P2PKH uses the hash value of a public key as a challenge (output script), and requires a signature consistent with the hash value as a response (input script). As the name suggests, a script is a short program. The language, Script, was created by Satoshi Nakamoto specifically for Bitcoin.

A Script is composed of two kinds of elements: values and opcodes. A value is a piece of data, and will be identified here by wrapping it in angle brackets. Preceding each data element is an implicit length, encoded as a variable length integer. As with transaction fields, the majority of variable length integers require one byte of storage. An opcode performs work of some kind. Each opcode is represented by a single byte, and begins with the prefix OP_. A script interacts with a stack. A stack works like a deck of playing cards. Values are pushed onto and popped from the stack by opcodes.

A P2PKH input script contains two values that require on average 107 bytes. Variability results from the method used to encode signatures.

P2PKH Input Script. Values require an additional variable length integer as a length specifier. Signature lengths vary due to DER encoding. The total length for this input script is 107±1 bytes.

Name	Length (bytes)	Description
<signature>	72±1 + 1	Transaction signature.
<pubkey>	33 + 1	An uncompressed public key would require 65 + 1 bytes.

A P2PKH output script encodes four opcodes (one byte each) and a 20-byte value (requiring 21 bytes total). The result requires 25 bytes.

P2PKH Output Script. Opcodes require one byte and values require. The total length is 25 bytes.

Name	Length (bytes)	Description
OP_DUP	1	Duplicate the top stack item.
OP_HASH160	1	Pop value, push its hash value.
<pubkeyhash>	20 + 1	Push the hash value of a public key.
OP_EQUALVERIFY	1	Pop two items, verify their equality.
OP_CHECKSIG	1	Check transaction signature using the contents of the stack.

Combining these length requirements yields a formula that can compute the size (s) of any P2PKH transaction:

s = 10 + 148×n + 34×t, ±n

where n is the number of inputs and t is the number of outputs. The input contribution accounts for outpoint (36 bytes) script length (1 byte), script (107 bytes), and sequence (4 bytes). The output contribution accounts for the value field (8 bytes), script length (1 byte), and script (25 bytes).

For example, a one-input, one-output transaction would require on average 193 bytes (10 + 148 + 35). A more realistic one-input, two-output transaction that allowed the collection of change would require on average 226 bytes (10 + 148 + 2×34). A six-input, six-output CoinJoin transaction would require on average 1,102 bytes (10 + 6×148 + 6×34), and so on.

Segregated Witness

The above calculation applies to base transactions, or what has until recently just been known as a “transaction.” Segregated Witness (“segwit”) introduced a new witness transaction format moves the response script from the input into a witness.

A witness is an ordered list of witness fields. A witness field is composed of an item count and list of items. Each input at a particular index draws its data from the witness field at the same index in the witness. A witness field plays a role that is comparable, but not identical to that played by the input script.

Witness Transaction Fields. Counts and lengths vary in length to accommodate large values, but rarely exceed one byte.

Name	Length (bytes)	Description
Version	4	The transaction format version. Currently 2.
Marker	1	Makes witness transactions distinguishable from base transactions.
Flag	1	Reserved for future upgrades.
Input Count	1-9	The number of inputs.
Outpoint	36	The parent transaction’s ID concatenated with the output’s zero-based index.
Input Script Length	1	The script length is zero, but this zero must still be captured.
Sequence	4	Used with time locks.
Output Count	1-9	The number of outputs. Larger counts require more bytes.
Value	8	The face value of the output, in satoshis.
Output Script Length	1-9	The length of the output script, in bytes.
Output Script	variable	The authentication challenge for the new coin.
Witness Field Item Count	1-9	The length of the witness field.
Witness Field Item	variable	Data to be used during the authentication response.
Lock Time	4	A timestamp or block index past which the transaction becomes valid.

The cost of publishing a witness transaction depends, not on size, but virtual size. Virtual size (v) is computed as follows. Add three times the size of the corresponding base transaction (s) to the size of the witness transaction (w). Divide the result by four and round up to the nearest one to obtain the virtual size.

v = (3×s + w)/4

This formula is backward-compatible with base transactions. For example, a one-input, one-output base transaction has a size of 193 bytes. Its size as a witness transaction is identical. Using the formula above yields a virtual size of 193 bytes ((3×193 + 193)/4).

As with base transactions, we can compute the overhead of a witness transaction. Adding the lengths of the version (four bytes), marker (one byte), flag (one byte), input/output counts (one byte each), and lock time (four bytes) fields gives 12 bytes.

P2WPKH Output Script. The complete script require 23 bytes.

Name	Length (bytes)	Description
<version>	1 + 1	The version for the witness program.
<witness program>	20 + 1	Used together with witness data.

Each P2WPKH output script holds 23 bytes of data (a version and “witness program”). The input script is blank, but still requires a one-byte length field set to zero.

A P2WPKH witness encodes 107 bytes (±1) of data comprised of two values: a signature and a public key.

P2WPKH Witness. The complete script requires 107 bytes.

Name	Length (bytes)	Description
<signature>	72±1 + 1	Transaction signature.
<public key>	33 + 1	An uncompressed public key would require 65 + 1 bytes.

Combining these requirements yields a formula for computing the weight of a witness transaction (w):

w = 12 + 149×n + 32×t

where n is the input count and t is the output count. The overhead accounts for the version (4 bytes), marker and flag (one byte each), input/output counts (one byte each), and lock time (4 bytes). The input multiplier accounts for the outpoint (36 bytes), dummy script length (one byte), and sequence (four bytes). The input multiplier further accounts for the witness field item count (one byte per input), signature (73 bytes per input), and public key (34 bytes per input). The output multiplier accounts for the value (8 bytes), script length (one byte), and script (23 bytes).

The size of a witness transaction (s) is equal to weight without the marker, flag, or witness. This yields the following formula:

s = 10 + 41×n + 32×t

Combining this defintion for size (s) with the one for weight (w) yields the following estimate for the virtual size of a P2WPKH transaction:

v = (42 + 272×n + 128×t)/4

For example, a one-input, one-output P2WPKH transaction would have a virtual size of 111 bytes. This represents a savings of 42% over the corresponding P2PKH transaction (193 bytes).

Fee Density

Computing transaction size is the first step toward finding the appropriate fee. In the next step, the market fee density is found. Fee density (d) is the transaction fee f (in satoshis) divided by its virtual size v (in bytes).

d = f/v

For example, a 1 KB transaction carrying a 1,000 satoshi fee would have a fee density of 1 satoshi/byte (1,000 satoshis/1,000 bytes). A 250 byte transaction carrying a 500 satoshi fee would have a fee density of two satoshis/byte, and so on.

Each node on the P2P network sets its own policies on fees. However, the most common implementation sorts pending transactions in reverse order of fee density. Enough transactions are pulled from the memory pool to create a full block. When the memory pool grows too large, transactions are evicted starting from the bottom of the list.

In aggregate, this behavior creates a block space market. In a block space market, transactions compete on the basis of fee density for inclusion in the next block. They also compete for propagation through the network on the same basis. A user interested in next-block confirmation uses a high enough fee density to outcompete all other pending transactions for confirmation and propagation. A user who can wait uses a lower fee density.

Transaction Fee

Given a market fee density (d) and transaction virtual size (v), an appropriate transaction fee (f) can be computed as:

f = d×v

To find the fee for any transaction, multiply its virtual size in bytes by the market fee density in satoshis/byte.

Minimizing Transaction Fees

The transaction fee that must be paid at any given moment is proportional to two terms: the virtual size of the transaction in bytes; and the market fee density. To reduce fees, reduce one term or the other.

The most efficient way to reduce transaction virtual size is to reduce the number of inputs. Each non-witness input costs 148×d satoshis, where d is the prevailing fee density. By comparison, non-witness outputs only cost 34×d each.

Most wallets don’t allow users to select the inputs they spend. Lack of this feature, known as coin control, poses a problem for any user trying minimize fees and who has several outputs to spend. The best solution in this case is to use a wallet that supports coin control. Examples include Bitcoin Core and Electrum.

Fees can also be reduced by publishing transactions at times of low volume. Saturdays and Sundays have in the past seen market fee densities drop by 50% or more compared to the preceding weekdays.

For those planning on paying the lowest fee possible, an estimator is essential. The one used by Bitcoin Core is the most advanced. Given a desired confirmation window and size, it will compute an appropriate fee using an algorithm that takes fees paid by pending and confirmed transactions into account. The Bitcoin Core fee estimator is available through a Web browser at estimatefee.com.

Conclusions

The fee required for a transaction depends on two factors: the transaction’s size, and the market fee density. Reducing either value reduces the fee. To reduce size, eliminate inputs or use witness transactions. To minimize fee density, publish transactions during off-peak times whenever possible. With the information presented here and a good wallet, it should be possible to estimate the fee for any transaction before signing it.