The latest Bitcoin Core update, 24.0, should force the use of the Replace-by-Fee (RBF) model, however a long discussion is taking place on the topic. Some people are even accusing the developers of attacks that include lying, lobbying and bribing miners. In short, RBF allows a transaction to be changed before it is committed. That is, you can pay a higher fee to change transaction data. Generally, this feature is used to speed up stuck transactions that, through carelessness, were entered with low fees. However, they can also be used to practice scams, changing the destination address. On the other hand, transactions without RBF — called 0conf or zeroconf (zero confirmations) — do not allow changes. Therefore, some services take advantage of these to confirm small deposits without depending on a confirmation on the blockchain, streamlining the entire process.
Bitcoin Core developers are accused by the community
The most serious accusations were made by John Carvalho, CEO of Synonym, who accused the developers of spreading lies to get the new model approved.
“Currently, a subset of Core developers is trying to attack Bitcoin by forcing an agenda to make all transactions RBF by default. This attack includes lies and lobbying from the bitcoin-dev mailing list, code changes to the Core node, and attempts to bribe miners.”
A subset of Core developers are currently trying to attack Bitcoin by forcing a pet schedule to make all RBF transactions by default. This attack includes bitcoin-dev mailing list lies and lobbying, code changes in Core node, and bribery attempts to miners. 1/5 — John Carvalho (@BitcoinErrorLog) November 3, 2022
Carvalho then also notes that Bitcoin users expect a function to work forever. That is, developers would be harming their current use cases. As an example, he cites the case of the Muun wallet, famous for allowing easy and uncomplicated access to the Lightning Network. Other services, such as Bitcoin ATMs and Bitrefill, a company that sells gift cards for BTC, would also suffer.
“We at Muun will have to disable outgoing Lightning payments for over 100,000 users, which is currently a good chunk of all non-Fiat Lightning payments”commented Dario Sneidernis, founder of the Muun portfolio.
Discussion also appears on GitHub
On GitHub, users also question the developers’ decision. One of them asks what would be the benefits of forcing the use of RBF, being quickly answered by defenders of the new model.
“Business and projects [que trabalham com] Zeroconf (zero commits) are vulnerable by design. This can be fixed without changing anything on Bitcoin Core”, commented one of them. Although the above statement is true, companies that work with this model claim that they assess the risk of each transaction and, above all, would be the only ones injured. Another who came out in defense of the RBF as a default was the controversial Peter Todd, a developer who defends that the limit of 21 million units of bitcoins be broken.
“Zeroconf is antithetical to trustless design and driven by Bitcoin economic incentives. It is a dangerous practice that has repeatedly bitten naive users leading to huge losses.”argues Peter Todd. “Any option that changes mempool policy breaks zeroconf if used by miners, because any difference in mempool policy can be exploited. mempoolfullrbf is not special and to claim the opposite is to be dishonest with users.”
Finally, it’s hard to imagine that forcing RBF will save the naive users mentioned by Todd. After all, these too can be fooled with the RBF, perhaps even more easily.
How many confirmations are needed?
Still on the subject, some experts suggest that the number of confirmations — for a transaction to be considered safe — depends on its value. As an example, if you are going to sell an item of 0.00046402 BTC (R$ 50), 1 confirmation would already be a good size, increasing to 3 in higher value items. In the case of trading a car or a house, this number would increase to 6 confirmations, as the amount is higher and there are more incentives for scams. So, with or without RBF, it’s nice to use the example above as a model, analyzing the risks. After all, no one wants to wait 1 hour for a payment of BRL 50 in BTC to be considered immutable.