Transaction replacement: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
← Older editNewer edit →
Luke-jr (talk | contribs)
Clerks, Administrators, Editors
3,074 edits
Updates
Luke-jr (talk | contribs)
Clerks, Administrators, Editors
3,074 edits
Update & clarifications
Line 1: Line 1:
'''Transaction replaceability''' occurs when a full node allows one or
'''Transaction replacement''' occurs when a transaction seen by a node is conflicted with and ultimately replaced by another transaction.
more of the transactions in its memory pool (mempool) to be replaced
Typically, the replaced transaction had been unconfirmed, though it can happen sometimes in a [[blockchain reorganisation]] that a transaction with a few blocks confirmation can also be replaced.
with a different transaction that spends some or all of the same inputs.
Transactions in the canonical blockchain must always replace conflicting transactions (a blockchain with two conflicting transactions is invalid).
Transaction replaceability was enabled in the first version of
 
Unconfirmed transactions that do not conflict with the blockchain can, however, be replaced by other unconfirmed transactions at the whim of nodes, determined by the node operator's own policies.
Hypothetically, a node could also keep track of and relay multiple conflicting transactions, though this is not typically done due to DoS risks.
 
Unconfirmed transaction replacement has been included in the first version of
Bitcoin<ref>[https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434 Replacement in original Bitcoin source code], Satoshi Nakamoto, GitHub, ''Retrieved 2015-12-08''</ref> but was disabled in the 0.3.12 release with the comment,
Bitcoin<ref>[https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434 Replacement in original Bitcoin source code], Satoshi Nakamoto, GitHub, ''Retrieved 2015-12-08''</ref> but was disabled in the 0.3.12 release with the comment,
"Disable replacement feature for now".<ref>[https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7#diff-118fcbaaba162ba17933c7893247df3aR522 Commit disabling replacement "for now"], Satoshi Nakamoto, GitHub, ''Retrieved 2015-12-08''</ref>  Since then, there have been various attempts to make
"Disable replacement feature for now".<ref>[https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7#diff-118fcbaaba162ba17933c7893247df3aR522 Commit disabling replacement "for now"], Satoshi Nakamoto, GitHub, ''Retrieved 2015-12-08''</ref>  Since then, there have been various attempts to make
Line 14: Line 18:
== Node policies ==
== Node policies ==


Transaction replacement is optional (it is not, and cannot be,
Unconfirmed transaction replacement is optional (it is not, and cannot be,
a consensus rule), but widespread adherence to the same basic policy
a consensus rule), but widespread adherence to the same basic policy
among nodes can help predict a popular network-wide mempool policy
among nodes can help predict a popular network-wide mempool policy
Line 25: Line 29:
* Consistent mempools may help nodes more quickly validate newly-received blocks as well as reduce the bandwidth used to announce new blocks in the future.
* Consistent mempools may help nodes more quickly validate newly-received blocks as well as reduce the bandwidth used to announce new blocks in the future.


=== Bitcoin Core 0.3.12 to 0.11.x ===
=== Bitcoin 0.1 to 0.3.11===
 
Unconfirmed transactions can be replaced at-will by the sender, regardless of fee increase or reduction, or output destinations.
 
=== Bitcoin 0.3.12 to 0.3.19===
 
Transaction replacability is accepted only in mined blocks, after which the replaced transaction can only be restored by a subsequent [[blockchain reorganisation]] containing a conflicting transaction (a reorganisation not conflicting will not rereplace the previously-mined replacement).
 
=== Bitcoin Core & Knots 0.3.20 to 0.11.x ===
 
Initially, Bitcoin Core did not modify, and continued the replacement policy of Bitcoin 0.3.19.


Transaction replacability is disallowed in a running node.
=== Peter Todd's full-RBF patchset ===


=== Bitcoin Core 0.12.0 to 0.16.0 ===
Peter Todd has historically maintained patchsets against Bitcoin Core
0.8.x and later that implement full-RBF for all transactions in the
mempool.
Some older versions also provide an option to enable RBF First-Seen-Safe (RBF-FSS) only.
 
Notably, the patchset also implements preferential peering that allows
nodes implementing full-RBF to connect to each other so that replacements
can circulate even if full-RBF nodes represent a small minority of the
network.
 
=== Bitcoin Core 0.12.0 to 0.18.x ===


''Bitcoin Core 0.12.0 was released in Feb 2016.''
''Bitcoin Core 0.12.0 was released in Feb 2016.''


Bitcoin Core 0.12.0 and later use the initial implementation of opt-in full-RBF
Bitcoin Core 0.12.0 until 0.18.x included and used by default the initial implementation of opt-in RBF
described in [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP 125].
similar to (but not identical with) that described in [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP 125].
Users could turn off the feature, reverting to the old replacement-averse policy.


The initial implementation of opt-in full-RBF may be seen in  
The initial implementation of opt-in full-RBF may be seen in  
Line 42: Line 67:
16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive).
16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive).


