Full RBF - Revision history

NotATether: Add Opt-in history, Policy change, and Deployment sections

2026-09-13T07:35:14Z

Add Opt-in history, Policy change, and Deployment sections

← Older revision		Revision as of 07:35, 13 September 2026
Line 1:		Line 1:
	'''Full RBF''' (full replace-by-fee) is a [[Mempool\|mempool]] policy in which a node accepts a replacement for an unconfirmed transaction even when the original did not signal replaceability under BIP 125. It is a relay and mining policy, not a consensus rule. Nodes that do not implement full RBF still accept blocks that contain replacements. It is one variant of [[Replace by fee]]; other historical variants include opt-in RBF, first-seen-safe RBF, and delayed RBF.		'''Full RBF''' (full replace-by-fee) is a [[Mempool\|mempool]] policy in which a node accepts a replacement for an unconfirmed transaction even when the original did not signal replaceability under BIP 125. It is a relay and mining policy, not a consensus rule. Nodes that do not implement full RBF still accept blocks that contain replacements. It is one variant of [[Replace by fee]]; other historical variants include opt-in RBF, first-seen-safe RBF, and delayed RBF.

			== Opt-in history ==

	Bitcoin Core historically applied a first-seen rule: once a transaction was in the mempool, a conflicting higher-fee transaction was ignored unless the original had opted in. BIP 125, deployed in Bitcoin Core 0.12.0, defined that opt-in: a transaction signals replaceability when any of its inputs has <code>nSequence</code> less than <code>0xffffffff−1</code> (see [[nSequence]]). Wallets that wanted to bump fees set the signal. Wallets that wanted to present an unconfirmed output as final left it unset. The first-seen simplification never bound miners: a miner could always include a higher-fee conflict. As more hash power and more relay nodes treated unsignaled replacements as acceptable, the opt-in bit stopped predicting whether an unconfirmed transaction would remain first.		Bitcoin Core historically applied a first-seen rule: once a transaction was in the mempool, a conflicting higher-fee transaction was ignored unless the original had opted in. BIP 125, deployed in Bitcoin Core 0.12.0, defined that opt-in: a transaction signals replaceability when any of its inputs has <code>nSequence</code> less than <code>0xffffffff−1</code> (see [[nSequence]]). Wallets that wanted to bump fees set the signal. Wallets that wanted to present an unconfirmed output as final left it unset. The first-seen simplification never bound miners: a miner could always include a higher-fee conflict. As more hash power and more relay nodes treated unsignaled replacements as acceptable, the opt-in bit stopped predicting whether an unconfirmed transaction would remain first.

			== Policy change ==

	Under full RBF, replacement is still subject to the rest of the node's replacement rules: the replacement must pay a higher absolute fee, a sufficiently higher fee rate, and must not cause unbounded mempool churn (the familiar BIP 125 incentive constraints, with details revised over time). The change is only that the original transaction's signaling is not required. The policy is local. A node with full RBF will relay and, if mining, consider the higher-fee transaction. A node without it will keep the first-seen transaction and will not relay the conflict. Compact block reconstruction is more reliable among nodes that share the same replacement policy.		Under full RBF, replacement is still subject to the rest of the node's replacement rules: the replacement must pay a higher absolute fee, a sufficiently higher fee rate, and must not cause unbounded mempool churn (the familiar BIP 125 incentive constraints, with details revised over time). The change is only that the original transaction's signaling is not required. The policy is local. A node with full RBF will relay and, if mining, consider the higher-fee transaction. A node without it will keep the first-seen transaction and will not relay the conflict. Compact block reconstruction is more reliable among nodes that share the same replacement policy.
