Difference between revisions of "Transaction replacement"

From Bitcoin Wiki
Jump to: navigation, search
m (Take out of draft)
m (Software support for replacement policies: Bold current versions)
 
(13 intermediate revisions by 6 users 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
 
transaction replaceability widely available again.<ref>[https://bitcointalk.org/index.php?topic=199947.0 Initial replace-by-fee implementation available for testnet], BitcoinTalk forum, posted 2013-05-09, ''retrieved 2015-12-09''</ref>
 
transaction replaceability widely available again.<ref>[https://bitcointalk.org/index.php?topic=199947.0 Initial replace-by-fee implementation available for testnet], BitcoinTalk forum, posted 2013-05-09, ''retrieved 2015-12-09''</ref>
  
Beginning with Bitcoin Core 0.12.0 (not released yet), it is expected
+
Beginning with Bitcoin Core 0.12.0 (released Feb 2016), one type of transaction replaceability, [[Replace by fee|replace-by-fee]] (RBF), became widely available.
that transaction replaceability will become widely available. This page
+
This page
 
attempts to document the current state of transaction replaceability for
 
attempts to document the current state of transaction replaceability for
 
wallet authors who want to use that feature.
 
wallet authors who want to use that feature.
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 will help maintain a consistent 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) ===
 +
 
 +
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.
  
Transaction replaceability is disallowed in a running node.
+
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 ===
+
=== "First-seen-safe" RBF ===
  
''Bitcoin Core 0.12.0 has not been released yet.  It is expected in Jan/Feb 2016.''
+
"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 uses the initial implementation of opt-in full-RBF
+
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]].
described in FIXME:bip-harding-opt-in-replace-by-fee.
+
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.
  
The initial implementation of opt-in full-RBF may be seen in
+
=== Time-based RBF ===
[https://github.com/bitcoin/bitcoin/pull/6871 Bitcoin Core PR#6871]
 
and specifically the master branch commits from
 
5891f870d68d90408aa5ce5b597fb574f2d2cbca to
 
16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive).
 
  
=== Peter Todd's full-RBF patchset ===
+
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.
  
Peter Todd has historically maintained patchsets against Bitcoin Core
+
=== Opt-in RBF ===
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.)
 
A rebased version of the most recent patch is also available for
 
contemporary [http://luke.dashjr.org/programs/bitcoin-ljr/ Bitcoin LJR] releases.
 
  
Notably, the patchset also implements preferential peering that allows
+
[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.
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.
 
  
As of 2015-12-08, there are no known large miners or mining pools that
+
Nodes supporting an opt-in RBF policy therefore switch the policy they use based on the preference indicated by the would-be-replaced transaction.
implement full-RBF.
 
  
* [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 & 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 ==
  
* [http://FIXME.com bip-harding-opt-in-replace-by-fee: Opt-in full-RBF signalling]
+
* [[Fee bumping]]
 +
* [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP 125]
 
* [https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/ Reddit: Questions about opt-in RBF]
 
* [https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/ Reddit: Questions about opt-in RBF]
  

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