=== Bitcoin Knots ===
=== Bitcoin Knots 0.12.0 to 0.15.1 ===


Bitcoin Knots allows the user to easily configure its replacement policy.
Bitcoin Knots 0.12.0 until 0.15.1 supported the same replacement-adverse and opt-in RBF policies as Bitcoin Core, but additionally offered the option for users to choose unconditional RBF, ignoring any policy preferences expressed using BIP 125.
Opt-in RBF, full RBF, and strict first-seen policies are supported.


=== Peter Todd's full-RBF patchset ===
=== Bitcoin Knots 0.16.0 and later ===


Peter Todd has historically maintained patchsets against Bitcoin Core
In 0.16.0, the default policy of Bitcoin Knots was changed to unconditional RBF, while support for both opt-in RBF and replacement-adverse policies have been maintained for users to choose at will.
0.8.x and later that implement full-RBF for all transactions in the
mempool. (Later versions also provide an option to enable RBF First-Seen-Safe (RBF-FSS) only.)


Notably, the patchset also implements preferential peering that allows
=== Bitcoin Core 0.19.0 to 23.x ===
nodes implementing full-RBF to connect to each other so that replacements
can circulate even if full-RBF nodes represent a small minority of the
network.


* [https://github.com/petertodd/bitcoin/branches/all?utf8=%E2%9C%93&query=replace-by-fee-v0.10 Replace by fee patches for Bitcoin Core 0.10.x]
Beginning with 0.19.0, Bitcoin Core removed the option to revert to the replacement-averse policy, only supporting opt-in RBF.
* [https://github.com/petertodd/bitcoin/branches/all?utf8=%E2%9C%93&query=replace-by-fee-v0.11 Replace by fee patches for Bitcoin Core 0.11.x]


Policy<ref>[https://github.com/bitcoin/bitcoin/compare/0.11...petertodd:replace-by-fee-v0.11.0 RBF patchset for 0.11.2], Peter Todd, GitHub, ''Retrieved 2015-12-08''</ref>: one or more transactions currently in the mempool (original
=== Bitcoin Core 24.0 and later ===
transactions) will be replaced by a new transaction (replacement
transaction) that spends one or more of the same inputs if,


# The replacement transaction pays an absolute higher fee than the original transactions.
Bitcoin Core 24.0 added the option to choose the unconditional RBF policy, though the default remains to apply only opt-in RBF.
# The replacement transaction must pay for its own bandwidth in addition to the amount paid by the original transactions at least by the rate set by the node's minimum relay fee setting.  For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the originals.
# No more than 100 original transactions are replaced by the replacement transaction


== See Also ==
== See Also ==

Revision as of 00:31, 24 November 2022

Transaction replacement occurs when a transaction seen by a node is conflicted with and ultimately replaced by another transaction. Typically, the replaced transaction had been unconfirmed, though it can happen sometimes in a blockchain reorganisation that a transaction with a few blocks confirmation can also be replaced. Transactions in the canonical blockchain must always replace conflicting transactions (a blockchain with two conflicting transactions is invalid).

Unconfirmed transactions that do not conflict with the blockchain can, however, be replaced by other unconfirmed transactions at the whim of nodes, determined by the node operator's own policies. Hypothetically, a node could also keep track of and relay multiple conflicting transactions, though this is not typically done due to DoS risks.

Unconfirmed transaction replacement has been included in the first version of Bitcoin[1] but was disabled in the 0.3.12 release with the comment, "Disable replacement feature for now".[2] Since then, there have been various attempts to make transaction replaceability widely available again.[3]

Beginning with Bitcoin Core 0.12.0 (released Feb 2016), one type of transaction replaceability, replace-by-fee (RBF), became widely available. This page attempts to document the current state of transaction replaceability for wallet authors who want to use that feature.

Node policies

Unconfirmed transaction replacement is optional (it is not, and cannot be, a consensus rule), but widespread adherence to the same basic policy among nodes can help predict a popular network-wide mempool policy with the following expected benefits:

  • Consistent policy makes it easy for wallet authors to write code that uses transaction replacement to provide usability-enhancing features.
  • Consistent policy helps ensure long-running mempools contain mostly the same transactions (mempool consistency), which makes it easier for wallets and nodes to make guesses about how long it will take a transaction to confirm.
  • Consistent mempools may help nodes more quickly validate newly-received blocks as well as reduce the bandwidth used to announce new blocks in the future.

Bitcoin 0.1 to 0.3.11

Unconfirmed transactions can be replaced at-will by the sender, regardless of fee increase or reduction, or output destinations.

Bitcoin 0.3.12 to 0.3.19

Transaction replacability is accepted only in mined blocks, after which the replaced transaction can only be restored by a subsequent blockchain reorganisation containing a conflicting transaction (a reorganisation not conflicting will not rereplace the previously-mined replacement).

Bitcoin Core & Knots 0.3.20 to 0.11.x

Initially, Bitcoin Core did not modify, and continued the replacement policy of Bitcoin 0.3.19.

Peter Todd's full-RBF patchset

Peter Todd has historically maintained patchsets against Bitcoin Core 0.8.x and later that implement full-RBF for all transactions in the mempool. Some older versions also provide an option to enable RBF First-Seen-Safe (RBF-FSS) only.

Notably, the patchset also implements preferential peering that allows nodes implementing full-RBF to connect to each other so that replacements can circulate even if full-RBF nodes represent a small minority of the network.

Bitcoin Core 0.12.0 to 0.18.x

Bitcoin Core 0.12.0 was released in Feb 2016.

Bitcoin Core 0.12.0 until 0.18.x included and used by default the initial implementation of opt-in RBF similar to (but not identical with) that described in BIP 125. Users could turn off the feature, reverting to the old replacement-averse policy.

The initial implementation of opt-in full-RBF may be seen in Bitcoin Core PR#6871 and specifically the master branch commits from 5891f870d68d90408aa5ce5b597fb574f2d2cbca to 16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive).

Bitcoin Knots 0.12.0 to 0.15.1

Bitcoin Knots 0.12.0 until 0.15.1 supported the same replacement-adverse and opt-in RBF policies as Bitcoin Core, but additionally offered the option for users to choose unconditional RBF, ignoring any policy preferences expressed using BIP 125.

Bitcoin Knots 0.16.0 and later

In 0.16.0, the default policy of Bitcoin Knots was changed to unconditional RBF, while support for both opt-in RBF and replacement-adverse policies have been maintained for users to choose at will.

Bitcoin Core 0.19.0 to 23.x

Beginning with 0.19.0, Bitcoin Core removed the option to revert to the replacement-averse policy, only supporting opt-in RBF.

Bitcoin Core 24.0 and later

Bitcoin Core 24.0 added the option to choose the unconditional RBF policy, though the default remains to apply only opt-in RBF.

See Also

References

  1. ↑ Replacement in original Bitcoin source code, Satoshi Nakamoto, GitHub, Retrieved 2015-12-08
  2. ↑ Commit disabling replacement "for now", Satoshi Nakamoto, GitHub, Retrieved 2015-12-08
  3. ↑ Initial replace-by-fee implementation available for testnet, BitcoinTalk forum, posted 2013-05-09, retrieved 2015-12-09
Retrieved from "https://en.bitcoin.it/w/index.php?title=Transaction_replacement&oldid=69562"