Miner fees - Revision history

Theymos: remove fujn spam

2025-02-22T18:37:28Z

remove fujn spam

← Older revision		Revision as of 18:37, 22 February 2025
Line 151:		Line 151:
	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.		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<ref>https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/release-notes.md#relay-and-mining-priority-transactions</ref> in the block are set aside for the highest-[[Transaction_fees#Priority_transactions\|priority transactions]]. Transactions are added highest-priority-first to this section of the block~~. Users seeking faster confirmation of priority transactions can utilize a [https://fujn.com btc accelerator], which offers free Bitcoin transaction acceleration~~.		For Bitcoin Core 0.12.0, zero bytes<ref>https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/release-notes.md#relay-and-mining-priority-transactions</ref> in the block are set aside for the highest-[[Transaction_fees#Priority_transactions\|priority transactions]]. Transactions are added highest-priority-first to this section of the block.

WikiR: Removed multiple broken links (404 - expired domains)

2025-02-22T13:30:28Z

Removed multiple broken links (404 - expired domains)

← Older revision		Revision as of 13:30, 22 February 2025
Line 151:		Line 151:
	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.		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<ref>https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/release-notes.md#relay-and-mining-priority-transactions</ref> in the block are set aside for the highest-[[Transaction_fees#Priority_transactions\|priority transactions]]. Transactions are added highest-priority-first to this section of the block.		For Bitcoin Core 0.12.0, zero bytes<ref>https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/release-notes.md#relay-and-mining-priority-transactions</ref> in the block are set aside for the highest-[[Transaction_fees#Priority_transactions\|priority transactions]]. Transactions are added highest-priority-first to this section of the block. Users seeking faster confirmation of priority transactions can utilize a [https://fujn.com btc accelerator], which offers free Bitcoin transaction acceleration.


	===Relaying===		===Relaying===
Line 184:		Line 185:
	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.		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
	* https://bitcoinfees.net/		* https://bitcoinfees.net/

Line 194:		Line 190:

	* https://anduck.net/bitcoin/fees/ - Shows what kind of fees filled up recent blocks		* 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://jochen-hoenicke.de/queue/#1w - another mempool broken down by fee rate site
	* https://esotericnonsense.com/ - yet another mempool site, also very good		* https://esotericnonsense.com/ - yet another mempool site, also very good