Line 11:		Line 15:
	Bitcoin Core exposed <code>mempoolfullrbf</code> so operators could opt into unsignaled replacements before the policy became the default. Version 28.0 defaulted the option on. Version 29.0 removed the setting so full RBF is simply part of ordinary replacement policy. Older nodes and alternative implementations may still prefer first-seen behavior, which can temporarily split relay paths for conflicting transactions.		Bitcoin Core exposed <code>mempoolfullrbf</code> so operators could opt into unsignaled replacements before the policy became the default. Version 28.0 defaulted the option on. Version 29.0 removed the setting so full RBF is simply part of ordinary replacement policy. Older nodes and alternative implementations may still prefer first-seen behavior, which can temporarily split relay paths for conflicting transactions.

	Merchants that formerly treated BIP 125 non-signaling as a soft finality signal lost that heuristic once full RBF became widespread. Zero-confirmation acceptance policies must assume replacement is always possible at a high enough fee. Fee-bumping wallets benefit because they no longer need to remember to set nSequence at the first broadcast in order to raise fees later on Core peers.		== Deployment ==

			Merchants that formerly treated BIP 125 non-signaling as a soft finality signal lost that heuristic once full RBF became widespread. Zero-confirmation acceptance policies must assume replacement is always possible at a high enough fee. Fee-bumping wallets benefit because they no longer need to remember to set nSequence at the first broadcast in order to raise fees later on Core peers. Merchants that treated unsignaled unconfirmed inputs as final already faced miner-level replacement risk. Full RBF makes that risk match common relay policy, so zero-conf acceptance remains an explicit business decision rather than an assumption about BIP 125 signaling.

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

NotATether: Expand See also links

2026-09-13T07:20:47Z

Expand See also links

← Older revision		Revision as of 07:20, 13 September 2026
Line 18:		Line 18:
	* [[Fee estimation]]		* [[Fee estimation]]
	* [[Package relay]]		* [[Package relay]]
			* [[Cluster mempool]]
	* [[nSequence]]		* [[nSequence]]
	* [[TRUC]]		* [[TRUC]]
			* [[Zero-confirmation transaction]]

	== External links ==		== External links ==

NotATether: Add merchant and wallet implications

2026-09-13T07:20:46Z

Add merchant and wallet implications

← Older revision		Revision as of 07:20, 13 September 2026
Line 10:		Line 10:

	Bitcoin Core exposed <code>mempoolfullrbf</code> so operators could opt into unsignaled replacements before the policy became the default. Version 28.0 defaulted the option on. Version 29.0 removed the setting so full RBF is simply part of ordinary replacement policy. Older nodes and alternative implementations may still prefer first-seen behavior, which can temporarily split relay paths for conflicting transactions.		Bitcoin Core exposed <code>mempoolfullrbf</code> so operators could opt into unsignaled replacements before the policy became the default. Version 28.0 defaulted the option on. Version 29.0 removed the setting so full RBF is simply part of ordinary replacement policy. Older nodes and alternative implementations may still prefer first-seen behavior, which can temporarily split relay paths for conflicting transactions.

			Merchants that formerly treated BIP 125 non-signaling as a soft finality signal lost that heuristic once full RBF became widespread. Zero-confirmation acceptance policies must assume replacement is always possible at a high enough fee. Fee-bumping wallets benefit because they no longer need to remember to set nSequence at the first broadcast in order to raise fees later on Core peers.

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

NotATether: Add Core 28 default and 29 option removal

2026-09-13T07:20:44Z

Add Core 28 default and 29 option removal

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

	Bitcoin Core 24.0 added the <code>mempoolfullrbf</code> configuration option, defaulting to off (opt-in RBF only). Bitcoin Core 28.0 changed the default to on. Bitcoin Core 29.0 removed the option, making full replace-by-fee the only mempool replacement policy in Core. The Core wallet has defaulted to creating opt-in RBF transactions for some time. Full RBF affects how the node treats transactions created by others, not only its own wallet. Because policy is not consensus, effective network behaviour still depends on what miners currently run.		Bitcoin Core 24.0 added the <code>mempoolfullrbf</code> configuration option, defaulting to off (opt-in RBF only). Bitcoin Core 28.0 changed the default to on. Bitcoin Core 29.0 removed the option, making full replace-by-fee the only mempool replacement policy in Core. The Core wallet has defaulted to creating opt-in RBF transactions for some time. Full RBF affects how the node treats transactions created by others, not only its own wallet. Because policy is not consensus, effective network behaviour still depends on what miners currently run.

			Bitcoin Core exposed <code>mempoolfullrbf</code> so operators could opt into unsignaled replacements before the policy became the default. Version 28.0 defaulted the option on. Version 29.0 removed the setting so full RBF is simply part of ordinary replacement policy. Older nodes and alternative implementations may still prefer first-seen behavior, which can temporarily split relay paths for conflicting transactions.

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

