A new Bitcoin development proposal states that network nodes should by default accept commission replacement or Replace-By-Fee (RBF), a functionality that is mainly used to incentivize fast confirmation of transactions by miners.
Fee replacement (RBF), as its name implies, allows that if a user sent a Bitcoin transaction, and this has not yet been confirmed, said transaction can be replaced by another that pays a higher amount of commissionto encourage miners to confirm it more quickly.
RBF is particularly useful in periods of high transaction congestion on the network. If at one point the average commission per transaction is 30 satoshis per byte (sats/vB), for example, and a user sent a transaction with a commission of 10 sats/vB, this same user would have the opportunity to increase the commission enough so that miners can take it into account in the short term.
RBF is not a quality included in all Bitcoin wallet applications by default. Some give the user the option to enable it, but ultimately, at this time, when a transaction is likely to admit an RBF, you have to signal it with an information bit within that transaction.
Also, RBF encounters some resistance among businesses and merchants that accept bitcoin. To receive a Bitcoin payment without confirmations from miners (0-conf), many businesses require that the payment transactions they receive do not have RBF activated, due to the risk that the customer purchases the product and then can redirect the transaction to their own wallet with RBF.
This is a type of fraud for which there are not enough incentives, so it is not frequent, but it is possible by this functionality.
Why accept RBF by default on Bitcoin nodes?
Bitcoin nodes accepting any RBF-type transaction by default has other goals, its proponents argue.
The default RBF proposal was submitted to the code repository of BitcoinCore by developer Luke Dashjr on June 14, 2022. Dashjr noted that this capability has been included in the Bitcoin Knots client since 2016.
It was also commented on by other programmers of that Bitcoin client, both in that repository and in the mail list from Linux Foundation developers.
The core of the argument is the possibility of a DoS (denial of service) attack on transactions involving 2 or more participantssuch as coinjoins (mixing of bitcoins), discrete registration contracts (DLC) or the opening and closing of Lightning network channels.
In theory, a group of attackers could use the RBF feature to send transactions that preempt the other transactions mentioned above, obstructing the different processes they seek to accomplish.
“There is an easily executable DoS attack vector against the funds of such transactions [DLC, coinjoins, canales de Lightning, etc.] due to the lack of a topology to fully accept RBF transactions in the P2P network. While this does not lead to direct loss of funds, if executed well it can be annoying enough to inflict a significant loss of time or commission on future providers. [de servicios] or users who make transactions by pooling their funds with each other […]».
Antoine Riard, Bitcoin Core developer.
For his part, John Carvalho, also a developer of Bitcoin Core and CEO of Synonym, opposed the proposal pointing out the risks against the use of Bitcoin.
“I do not recognize this proposal. This takes the ability to do RBF by default too far, and eventually preempts the normal and original use of Bitcoin, and creates uncertainty and choice for merchants about accepting 0 confirmation payments at their own risk tolerance. I appreciate that RBF is off by default, but RBF isn’t generally a widely used capability (although some apps have it turned on by default) and doesn’t deserve your constant push towards making it a cultural norm.”
John Carvalho, CEO of Synonym.
Earlier this year, other Bitcoin developers considered enabling RBF by default, also without coming to a final change agreed upon by consensus.
To this day, this proposal continues to be commented and discussed by Bitcoin developers, with what seems to be a majority positive reception. However, it has not yet been established when it would begin to be part of the Bitcoin Core code.