Fee estimation - Revision history

NotATether: Restore content and fix estimator and External feeds sections

2026-09-13T07:34:12Z

Restore content and fix estimator and External feeds sections

← Older revision		Revision as of 07:34, 13 September 2026
Line 7:		Line 7:
	Bitcoin Core's long-standing estimator is <code>CBlockPolicyEstimator</code>. When a transaction enters the local mempool, the node records its fee rate in an exponentially spaced bucket. When the transaction later confirms, the estimator records how many blocks elapsed between first sighting and inclusion. Transactions that leave without confirming are recorded as failures. Moving averages over short, medium, and long horizons let old data decay. To answer a confirmation target of ''n'' blocks, the estimator walks from high fee-rate buckets toward lower ones and returns a rate at which a sufficient fraction of observed transactions confirmed within the target (with checks at ''n''/2 and 2''n''). The <code>estimatesmartfee</code> RPC exposes this for targets from 1 to 1008 blocks. '''Conservative''' mode uses a longer history and tends to return a higher rate; '''economical''' mode tracks recent drops more closely and risks underpaying. The returned rate is at least the node's mempool minimum and minimum relay fee. A node without enough history cannot produce a reliable estimate.		Bitcoin Core's long-standing estimator is <code>CBlockPolicyEstimator</code>. When a transaction enters the local mempool, the node records its fee rate in an exponentially spaced bucket. When the transaction later confirms, the estimator records how many blocks elapsed between first sighting and inclusion. Transactions that leave without confirming are recorded as failures. Moving averages over short, medium, and long horizons let old data decay. To answer a confirmation target of ''n'' blocks, the estimator walks from high fee-rate buckets toward lower ones and returns a rate at which a sufficient fraction of observed transactions confirmed within the target (with checks at ''n''/2 and 2''n''). The <code>estimatesmartfee</code> RPC exposes this for targets from 1 to 1008 blocks. '''Conservative''' mode uses a longer history and tends to return a higher rate; '''economical''' mode tracks recent drops more closely and risks underpaying. The returned rate is at least the node's mempool minimum and minimum relay fee. A node without enough history cannot produce a reliable estimate.

	Estimates degrade when the local mempool diverges from miners' templates, for example after a sudden fee spike or when packages and RBF churn rewrite confirmation history. Wallets that must confirm within a short window often combine the estimator with manual overrides or external feeds.		Historical confirmation tracking can lag a sudden collapse in demand or under-react to a spike. Some wallets take the maximum of the Core estimate and a rate derived from the current mempool. Lightning and other time-sensitive protocols often use a short target and conservative mode, or they overshoot. On-chain wallets that can use [[Replace by fee]] may start with an economical estimate and bump later. Related package and child-pays-for-parent policies affect what fee is needed in practice; see [[Package relay]].

			After a transaction is broadcast, wallets that support [[Replace by fee]] can raise the fee if the first estimate was too low. Child-pays-for-parent and [[Package relay\|package relay]] change the effective rate a parent needs when a child carries the fees. Estimators that only look at unconfirmed parents in isolation can understate the package feerate miners will actually require. Estimates degrade when the local mempool diverges from miners' templates, for example after a sudden fee spike or when packages and RBF churn rewrite confirmation history. Wallets that must confirm within a short window often combine the estimator with manual overrides or external feeds.

	== External feeds ==		== External feeds ==

	~~Historical confirmation tracking~~ can ~~lag a sudden collapse in demand or under-react to~~ a ~~spike. Some wallets take the maximum of the Core~~ estimate ~~and a rate derived from~~ the ~~current~~ mempool. ~~Lightning and other time-sensitive protocols often use a short target and conservative mode,~~ or ~~they overshoot~~. ~~On-chain wallets that can use [[Replace by fee]]~~ may ~~start with an economical estimate and bump later. Related package and child-pays-for-parent policies affect what fee is needed in practice; see [[Package relay]]~~.		External fee APIs sample their own mempools and sometimes block templates from large miners. Those numbers can lead a local estimate when the node has been offline or has an empty mempool. They can also diverge during partitions or when the service applies different minimum relay policies. Operators who care about privacy may prefer local <code>estimatesmartfee</code> so transaction construction does not query a third party.


	== See also ==		== See also ==

NotATether: Add Bitcoin Core estimator and External feeds sections

2026-09-13T07:33:27Z

Add Bitcoin Core estimator and External feeds sections

← Older revision		Revision as of 07:33, 13 September 2026
Line 2:		Line 2:

	Early Bitcoin clients used a static default fee. As block space became scarce, that default was either wasteful or insufficient. Bitcoin Core replaced it with an estimator that observes how long transactions at various fee rates actually take to confirm, and wallets query that estimator when they build a transaction. Third-party services publish fee recommendations from their own mempools. Those figures can differ from a local node's estimate because mempools and policy are not globally identical. After SegWit, estimates are usually expressed as satoshis per virtual byte (related to [[Weight units]]), not per raw serialized byte.		Early Bitcoin clients used a static default fee. As block space became scarce, that default was either wasteful or insufficient. Bitcoin Core replaced it with an estimator that observes how long transactions at various fee rates actually take to confirm, and wallets query that estimator when they build a transaction. Third-party services publish fee recommendations from their own mempools. Those figures can differ from a local node's estimate because mempools and policy are not globally identical. After SegWit, estimates are usually expressed as satoshis per virtual byte (related to [[Weight units]]), not per raw serialized byte.

			== Bitcoin Core estimator ==

	Bitcoin Core's long-standing estimator is <code>CBlockPolicyEstimator</code>. When a transaction enters the local mempool, the node records its fee rate in an exponentially spaced bucket. When the transaction later confirms, the estimator records how many blocks elapsed between first sighting and inclusion. Transactions that leave without confirming are recorded as failures. Moving averages over short, medium, and long horizons let old data decay. To answer a confirmation target of ''n'' blocks, the estimator walks from high fee-rate buckets toward lower ones and returns a rate at which a sufficient fraction of observed transactions confirmed within the target (with checks at ''n''/2 and 2''n''). The <code>estimatesmartfee</code> RPC exposes this for targets from 1 to 1008 blocks. '''Conservative''' mode uses a longer history and tends to return a higher rate; '''economical''' mode tracks recent drops more closely and risks underpaying. The returned rate is at least the node's mempool minimum and minimum relay fee. A node without enough history cannot produce a reliable estimate.		Bitcoin Core's long-standing estimator is <code>CBlockPolicyEstimator</code>. When a transaction enters the local mempool, the node records its fee rate in an exponentially spaced bucket. When the transaction later confirms, the estimator records how many blocks elapsed between first sighting and inclusion. Transactions that leave without confirming are recorded as failures. Moving averages over short, medium, and long horizons let old data decay. To answer a confirmation target of ''n'' blocks, the estimator walks from high fee-rate buckets toward lower ones and returns a rate at which a sufficient fraction of observed transactions confirmed within the target (with checks at ''n''/2 and 2''n''). The <code>estimatesmartfee</code> RPC exposes this for targets from 1 to 1008 blocks. '''Conservative''' mode uses a longer history and tends to return a higher rate; '''economical''' mode tracks recent drops more closely and risks underpaying. The returned rate is at least the node's mempool minimum and minimum relay fee. A node without enough history cannot produce a reliable estimate.

			Estimates degrade when the local mempool diverges from miners' templates, for example after a sudden fee spike or when packages and RBF churn rewrite confirmation history. Wallets that must confirm within a short window often combine the estimator with manual overrides or external feeds.

			== External feeds ==

	Historical confirmation tracking can lag a sudden collapse in demand or under-react to a spike. Some wallets take the maximum of the Core estimate and a rate derived from the current mempool. Lightning and other time-sensitive protocols often use a short target and conservative mode, or they overshoot. On-chain wallets that can use [[Replace by fee]] may start with an economical estimate and bump later. Related package and child-pays-for-parent policies affect what fee is needed in practice; see [[Package relay]].		Historical confirmation tracking can lag a sudden collapse in demand or under-react to a spike. Some wallets take the maximum of the Core estimate and a rate derived from the current mempool. Lightning and other time-sensitive protocols often use a short target and conservative mode, or they overshoot. On-chain wallets that can use [[Replace by fee]] may start with an economical estimate and bump later. Related package and child-pays-for-parent policies affect what fee is needed in practice; see [[Package relay]].

	After a transaction is broadcast, wallets that support [[Replace by fee]] can raise the fee if the first estimate was too low. Child-pays-for-parent and [[Package relay\|package relay]] change the effective rate a parent needs when a child carries the fees. Estimators that only look at unconfirmed parents in isolation can understate the package feerate miners will actually require.

	External fee APIs sample their own mempools and sometimes block templates from large miners. Those numbers can lead a local estimate when the node has been offline or has an empty mempool. They can also diverge during partitions or when the service applies different minimum relay policies. Operators who care about privacy may prefer local <code>estimatesmartfee</code> so transaction construction does not query a third party.

	== See also ==		== See also ==

NotATether: Expand See also links

2026-09-13T07:19:51Z

Expand See also links

← Older revision		Revision as of 07:19, 13 September 2026
Line 14:		Line 14:
	* [[Transaction fees]]		* [[Transaction fees]]
	* [[Mempool]]		* [[Mempool]]
			* [[Cluster mempool]]
	* [[Replace by fee]]		* [[Replace by fee]]
	* [[Package relay]]		* [[Package relay]]

NotATether: Add third-party APIs versus local estimator

2026-09-13T07:19:49Z

Add third-party APIs versus local estimator

← Older revision		Revision as of 07:19, 13 September 2026
Line 8:		Line 8:

	After a transaction is broadcast, wallets that support [[Replace by fee]] can raise the fee if the first estimate was too low. Child-pays-for-parent and [[Package relay\|package relay]] change the effective rate a parent needs when a child carries the fees. Estimators that only look at unconfirmed parents in isolation can understate the package feerate miners will actually require.		After a transaction is broadcast, wallets that support [[Replace by fee]] can raise the fee if the first estimate was too low. Child-pays-for-parent and [[Package relay\|package relay]] change the effective rate a parent needs when a child carries the fees. Estimators that only look at unconfirmed parents in isolation can understate the package feerate miners will actually require.

			External fee APIs sample their own mempools and sometimes block templates from large miners. Those numbers can lead a local estimate when the node has been offline or has an empty mempool. They can also diverge during partitions or when the service applies different minimum relay policies. Operators who care about privacy may prefer local <code>estimatesmartfee</code> so transaction construction does not query a third party.

	== See also ==		== See also ==

NotATether: Add RBF and package feerate interaction

2026-09-13T07:19:47Z

Add RBF and package feerate interaction

← Older revision		Revision as of 07:19, 13 September 2026
Line 6:		Line 6:

	Historical confirmation tracking can lag a sudden collapse in demand or under-react to a spike. Some wallets take the maximum of the Core estimate and a rate derived from the current mempool. Lightning and other time-sensitive protocols often use a short target and conservative mode, or they overshoot. On-chain wallets that can use [[Replace by fee]] may start with an economical estimate and bump later. Related package and child-pays-for-parent policies affect what fee is needed in practice; see [[Package relay]].		Historical confirmation tracking can lag a sudden collapse in demand or under-react to a spike. Some wallets take the maximum of the Core estimate and a rate derived from the current mempool. Lightning and other time-sensitive protocols often use a short target and conservative mode, or they overshoot. On-chain wallets that can use [[Replace by fee]] may start with an economical estimate and bump later. Related package and child-pays-for-parent policies affect what fee is needed in practice; see [[Package relay]].

			After a transaction is broadcast, wallets that support [[Replace by fee]] can raise the fee if the first estimate was too low. Child-pays-for-parent and [[Package relay\|package relay]] change the effective rate a parent needs when a child carries the fees. Estimators that only look at unconfirmed parents in isolation can understate the package feerate miners will actually require.

	== See also ==		== See also ==

NotATether: Create Fee estimation stub (estimatesmartfee / mempool forecast)

2026-09-12T13:12:10Z

Create Fee estimation stub (estimatesmartfee / mempool forecast)

New page

'''Fee estimation''' is the process by which a wallet or node predicts the fee rate that will get a transaction confirmed within a target number of blocks. Bitcoin does not have a protocol-level fee. Miners select transactions from the [[Mempool|mempool]] by policy, typically preferring higher fee rates. An estimate is therefore a forecast of the competitive fee market, not a consensus value. It is related to but distinct from the broader topic of [[Transaction fees]].

Early Bitcoin clients used a static default fee. As block space became scarce, that default was either wasteful or insufficient. Bitcoin Core replaced it with an estimator that observes how long transactions at various fee rates actually take to confirm, and wallets query that estimator when they build a transaction. Third-party services publish fee recommendations from their own mempools. Those figures can differ from a local node's estimate because mempools and policy are not globally identical. After SegWit, estimates are usually expressed as satoshis per virtual byte (related to [[Weight units]]), not per raw serialized byte.

Bitcoin Core's long-standing estimator is <code>CBlockPolicyEstimator</code>. When a transaction enters the local mempool, the node records its fee rate in an exponentially spaced bucket. When the transaction later confirms, the estimator records how many blocks elapsed between first sighting and inclusion. Transactions that leave without confirming are recorded as failures. Moving averages over short, medium, and long horizons let old data decay. To answer a confirmation target of ''n'' blocks, the estimator walks from high fee-rate buckets toward lower ones and returns a rate at which a sufficient fraction of observed transactions confirmed within the target (with checks at ''n''/2 and 2''n''). The <code>estimatesmartfee</code> RPC exposes this for targets from 1 to 1008 blocks. '''Conservative''' mode uses a longer history and tends to return a higher rate; '''economical''' mode tracks recent drops more closely and risks underpaying. The returned rate is at least the node's mempool minimum and minimum relay fee. A node without enough history cannot produce a reliable estimate.

Historical confirmation tracking can lag a sudden collapse in demand or under-react to a spike. Some wallets take the maximum of the Core estimate and a rate derived from the current mempool. Lightning and other time-sensitive protocols often use a short target and conservative mode, or they overshoot. On-chain wallets that can use [[Replace by fee]] may start with an economical estimate and bump later. Related package and child-pays-for-parent policies affect what fee is needed in practice; see [[Package relay]].

== See also ==
* [[Transaction fees]]
* [[Mempool]]
* [[Replace by fee]]
* [[Package relay]]
* [[Weight units]]
* [[Confirmation]]

== External links ==
* [https://bitcoinops.org/en/topics/fee-estimation/ Bitcoin Optech: Fee estimation]
* [https://bitcoincore.org/en/doc/ Bitcoin Core RPC documentation (<code>estimatesmartfee</code>)]
* [https://github.com/bitcoin/bitcoin/blob/master/src/policy/fees.h Bitcoin Core <code>CBlockPolicyEstimator</code> (fees.h)]

[[Category:Technical]]