NotATether: Create Full RBF stub: mempool policy vs BIP125 opt-in; Core 24/28/29 history; link Replace by fee / Mempool / Fee estimation / Package relay (no Package RBF page)

2026-09-12T13:22:36Z

Create Full RBF stub: mempool policy vs BIP125 opt-in; Core 24/28/29 history; link Replace by fee / Mempool / Fee estimation / Package relay (no Package RBF page)

New page

'''Full RBF''' (full replace-by-fee) is a [[Mempool|mempool]] policy in which a node accepts a replacement for an unconfirmed transaction even when the original did not signal replaceability under BIP 125. It is a relay and mining policy, not a consensus rule. Nodes that do not implement full RBF still accept blocks that contain replacements. It is one variant of [[Replace by fee]]; other historical variants include opt-in RBF, first-seen-safe RBF, and delayed RBF.

Bitcoin Core historically applied a first-seen rule: once a transaction was in the mempool, a conflicting higher-fee transaction was ignored unless the original had opted in. BIP 125, deployed in Bitcoin Core 0.12.0, defined that opt-in: a transaction signals replaceability when any of its inputs has <code>nSequence</code> less than <code>0xffffffff−1</code> (see [[nSequence]]). Wallets that wanted to bump fees set the signal. Wallets that wanted to present an unconfirmed output as final left it unset. The first-seen simplification never bound miners: a miner could always include a higher-fee conflict. As more hash power and more relay nodes treated unsignaled replacements as acceptable, the opt-in bit stopped predicting whether an unconfirmed transaction would remain first.

Under full RBF, replacement is still subject to the rest of the node's replacement rules: the replacement must pay a higher absolute fee, a sufficiently higher fee rate, and must not cause unbounded mempool churn (the familiar BIP 125 incentive constraints, with details revised over time). The change is only that the original transaction's signaling is not required. The policy is local. A node with full RBF will relay and, if mining, consider the higher-fee transaction. A node without it will keep the first-seen transaction and will not relay the conflict. Compact block reconstruction is more reliable among nodes that share the same replacement policy.

Full RBF does not make unconfirmed transactions safe. It makes the unsafety uniform: any unconfirmed output can be replaced by a higher-fee double spend that the network is willing to relay. Services that credit unconfirmed deposits do so at their own risk regardless of signaling. Wallets that need to increase a stuck transaction's fee can do so without having set the BIP 125 bit at first broadcast, provided enough of the relay network and miners apply full RBF. Related package policies (limited package RBF, [[TRUC]] / v3 transactions) are separate rules about replacing clusters of related transactions; they are not implied by full RBF alone. See [[Package relay]] and [[Replace by fee]].

Bitcoin Core 24.0 added the <code>mempoolfullrbf</code> configuration option, defaulting to off (opt-in RBF only). Bitcoin Core 28.0 changed the default to on. Bitcoin Core 29.0 removed the option, making full replace-by-fee the only mempool replacement policy in Core. The Core wallet has defaulted to creating opt-in RBF transactions for some time. Full RBF affects how the node treats transactions created by others, not only its own wallet. Because policy is not consensus, effective network behaviour still depends on what miners currently run.

== See also ==
* [[Replace by fee]]
* [[Mempool]]
* [[Fee estimation]]
* [[Package relay]]
* [[nSequence]]
* [[TRUC]]

== External links ==
* [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP 125: Opt-in Full Replace-by-Fee Signaling]
* [https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md Bitcoin Core mempool replacement policy]
* [https://bitcoinops.org/en/topics/replace-by-fee/ Bitcoin Optech: Replace by fee]
* [https://bitcoincore.org/en/releases/24.0.1/ Bitcoin Core 24.0.1 release notes (<code>mempoolfullrbf</code>)]
* [https://bitcoincore.org/en/releases/28.0/ Bitcoin Core 28.0 release notes (default on)]
* [https://bitcoincore.org/en/releases/29.0/ Bitcoin Core 29.0 release notes (option removed)]

[[Category:Technical]]