Difference between revisions of "Transaction replacement"

From Bitcoin Wiki
Jump to: navigation, search
(Update & clarifications)
m (Software support for replacement policies: Bold current versions)
 
(3 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
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.
 
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.
 
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
 
Unconfirmed transaction replacement has been included in the first version of
Line 19: Line 20:
  
 
Unconfirmed 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 29: 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 0.1 to 0.3.11===
+
=== "First seen" / replacement-adverse ===
  
Unconfirmed transactions can be replaced at-will by the sender, regardless of fee increase or reduction, or output destinations.
+
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:
  
=== Bitcoin 0.3.12 to 0.3.19===
+
# 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.
  
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).
+
=== Sequential ===
  
=== Bitcoin Core & Knots 0.3.20 to 0.11.x ===
+
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.
  
Initially, Bitcoin Core did not modify, and continued the replacement policy of Bitcoin 0.3.19.
+
=== Replace by fee (RBF) ===
  
=== Peter Todd's full-RBF patchset ===
+
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.
  
Peter Todd has historically maintained patchsets against Bitcoin Core
+
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.
0.8.x and later that implement full-RBF for all transactions in the
+
As a result, several variations were proposed (the original is sometimes called "full RBF" or "unconditional RBF").
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
+
=== "First-seen-safe" RBF ===
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 ===
+
"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.
  
''Bitcoin Core 0.12.0 was released in Feb 2016.''
+
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.
  
Bitcoin Core 0.12.0 until 0.18.x included and used by default the initial implementation of opt-in RBF
+
=== Time-based RBF ===
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
+
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.
[https://github.com/bitcoin/bitcoin/pull/6871 Bitcoin Core PR#6871]
 
and specifically the master branch commits from
 
5891f870d68d90408aa5ce5b597fb574f2d2cbca to
 
16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive).
 
  
=== Bitcoin Knots 0.12.0 to 0.15.1 ===
+
=== Opt-in RBF ===
  
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.
+
[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.
  
=== Bitcoin Knots 0.16.0 and later ===
+
Nodes supporting an opt-in RBF policy therefore switch the policy they use based on the preference indicated by the would-be-replaced transaction.
  
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.
+
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).
  
=== Bitcoin Core 0.19.0 to 23.x ===
+
== Software support for replacement policies ==
  
Beginning with 0.19.0, Bitcoin Core removed the option to revert to the replacement-averse policy, only supporting opt-in RBF.
+
{| class="wikitable sortable"
 
+
! Software !! First-seen !! Sequential !! Full RBF !! FSS-RBF !! Time RBF !! Opt-in RBF
=== Bitcoin Core 24.0 and later ===
+
|-
 
+
| Bitcoin 0.1 - 0.3.11 || {{No}} || {{Prefer||Exclusive}} || {{No}} || {{No}} || {{No}} || {{No}}
Bitcoin Core 24.0 added the option to choose the unconditional RBF policy, though the default remains to apply only opt-in RBF.
+
|-
 +
| 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 & later''' || {{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 ==

Latest revision as of 08:43, 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 Exclusive Disabled (DoS risk) No No No No
Bitcoin Core 0.3.20 - 0.11.x Exclusive No No No No No
Bitcoin Knots 0.3.21 - 0.11.x Exclusive No No No No No
Satoshi RBF 0.8.6 - 0.10.x No No Exclusive No No No
Satoshi RBF 0.11.0 No No Default Yes No No
Satoshi RBF 0.11.1 & later No No Exclusive No No No
Bitcoin Core 0.12.0 - 0.18.x Yes No No No No Default
Bitcoin Knots 0.12.0 - 0.15.1 Yes No Yes No No Default
Bitcoin Knots 0.16.0 & later Yes No Default No No Yes
Bitcoin Core 0.19.0 - 23.x No No No No No Exclusive
Bitcoin Core 24.0 & later No No Yes No No Default

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