Miner fees

Transaction fees are a fee that spenders may include in any Bitcoin transaction. The fee may be collected by the miner who includes the transaction in a block.

Overview

Every Bitcoin transaction spends zero or more bitcoins to zero or more recipients. The difference between the amount being spent and the amount being received is the transaction fee (which must be zero or more).

Bitcoin's design makes it easy and efficient for the spender to specify how much fee to pay, whereas it would be harder and less efficient for the recipient to specify the fee, so by custom the spender is almost always solely responsible for paying all necessary Bitcoin transaction fees.

When a miner creates a block proposal, the miner is entitled to specify where all the fees paid by the transactions in that block proposal should be sent. If the proposal results in a valid block that becomes a part of the best block chain, the fee income will be sent to the specified recipient. If a valid block does not collect all available fees, the amount not collected are permanently destroyed; this has happened on more than 1,000 occasions from 2011 to 2017, with decreasing frequency over time.

The market for block space

Receiving the fees from hundreds of transactions (0.44 BTC)

Transaction fees are voluntary on the part of the person making the bitcoin transaction, as the person attempting to make a transaction can include any fee or none at all in the transaction. On the other hand, nobody mining new bitcoins necessarily needs to accept the transactions and include them in the new block being created. The transaction fee is therefore an incentive on the part of the bitcoin transactor to make sure that a particular transaction will get included into a block.

It is envisioned that over time the cumulative effect of collecting transaction fees will allow somebody creating new blocks to "earn" more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks as the creation of new bitcoins from the mining activity goes towards zero in the future.

Because of deep technical reasons, bitcoin block space is a scarce commodity, getting a transaction mined can be seen as purchasing a portion of it. The price of block space is set by supply and demand, although in the real world the supply of space for transactions is extremely noisy, because more becomes available (and has to be immediately consumed or it’s lost forever) every time a block is mined, and block mined is an intentionally random process, that randomness being essential for bitcoin's operation. Demand is random and cyclical. Random because each transaction is generated individually so the total amount is noisy (although that averages out to be somewhat smooth at scale) and has both daily and weekly cycles, with more transactions done during the day than at night. Demand can also be affected by speculative movements in the exchange rate.

Therefore the market for block space asks users to make a tradeoff between confirmation time and cost. Users with high time requirements may pay a higher than average miner fee to be confirmed quickly, while more users under less time pressure can save money by being prepared to wait longer.

Feerates

Perhaps the most important factor affecting how fast a transaction gets confirmed is its fee rate (often spelled feerate). This section describes why feerates are important and how to calculate a transaction's feerate.

Bitcoin transaction vary in size for a variety of reasons. We can easily visualize that by drawing four transactions side-by-side based on their size (length) with each of our examples larger than the previous one:

This method of illustrating length maxes it easy to also visualize an example maximum block size limit that constrains how much transaction data a miner can add to an individual block:

Since Bitcoin only allows whole transactions to be added to a particular block, at least one of the transactions in the example above can't be added to the next block. So how does a miner select which transactions to include? There's no required selection method (called policy) and no known way to make any particular policy required, but one strategy popular among miners is for each individual miner to attempt to maximize the amount of fee income they can collect from the transactions they include in their blocks.

We can add a visualization of available fees to our previous illustration by keeping the length of each transaction the same but making the area of the transaction equal to its fee. This makes the height of each transaction equal to the fee divided by the size, which is called the feerate:

Although long (wide) transactions may contain more total fee, the high-feerate (tall) transactions are the most profitable to mine because their area is greatest compared to the amount of space (length) they take up in a block. For example, compare transaction B to transaction D in the illustration above. This means that miners attempting to maximize fee income can get good results by simply sorting by feerate and including as many transactions as possible in a block:

Because only complete transactions can be added to a block, sometimes (as in the example above) the inability to include the incomplete transaction near the end of the block frees up space for one or more smaller and lower-feerate transactions, so when a block gets near full, a profit-maximizing miner will often ignore all remaining transactions that are too large to fit and include the smaller transactions that do fit (still in highest-feerate order):

Excluding some rare and rarely-significant edge cases, the feerate sorting described above maximizes miner revenue for any given block size as long as none of the transactions depend on any of the other transactions being included in the same block.

To calculate the feerate for your transaction, take the fee the transaction pays and divide that by the size of the transaction (currently based on weight units or vbytes but no longer based on bytes). For example, if a transaction pays a fee of 2,250 nanobitcoins and is 225 vbytes in size, its feerate is 2,250 divided by 225, which is 10 nanobitcoins per vbyte (this happens to be the minimum fee Bitcoin Core Wallet will pay by default).

When comparing to the feerate between several transactions, ensure that the units used for all of the measurements are the same. For example, some tools calculate size in weight units and others use vbytes; some tools also display fees in a variety of denominations.

Reference Implementation

The following sections describe the behavior of the reference implementation as of version 0.12.0. Earlier versions treated fees differently, as do other popular implementations (including possible later versions).

Sending

