Difference between revisions of "Transaction replacement"

From Bitcoin Wiki
Jump to: navigation, search
(Updates)
(Rework page)
(One intermediate revision by the same user not shown)
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.
 +
Most of this article focuses on this replacement of unconfirmed transactions, since the consensus rules are fixed and unlikely to change ever.
 +
 
 +
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 19:
 
== 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 or similar policies
among nodes can help predict a popular network-wide mempool policy
+
among nodes can help predict popular network-wide mempool policies
 
with the following expected benefits:
 
with the following expected benefits:
  
Line 25: Line 30:
 
* 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 ===
+
=== "First seen" / replacement-adverse ===
 +
 
 +
The so-called "first seen" policy simply does not perform replacements at all (except as required by the consensus rules when a block confirms a conflicting transaction).
 +
A miner using a "first seen" policy can still end up mining a replacement in two notable cases:
 +
 
 +
# If the miner saw the "replacement" first. This can be easy to arrange. From the miner's perspective, no replacement occurred, but that is not necessarily the case for other users.
 +
# If another miner produces a block that confirms a conflicting transaction, this policy discards the first-seen transaction in favour for the confirmed one (required by the consensus rules). Note, however, that even if the block confirming the replacement is later reorganised away, the replacement transaction it confirmed is still preferred to re-mining by a miner using this policy, even if it had replaced another it saw first.
 +
 
 +
=== Sequential ===
 +
 
 +
The sequential policy was used originally by Satoshi's Bitcoin node software, and simply allows any later transaction to replace an earlier one (indicated by the "sequence" counter in the transaction).
 +
This policy has a risk of denial-of-service attacks on nodes, and therefore hasn't been supported since 2010.
 +
 
 +
=== Replace by fee (RBF) ===
  
Transaction replacability is disallowed in a running node.
+
The DoS risk in the sequential replacement policy was addressed in 2015 by the concept of requiring transaction replacements to include a higher fee.
 +
While fees cannot compensate nodes for the cost of performing the replacement, it is presumed to be paid eventually to a miner, and as such acts as an effective rate limit on any would-be attacker.
  
=== Bitcoin Core 0.12.0 to 0.16.0 ===
+
Despite fully addressing the dangers of the sequential policy, its deployment was met with resistance by people who have grown accustomed to the intermediate replacement-adverse policy and (irrationally) imagine transaction replacement to endanger their acceptance of unconfirmed transactions.
 +
As a result, several variations were proposed (the original is sometimes called "full RBF" or "unconditional RBF").
  
''Bitcoin Core 0.12.0 was released in Feb 2016.''
+
=== "First-seen-safe" RBF ===
  
Bitcoin Core 0.12.0 and later use the initial implementation of opt-in full-RBF
+
"First-seen-safe" RBF (FSS-RBF) limits replacements further, by requiring the replacement transaction to pay at least the same addresses in the same amounts.
described in [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP 125].
 
  
The initial implementation of opt-in full-RBF may be seen in
+
The downside to this approach is that it effectively requires adding additional inputs to fund any additional outputs or fees, rather than simply reducing [[change]].
[https://github.com/bitcoin/bitcoin/pull/6871 Bitcoin Core PR#6871]
+
This increases transaction size, and therefore also fees (beyond the increase required by RBF).
and specifically the master branch commits from
+
Arguably, it negates the benefit of replacement, making it comparable to [[child-pays-for-parent]] (non-replacement) policies.
5891f870d68d90408aa5ce5b597fb574f2d2cbca to
 
16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive).
 
  
=== Bitcoin Knots ===
+
=== Time-based RBF ===
  
Bitcoin Knots allows the user to easily configure its replacement policy.
+
Another policy proposed was to enforce the "first-seen" policy for a certain number of blocks after the transaction was initially seen, and afterward allowing its replacement by RBF only if that transaction has failed to be mined.
Opt-in RBF, full RBF, and strict first-seen policies are supported.
 
  
=== Peter Todd's full-RBF patchset ===
+
=== Opt-in RBF ===
  
