RBF debate is incentives and choice – Bitcoin Magazine
This is an opinion piece by Shinobi, a self-taught Bitcoin educator and tech-savvy Bitcoin podcast host.
Big surprise, Bitcoiners are furiously arguing over a proposed changeset to be included in the next release of Bitcoin Core. Opt-in replace-by-fee (RBF) is a mempool policy feature proposed in 2015 to provide users with a tool to deal with rapid increases in fees that cause their transactions to be stuck unconfirmed in the mempool for long periods of time .
Obviously this will be a problem for any use of Bitcoin if the transaction volume grows on average to be consistently higher than the number of transactions that can be processed on the blockchain, so unless you think it will never happen this is a necessary functionality on the Network.
Transaction replacement was actually included and possible in the original version of the software before Satoshi Nakamoto disappeared. He eventually disabled the feature because the way he originally implemented it created a vector for denial-of-service attacks against nodes. His implementation allowed the replacement of any transaction without paying a higher fee, which would have essentially allowed users to send a transaction and then start broadcasting an unlimited number of replacements to the network. This would obviously allow spamming of nodes with massive amounts of data that did not require proof of work and would increase the cost of running a node prohibitively.
Over the years, some different proposals for a renewed and more secure transaction compensation scheme have been discussed. We will quickly go through all of these.
Full RBF
The simplest variant of RBF. Any transaction can be replaced as long as the replacement of the original transaction pays a higher fee than the one it replaces. That way, all transactions are replaceable, but the requirement to pay a higher fee each time you replace one prevents an endless spam of new versions of the transaction congestion nodes.
First-set safe RBF
This suggested allowing all transactions to be replaced in the mempool, with a special caveat; all the output of the original transaction must also be included in the replacement transaction, including the change output. It still requires increasing the fee to replace a transaction, but the requirement to maintain the same outputs means you have to add a new input and another change output, because none of the original outputs can be changed. This results in larger transactions having to pay more in total fees to ensure the replacement pays a higher fee rate.
Delayed RBF
Here was a proposal to allow any transaction to be replaced in the mempool, but only after a certain number of blocks had passed since the node saw the original transaction. The idea was that this would allow transactions stuck in high-fee environments to be replaced and confirmed more quickly, but the time delay in how quickly it could be replaced would prevent zero-confirmation of dual-use attempts.
Opt-in RBF
This is what was implemented in 2016 as defined in BIP 125. Transactions can only be replaced if they set a specific flag in the transaction that chooses to replace, or if one of their ancestors did so in the case of a chain of unconfirmed transactions, to allow people receiving funds to know if an unconfirmed transaction will be replaceable in the mempool.
The big controversy today is that the next release of Core, 0.24, is set to introduce a full RBF mempool policy flag. What does this mean? It will give users a configurable option to change their local mempool policy from opt-in RBF to full RBF; by default the option will be omitted (nodes will use full RBF). So why are people up in arms about this change? Enterprises that accept zero confirmation transactions rely on most nodes’ mempools refusing to replace transactions that have not selected RBF with a transaction flag. They do this by tactically connecting their node to a large number of other nodes spread throughout the network. This allows them to very quickly detect the presence of a double spend transaction on the network, as it must be done almost immediately if a transaction is not flagged as RBF to have a good chance of reaching miners. It is also worth pointing out that any business on the network cannot do this without effectively sybilizing the network. These businesses claim that full RBF “breaks” their business model to use RBF. Some even have criticised Core developers who “force” a change that negatively affects those businesses.
The simple reality is that double spending has and always will be possible, opt-in RBF or full RBF does nothing to change this. Furthermore, simply creating an option to change your own local mempool policy (which is set to off by default) is in no way dictating changes to anyone, it’s an option given to users to make a choice themselves. At the end of the day when it comes to which transactions will actually be included in the next block, the only mempools that matter are the miners’. The mempools of individual user nodes are nothing more than a series of memory storage with the ultimate goal of conveying all these unconfirmed transactions to the miners so that they can be included in a block in the end.
Mempool policy is used as a kind of soft security mechanism to prevent denial of service attacks on nodes and protect users from shooting themselves in the foot with complicated transactions and scripts. Many types of transactions are valid by consensus, allowed to be included in a block, but will not be forwarded by the node’s default mempool policy. However, this does nothing at all to stop a particular user from forwarding a transaction that would be ignored by nodes on the network directly to a miner.
That is the crux of the matter. All it takes is miners setting up an API to send transactions directly to them, which many already have, and the restrictions of mempool policies across the network don’t matter. You can just give a transaction directly to the miners and bypass any rules about when something can be replaced in the mempool of other nodes. Think about the incentives for that – if there is money to be made by mining a certain class of transactions, but mempools across the network won’t forward them, what would you do as a miner? Just accept them directly. The more the subsidy decreases and transaction fees grow as a percentage of miner income, the more inevitable it becomes that miners will only accept replacements that pay higher fees if nodes on the network will not forward them indirectly. It is inevitable.
This change does not change the default mempool policy for Bitcoin Core, it simply presents an option for an individual node operator to change their local mempool policy if they wish.
And I might add, this is an option that has always been available if users chose to change their client. All it does is make a choice that has always been available to users easier to make. The incentives inevitably lead to the state where all transactions will be interchangeable if miners act in an economically rational way – it is inevitable. The only question in the matter is whether the software reflects these incentives, in a way that allows individual users to decide for themselves what policy to use for their mempool, or should people just sit back and let the mediation of transactions centralize around direct submission to miners themselves?
The end result is the same, but waiting for miners to retreat to direct transaction submission will have very negative consequences. It would have privacy implications for people broadcasting transactions to the network, and it could have very negative consequences for users’ ability to decide what fee to pay for a transaction. If large portions of pending transactions are no longer publicly broadcast over the network, users will have an incomplete view of who they are bidding against for inclusion in a block. Miners may even lie about the distribution of fees to motivate users to pay more than they have to.
The only real downside to making this option available is that full RBF may not work consistently if only a small portion of the network, including miners, chooses to enable full RBF. However, this is fundamentally no different in terms of transition than the upgrade to SegWit was. During this transition period, non-upgraded nodes would forward SegWit transactions because they were unable to validate them, so during that period the same dynamic of propagation was inconsistent until enough users upgraded. But ultimately, that didn’t change the fact that upgrading was a decision for individual users to make.
Fighting against full RBF is ultimately just denying the reality of the incentives on the network. Nothing is dictated to anyone, a configuration option is simply to present individual users with a choice they can make themselves. I find it strange that so many people simultaneously ignore the reality of incentives to argue that an insecure means of receiving payments can be held safe against incentives, just as people argue that software users should not be allowed to choose how to configure their own software.
My node, my rules, right?
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.