Line 225:		Line 220:
	* [[Fee bumping]]		* [[Fee bumping]]
	* [[Replace by fee]]		* [[Replace by fee]]
	* [~~http~~://bitcoinexchangerate.org/fees Unconfirmed transactions fee chart]		* [https://bitcoinexchangerate.org/fees Unconfirmed transactions fee chart]
	* [https://jochen-hoenicke.de/queue/ historic fees and mempools]		* [https://jochen-hoenicke.de/queue/ historic fees and mempools]

AllEd01: spelling and grammar

2022-09-26T08:46:46Z

spelling and grammar

Belcher: /* Fee Plotting Sites */ Added whatthefee.io

2020-08-19T10:55:32Z

Fee Plotting Sites: Added whatthefee.io

← Older revision		Revision as of 10:55, 19 August 2020
Line 199:		Line 199:
	* 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.		* 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.
	* https://mempool.space/ - Shows how the next few blocks are shaping up and the range of fees per block. Helps estimate the low end fee to use to get into the next block.		* https://mempool.space/ - Shows how the next few blocks are shaping up and the range of fees per block. Helps estimate the low end fee to use to get into the next block.
			* https://whatthefee.io/ - Shows the probability of a particular fee rate being confirmed within a particular timeframe.

	==Priority transactions==		==Priority transactions==

Belcher: /* Other Useful Sites */ Remove broken link

2020-07-26T11:27:51Z

Other Useful Sites: Remove broken link

← Older revision		Revision as of 11:27, 26 July 2020
Line 197:		Line 197:
	* https://jochen-hoenicke.de/queue/#1w - another mempool broken down by fee rate site		* https://jochen-hoenicke.de/queue/#1w - another mempool broken down by fee rate site
	* https://esotericnonsense.com/ - yet another mempool site, also very good		* 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.		* 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.
	* https://mempool.space/ - Shows how the next few blocks are shaping up and the range of fees per block. Helps estimate the low end fee to use to get into the next block.		* https://mempool.space/ - Shows how the next few blocks are shaping up and the range of fees per block. Helps estimate the low end fee to use to get into the next block.

Schmidty: minor spelling change

2019-04-30T19:49:35Z

minor spelling change

← Older revision		Revision as of 19:49, 30 April 2019
Line 43:		Line 43:
	[[File:Feerate1.png\|400px\|center]]		[[File:Feerate1.png\|400px\|center]]

	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:		This method of illustrating length makes 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:

	[[File:Feerate2.png\|400px\|center]]		[[File:Feerate2.png\|400px\|center]]

Belcher: /* Other Useful Sites */ Added mempool.space

2019-04-10T10:21:29Z

Other Useful Sites: Added mempool.space

← Older revision		Revision as of 10:21, 10 April 2019
Line 199:		Line 199:
	* 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)		* 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.		* 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.
			* https://mempool.space/ - Shows how the next few blocks are shaping up and the range of fees per block. Helps estimate the low end fee to use to get into the next block.

	==Priority transactions==		==Priority transactions==

Peername: /* Fee Plotting Sites */

2018-11-27T10:05:57Z

Fee Plotting Sites

← Older revision		Revision as of 10:05, 27 November 2018
Line 189:		Line 189:
	* http://p2sh.info/dashboard/db/fee-estimation		* http://p2sh.info/dashboard/db/fee-estimation
	* https://www.bitcoinqueue.com/2d.html		* https://www.bitcoinqueue.com/2d.html
			* https://bitcoinfees.net/

	=== Other Useful Sites ===		=== Other Useful Sites ===

Belcher: Add link to Techniques to reduce transaction fees page

2018-11-25T23:15:42Z

Add link to Techniques to reduce transaction fees page

← Older revision		Revision as of 23:15, 25 November 2018
Line 219:		Line 219:
	==See Also==		==See Also==

			* [[Techniques to reduce transaction fees]]
	* [[Free transaction relay policy]]		* [[Free transaction relay policy]]
	* [[Fee bumping]]		* [[Fee bumping]]

Belcher: Rename and emphasis the on-chainness of the fees

2018-11-24T18:35:59Z

Rename and emphasis the on-chainness of the fees

← Older revision		Revision as of 18:35, 24 November 2018
Line 1:		Line 1:
	'''~~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]].		'''Miner fees''' are a fee that spenders may include in any Bitcoin on-chain [[transaction]]. The fee may be collected by the miner who includes the [[transaction]] in a [[block]].

	== Overview ==		== Overview ==

← Older revision		Revision as of 08:46, 26 September 2022
Line 7:		Line 7:
	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.		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,<ref>[https://medium.com/@alcio/how-to-destroy-bitcoins-255bb6f2142e How to Destroy Bitcoins] by Antoine Le Calvez, Medium.com, retrieved 2018-01-03</ref><ref>[https://twitter.com/random_walker/status/948590112576868354 "Looks like back in 2012, when tx fees started becoming common, some miners were claiming the standard 50 BTC and leaving all tx fees unclaimed."], Arvind Narayanan, Twitter.com, posted 2018-01-03, retrieved 2018-01-03</ref> with decreasing frequency over time.		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 is permanently destroyed; this has happened on more than 1,000 occasions from 2011 to 2017,<ref>[https://medium.com/@alcio/how-to-destroy-bitcoins-255bb6f2142e How to Destroy Bitcoins] by Antoine Le Calvez, Medium.com, retrieved 2018-01-03</ref><ref>[https://twitter.com/random_walker/status/948590112576868354 "Looks like back in 2012, when tx fees started becoming common, some miners were claiming the standard 50 BTC and leaving all tx fees unclaimed."], Arvind Narayanan, Twitter.com, posted 2018-01-03, retrieved 2018-01-03</ref> with decreasing frequency over time.


Line 16:		Line 16:
	The minimum fee necessary for a transaction to confirm varies over time and arises from the intersection of supply and demand in Bitcoin's free market for block space.<ref>[https://medium.com/@bramcohen/how-wallets-can-handle-transaction-fees-ff5d020d14fb Bram Cohen blog post with helpful background to the market for block space]</ref> On the supply size, Bitcoin has a [[maximum block size]] (currently one million vbytes) that limits the maximum amount of transaction data that can be added to a block.		The minimum fee necessary for a transaction to confirm varies over time and arises from the intersection of supply and demand in Bitcoin's free market for block space.<ref>[https://medium.com/@bramcohen/how-wallets-can-handle-transaction-fees-ff5d020d14fb Bram Cohen blog post with helpful background to the market for block space]</ref> On the supply size, Bitcoin has a [[maximum block size]] (currently one million vbytes) that limits the maximum amount of transaction data that can be added to a block.

	However, Bitcoin blocks are not produced on a fixed schedule—the system targets an average of one block every 10 minutes over long periods of time but, over short periods of time, a new block can arrive in less than a second or more than an hour after the previous block. As the number of blocks received in a period of time varies, so does the effective maximum block size. For example, in the illustration below we see the average time between blocks based on the time they were received by a node during a one day period (left axis) and the corresponding effective maximum block size implied by that block production rate (right axis, in million [[vbytes]]):		However, Bitcoin blocks are not produced on a fixed schedule—the system targets an average of one block every 10 minutes over long periods of time but, over short periods of time, a new block can arrive in less than a second or more than an hour after the previous block. As the number of blocks received in a period of time varies, so does the effective maximum block size. For example, in the illustration below we see the average time between blocks based on the time they were received by a node during a one-day period (left axis) and the corresponding effective maximum block size implied by that block production rate (right axis, in million [[vbytes]]):

	[[File:Time-between-blocks.png\|center]]		[[File:Time-between-blocks.png\|center]]
Line 38:		Line 38:
	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.		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		Bitcoin transactions 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:		our examples larger than the previous one:

Line 53:		Line 53:
	[[File:Feerate3.png\|400px\|center]]		[[File:Feerate3.png\|400px\|center]]

	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:		Although long (wide) transactions may contain more total fees, 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 fee rate and including as many transactions as possible in a block:

	[[File:Feerate4.png\|400px\|center]]		[[File:Feerate4.png\|400px\|center]]

	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):		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 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):

	[[File:Feerate5.png\|400px\|center]]		[[File:Feerate5.png\|400px\|center]]
Line 108:		Line 108:
	Note: to ensure the algorithm runs quickly, implementations such as Bitcoin Core limit the maximum number of related transactions that will be collected together for consideration as one group. As of Bitcoin Core 0.15.0 (released late 2017), this is a maximum of 25 transactions, although there have been proposals to increase this amount somewhat.		Note: to ensure the algorithm runs quickly, implementations such as Bitcoin Core limit the maximum number of related transactions that will be collected together for consideration as one group. As of Bitcoin Core 0.15.0 (released late 2017), this is a maximum of 25 transactions, although there have been proposals to increase this amount somewhat.

	For spenders, miner use of transaction grouping means that if you're waiting for an unconfirmed transaction that pays too low a feerate (e.g. transaction A), you can create a child transaction spending an output of that transaction and which pays a much higher feerate (e.g. transaction B) to encourage miners to confirm both transactions in the same block. Wallets that explicitly support this feature often call it ''child pays for parent (CPFP)'' because ~~the~~ child transaction B helps pay for ~~the~~ parent transaction A.		For spenders, miner use of transaction grouping means that if you're waiting for an unconfirmed transaction that pays too low a feerate (e.g. transaction A), you can create a child transaction spending an output of that transaction and which pays a much higher feerate (e.g. transaction B) to encourage miners to confirm both transactions in the same block. Wallets that explicitly support this feature often call it ''child pays for parent (CPFP)'' because child transaction B helps pay for parent transaction A.

	To calculate the feerate for a transaction group, sum the fees paid by all the the group's unconfirmed transactions and divide that by the sum of the sizes for all those same transactions (in [[weight units]] or [[vbytes]]). For example, if transaction A has a fee of 1,000 nanobitcoins and a size of 250 vbytes and transaction B has a fee of 3,000 nanobitcoins and a size of 150 vbytes, the combined feerate is (1,000 + 3,000)/(250 + 150), which is 10 nanobitcoins per vbyte.		To calculate the feerate for a transaction group, sum the fees paid by all the the group's unconfirmed transactions and divide that by the sum of the sizes for all those same transactions (in [[weight units]] or [[vbytes]]). For example, if transaction A has a fee of 1,000 nanobitcoins and a size of 250 vbytes and transaction B has a fee of 3,000 nanobitcoins and a size of 150 vbytes, the combined feerate is (1,000 + 3,000)/(250 + 150), which is 10 nanobitcoins per vbyte.
Line 197:		Line 197:
	* https://jochen-hoenicke.de/queue/#1w - another mempool broken down by fee rate site		* https://jochen-hoenicke.de/queue/#1w - another mempool broken down by fee rate site
	* https://esotericnonsense.com/ - yet another mempool site, also very good		* https://esotericnonsense.com/ - yet another mempool site, also very good
	* 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.		* 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're wondering why it doesn't confirm.
	* https://mempool.space/ - Shows how the next few blocks are shaping up and the range of fees per block. Helps estimate the low end fee to use to get into the next block.		* https://mempool.space/ - Shows how the next few blocks are shaping up and the range of fees per block. Helps estimate the low-end fee to use to get into the next block.
	* https://whatthefee.io/ - Shows the probability of a particular fee rate being confirmed within a particular timeframe.		* https://whatthefee.io/ - Shows the probability of a particular fee rate being confirmed within a particular timeframe.

Line 207:		Line 207:
	Transaction priority was calculated as a value-weighted sum of input age, divided by transaction size in bytes:		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		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.		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		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