This version of Bitcoin Core adds a new mempoolfullrbf
configuration
option which allows users to change the policy their individual node
will use for relaying and mining unconfirmed transactions. The option
defaults to the same policy that was used in previous releases and no
changes to network behavior will occur if everyone uses the default.
But, if enough nodes (including nodes used by miners) change their
behavior using this option (or a related option provided by other
software), other users on the network who depend on the previous relay
policy may be affected---perhaps most especially users of the so-called zero-conf
acceptance policy.
Some Bitcoin services today expect that the first version of an unconfirmed transaction that they see will be the version of the transaction that ultimately gets confirmed---a transaction acceptance policy sometimes called "zero-conf".
It is not possible to provide any assurance that the first version of an unconfirmed transaction seen by a particular node will be the version that gets confirmed. If there are multiple versions of the same unconfirmed transaction available, only the miner who includes one of those transactions in a block gets to decide which version of the transaction gets confirmed.
Despite this lack of assurance, multiple merchants and services today use zero-conf acceptance policies. This seems reliable because Bitcoin Core, the most widely used node implementation, included a simplification for a long time where it only relayed and attempted to mine the first version of a transaction it saw, ignoring any alternative versions of the transaction.
There are several benefits to users from removing this first-seen simplification. One key benefit, the ability for the sender of a transaction to replace it with an alternative version paying higher fees, was realized in Bitcoin Core 0.12.0 (February 2016) with the introduction of BIP125 opt-in Replace By Fee (RBF). Spenders have to opt-in to allowing BIP125 replacement by setting a flag on every transaction they may want to replace in the future.
Since then, there has been discussion about completely removing the
first-seen simplification and allowing users to replace any of their
older unconfirmed transactions with newer transactions, a feature called
full-RBF. Spenders don't need to set a flag on their transactions in
order later replace them if full-RBF is available.
This release includes a mempoolfullrbf
configuration
option that allows enabling full-RBF, although it defaults to off
(allowing only opt-in RBF).
At least one alternative node implementation already enables full-RBF by default, and several contributors to Bitcoin Core have advocated for enabling full-RBF by default in a future version of Bitcoin Core.
As more nodes that participate in relay and mining begin enabling full-RBF, zero-conf transaction acceptance policies that previously seemed reliable (although were never assured) may suddenly become unreliable. It only takes one moderate-sized miner or mining pool to enable full-RBF to allow anyone to steal from unprepared zero-conf merchants, and neither the miner nor any attackers are under any obligation to announce their intents in advance.
Members of this project strongly recommend that zero-conf merchants and services take the appropriate steps to prepare for full-RBF.
I believe I've addressed all comments in this edit, except one described below. Thanks for the constructive feedback! Some notes below:
@ariard
The previous text didn't describe the opt-in mechanism, so I also added a sentence about that so that the text about signal-indepedent replacement would make sense.
I agree, although I think there are still people strongly in favor of default full-RBF and it's still a real possibility that merchants should prepare for. To try to address your feedback without substantially rewriting the text, I changed to the past tense: s/are advocating/have advocated/.
Yeah, I don't know of any good resources to which we can point zero-conf merchants at this time. If any exist, I'd be happy to add a link, but for now I've made no edit for this feedback.
@mzumsande
I changed this to "at least one" and removed "begun". For the number of implementations, I was thinking about Peter Todd's long-circulated patches for full-RBF (with optional preferential peering) as a separate implementation; also ghost42/sombernight said they run several bitcoinds in public use with the opt-in only RBF line commented out, which might could as an implementation, I dunno.
As for "recently switched", I didn't mean "begun" to imply recentness, but you're the second person to have that interpretation, so I changed it.
@stickies-v Thanks for the comments! Yours were straightforward, so I don't have anything extra to say after making edits. :-)