Peter Todd has historically maintained patchsets against Bitcoin Core
+
[https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP 125] proposed a way for transactions to use their "sequence" number to signal their preference for handling with a "first-seen" or RBF policy.
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
+
Nodes supporting an opt-in RBF policy therefore switch the policy they use based on the preference indicated by the would-be-replaced transaction.
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]
+
Note that node software often does not implement the RBF rules proposed by BIP 125 exactly, with small variations considered preferable in practice (or sometimes accidental).
* [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
+
== Software support for replacement policies ==
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.
+
{| class="wikitable sortable"
# 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.
+
! Software !! First-seen !! Sequential !! Full RBF !! FSS-RBF !! Time RBF !! Opt-in RBF
# No more than 100 original transactions are replaced by the replacement transaction
+
|-
 +
| Bitcoin 0.1 - 0.3.11 || {{No}} || {{Prefer||Exclusive}} || {{No}} || {{No}} || {{No}} || {{No}}
 +
|-
 +
| Bitcoin 0.3.12 & later || {{Prefer|Exclusive}} || {{No|Disabled (DoS risk)}} || {{No}} || {{No}} || {{No}} || {{No}}
 +
|-
 +
| Bitcoin Core 0.3.20 - 0.11.x || {{Prefer|Exclusive}} || {{No}} || {{No}} || {{No}} || {{No}} || {{No}}
 +
|-
 +
| Bitcoin Knots 0.3.21 - 0.11.x || {{Prefer|Exclusive}} || {{No}} || {{No}} || {{No}} || {{No}} || {{No}}
 +
|-
 +
| Satoshi RBF 0.8.6 - 0.10.x || {{No}} || {{No}} || {{Prefer|Exclusive}} || {{No}} || {{No}} || {{No}}
 +
|-
 +
| Satoshi RBF 0.11.0 || {{No}} || {{No}} || {{Prefer|Default}} || {{Yes}} || {{No}} || {{No}}
 +
|-
 +
| Satoshi RBF 0.11.1 & later || {{No}} || {{No}} || {{Prefer|Exclusive}} || {{No}} || {{No}} || {{No}}
 +
|-
 +
| Bitcoin Core 0.12.0 - 0.18.x || {{Yes}} || {{No}} || {{No}} || {{No}} || {{No}} || {{Prefer|Default}}
 +
|-
 +
| Bitcoin Knots 0.12.0 - 0.15.1 || {{Yes}} || {{No}} || {{Yes}} || {{No}} || {{No}} || {{Prefer|Default}}
 +
|-
 +
| Bitcoin Knots 0.16.0 & latter || {{Yes}} || {{No}} || {{Prefer|Default}} || {{No}} || {{No}} || {{Yes}}
 +
|-
 +
| Bitcoin Core 0.19.0 - 23.x || {{No}} || {{No}} || {{No}} || {{No}} || {{No}} || {{Prefer|Exclusive}}
 +
|-
 +
| Bitcoin Core 24.0 & later || {{No}} || {{No}} || {{Yes}} || {{No}} || {{No}} || {{Prefer|Default}}
 +
|}
  
 
== See Also ==
 
== See Also ==

Revision as of 01:37, 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. Most of this article focuses on this replacement of unconfirmed transactions, since the consensus rules are fixed and unlikely to change ever.

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 or similar policies among nodes can help predict popular network-wide mempool policies 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.

"First seen" / replacement-adverse

The so-called "first seen" policy simply does not perform replacements at all (except as required by the consensus rules when a block confirms a conflicting transaction). A miner using a "first seen" policy can still end up mining a replacement in two notable cases:

  1. If the miner saw the "replacement" first. This can be easy to arrange. From the miner's perspective, no replacement occurred, but that is not necessarily the case for other users.
  2. If another miner produces a block that confirms a conflicting transaction, this policy discards the first-seen transaction in favour for the confirmed one (required by the consensus rules). Note, however, that even if the block confirming the replacement is later reorganised away, the replacement transaction it confirmed is still preferred to re-mining by a miner using this policy, even if it had replaced another it saw first.

Sequential

The sequential policy was used originally by Satoshi's Bitcoin node software, and simply allows any later transaction to replace an earlier one (indicated by the "sequence" counter in the transaction). This policy has a risk of denial-of-service attacks on nodes, and therefore hasn't been supported since 2010.

Replace by fee (RBF)

The DoS risk in the sequential replacement policy was addressed in 2015 by the concept of requiring transaction replacements to include a higher fee. While fees cannot compensate nodes for the cost of performing the replacement, it is presumed to be paid eventually to a miner, and as such acts as an effective rate limit on any would-be attacker.

Despite fully addressing the dangers of the sequential policy, its deployment was met with resistance by people who have grown accustomed to the intermediate replacement-adverse policy and (irrationally) imagine transaction replacement to endanger their acceptance of unconfirmed transactions. As a result, several variations were proposed (the original is sometimes called "full RBF" or "unconditional RBF").

"First-seen-safe" RBF

"First-seen-safe" RBF (FSS-RBF) limits replacements further, by requiring the replacement transaction to pay at least the same addresses in the same amounts.

The downside to this approach is that it effectively requires adding additional inputs to fund any additional outputs or fees, rather than simply reducing change. This increases transaction size, and therefore also fees (beyond the increase required by RBF). Arguably, it negates the benefit of replacement, making it comparable to child-pays-for-parent (non-replacement) policies.

Time-based RBF

Another policy proposed was to enforce the "first-seen" policy for a certain number of blocks after the transaction was initially seen, and afterward allowing its replacement by RBF only if that transaction has failed to be mined.

Opt-in RBF

BIP 125 proposed a way for transactions to use their "sequence" number to signal their preference for handling with a "first-seen" or RBF policy.

Nodes supporting an opt-in RBF policy therefore switch the policy they use based on the preference indicated by the would-be-replaced transaction.

Note that node software often does not implement the RBF rules proposed by BIP 125 exactly, with small variations considered preferable in practice (or sometimes accidental).

Software support for replacement policies

Software First-seen Sequential Full RBF FSS-RBF Time RBF Opt-in RBF
Bitcoin 0.1 - 0.3.11 No Exclusive No No No No
Bitcoin 0.3.12 & later Prefer Disabled (DoS risk) No No No No
Bitcoin Core 0.3.20 - 0.11.x Prefer No No No No No
Bitcoin Knots 0.3.21 - 0.11.x Prefer No No No No No
Satoshi RBF 0.8.6 - 0.10.x No No Prefer No No No
Satoshi RBF 0.11.0 No No Prefer Yes No No
Satoshi RBF 0.11.1 & later No No Prefer No No No
Bitcoin Core 0.12.0 - 0.18.x Yes No No No No Prefer
Bitcoin Knots 0.12.0 - 0.15.1 Yes No Yes No No Prefer
Bitcoin Knots 0.16.0 & latter Yes No Prefer No No Yes
Bitcoin Core 0.19.0 - 23.x No No No No No Prefer
Bitcoin Core 24.0 & later No No Yes No No Prefer

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