Users can decide to pay a predefined fee rate by setting `-paytxfee=<n>` (or `settxfee <n>` rpc during runtime). A value of `n=0` signals Bitcoin Core to use floating fees. By default, Bitcoin Core will use floating fees.

Based on past transaction data, floating fees approximate the fees required to get into the `m`th block from now. This is configurable with `-txconfirmtarget=<m>` (default: `2`).

Sometimes, it is not possible to give good estimates, or an estimate at all. Therefore, a fallback value can be set with `-fallbackfee=<f>` (default: `0.0002` BTC/kB).

At all times, Bitcoin Core will cap fees at `-maxtxfee=<x>` (default: 0.10) BTC. Furthermore, Bitcoin Core will never create transactions smaller than the current minimum relay fee. Finally, a user can set the minimum fee rate for all transactions with `-mintxfee=<i>`, which defaults to 1000 satoshis per kB.

Note that a typical transaction is 500 bytes.

Including in Blocks

This section describes how the reference implementation selects which transactions to put into new blocks, with default settings. All of the settings may be changed if a miner wants to create larger or smaller blocks containing more or fewer free transactions.

Then transactions that pay a fee of at least 0.00001 BTC/kb are added to the block, highest-fee-per-kilobyte transactions first, until the block is not more than 750,000 bytes big.

The remaining transactions remain in the miner's "memory pool", and may be included in later blocks if their priority or fee is large enough.

For Bitcoin Core 0.12.0 zero bytes in the block are set aside for the highest-priority transactions. Transactions are added highest-priority-first to this section of the block.

Relaying

The reference implementation's rules for relaying transactions across the peer-to-peer network are very similar to the rules for sending transactions, as a value of 0.00001 BTC is used to determine whether or not a transaction is considered "Free". However, the rule that all outputs must be 0.01 BTC or larger does not apply. To prevent "penny-flooding" denial-of-service attacks on the network, the reference implementation caps the number of free transactions it will relay to other nodes to (by default) 15 thousand bytes per minute.

Settings

Setting	Default Value (units)
txconfirmtarget	2 (blocks)
paytxfee	0 (BTC/kB)
mintxfee	0.00001 (BTC/kB)
limitfreerelay	15 (thousand bytes per minute)
minrelaytxfee	0.00001 (BTC/kB)
blockmaxsize	750000 (bytes)
blockminsize	0 (bytes)
blockprioritysize	0 (bytes)

Fee Plotting Sites

As of May 2016, the following sites seem to plot the required fee, in satoshi per (kilo)byte, required to get a transaction mined in a certain number of blocks. Note that all these algorithms work in terms of probabilities.

• https://bitcoinfees.21.co/
• https://bitcoinfees.github.io/
• https://statoshi.info/dashboard/db/fee-estimates
• http://p2sh.info/dashboard/db/fee-estimation
• https://www.bitcoinqueue.com/2d.html

Other Useful Sites

• https://anduck.net/bitcoin/fees/ - Shows what kind of fees filled up recent blocks
• https://btc.com/stats/unconfirmed-tx - the state of the website's mempool broken down by fee rate
• https://jochen-hoenicke.de/queue/#1w - another mempool broken down by fee rate site
• https://esotericnonsense.com/ - yet another mempool site, also very good
• http://mempool.us.to/tx.html - Tells you where a unconfirmed txid is in the queue based on its fee rate (Note that not all miners use the same algorithm)
• https://estimatefee.com/ - You can click any of the transactions in that graph to get more info (like its "effective fee rate" which uses recursive ancestors/descendants for CPFP) and an estimated amount of blocks it'll take to confirm. It works with any transaction in the top 100MB of the bitcoin mempool. And you can enter in any transaction txid for info when you'er wondering why it doesn't confirm.

Priority transactions

Historically it was not required to include a fee for every transaction. A large portion of miners would mine transactions with no fee given that they had enough "priority". Today, low priority is mostly used as an indicator for spam transactions and almost all miners expect every transaction to include a fee. Today miners choose which transactions to mine only based on fee-rate.

Transaction priority was calculated as a value-weighted sum of input age, divided by transaction size in bytes:

priority = sum(input_value_in_base_units * input_age)/size_in_bytes

Transactions needed to have a priority above 57,600,000 to avoid the enforced limit (as of client version 0.3.21). This threshold was written in the code as COIN * 144 / 250, suggesting that the threshold represents a one day old, 1 btc coin (144 is the expected number of blocks per day) and a transaction size of 250 bytes.

So, for example, a transaction that has 2 inputs, one of 5 btc with 10 confirmations, and one of 2 btc with 3 confirmations, and has a size of 500bytes, will have a priority of

(500000000 * 10 + 200000000 * 3) / 500 = 11,200,000

Historic rules for free transactions

A transaction was safe to send without fees if these conditions were met:

• It is smaller than 1,000 bytes.
• All outputs are 0.01 BTC or larger.
• Its priority is large enough (see above)

See Also

• Free transaction relay policy
• Unconfirmed transactions fee chart
• historic fees and mempools