Replace by fee: Difference between revisions
Initial description |
→Criticism: added link to bram cohen's blog on unconfirmed transactions |
||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
Since Bitcoin's original inception, it has supported the concept that an unconfirmed transaction may be modified and re-issued. | Since Bitcoin's original inception, it has supported the concept that an unconfirmed transaction may be modified and re-issued. | ||
This concept is known as "transaction replacement", because the new transaction replaces the old one. | This concept is known as "[[transaction replacement]]", because the new transaction replaces the old one. | ||
However, since transaction replacement eliminates the cost to all previous transactions being replaced, it created a DoS risk: | However, since transaction replacement eliminates the cost to all previous transactions being replaced, it created a DoS risk: | ||
attackers could produce as many transactions as they wanted, while only paying the fee for the one variant that was eventually mined. | attackers could produce as many transactions as they wanted, while only paying the fee for the one variant that was eventually mined. | ||
Line 42: | Line 42: | ||
However, this criticism does not hold up: double spend attacks are entirely possible without RBF. | However, this criticism does not hold up: double spend attacks are entirely possible without RBF. | ||
A good analysis of the tradeoffs with transaction replacement can be in a blog post by Bram Cohen: https://medium.com/@bramcohen/the-inevitable-demise-of-unconfirmed-bitcoin-transactions-8b5f66a44a35 |
Latest revision as of 15:59, 6 March 2018
Since Bitcoin's original inception, it has supported the concept that an unconfirmed transaction may be modified and re-issued. This concept is known as "transaction replacement", because the new transaction replaces the old one. However, since transaction replacement eliminates the cost to all previous transactions being replaced, it created a DoS risk: attackers could produce as many transactions as they wanted, while only paying the fee for the one variant that was eventually mined.
To solve this problem, the concept of replace-by-fee was developed: by requiring replacements to pay for not only its own cost, but also the fee of the transactions being replaced, the DoS risk was strictly less than the risk of flooding with separate transactions.
Variants
Replace-by-fee is a node policy that comes in multiple variants:
Full RBF
So-called "full RBF" unconditionally allows a transaction to replace older ones so long as it pays a sufficient fee.
First-seen-safe RBF
The "first-seen-safe" variant only allows the replacement if an additional criteria is met: the replacement transaction must pay all the same outputs as the transactions being replaced.
This variant was created to counter the accusation that RBF enabled double spend attacks, by preventing such attacks from making use of RBF.
One downside of this variant, is that the change output is necessarily treated as a payment, and cannot be reduced. This results in larger transaction sizes (as additional inputs must be added) and therefore fees.
Opt-in RBF
The "opt-in" variant only allows the replacement when the transactions being replaced have explicitly signalled they allow replacement. This signalling is done via the "sequence" field, and defined by BIP 125.
One downside of this variant is that users must know in advance when they may wish to replace a transaction. As a result, opt-in RBF is often used as a default even when it might otherwise not be needed.
Delayed RBF
Delayed RBF is a variant which allows transactions to be replaced unconditionally, but only after a given number of blocks have been mined since the replaced transactions were first seen by the node.
Criticism
Some people believe transaction replacement harms Bitcoin by enabling double spend attacks, where an attacker sends bitcoins, but then replaces that transaction with one taking them back.
However, this criticism does not hold up: double spend attacks are entirely possible without RBF.
A good analysis of the tradeoffs with transaction replacement can be in a blog post by Bram Cohen: https://medium.com/@bramcohen/the-inevitable-demise-of-unconfirmed-bitcoin-transactions-8b5f66a44a35