Over the last week, many people discussed the forthcoming release of Bitcoin Core version 2.4.0. They also talked about how the codebase would include RBF logic. This has been controversial because some Lightning Network and Zero confirmation supporters have voiced disapproval for full-RBF logic. The CEO of Synonym, John Carvalho, has been a vocal critic of the proposal on Twitter and on Nov. 3, Carvalho remarked that a subset of Core developers “are currently trying to attack Bitcoin by forcing a pet agenda to make all transactions RBF by default.”
Bitcoin Core Version 24.0 to Offer Full-RBF Logic and Zero-Confirmation Lightning Network Supporters Speak Out Against the Proposal
Since the introduction of replace-by-fee in 2014 by Peter Todd (software developer), this topic has been controversial. RBF lets bitcoin users use it to confirm a transaction and replace it with another transaction at a reduced fee. RBF cannot override transactions that are already in blocks. This scheme works only with zero confirmation (0-conf), transactions (txns). Transactions with zero confirmation are transactions that can be accepted and confirmed by merchants or services via network broadcast, long before the miner approves it in a block.
It is believed that Bitcoin Core Version 24.0 will include full-RBF logic. The idea has caused more controversy. “Until now, Bitcoin Core nodes applied the ‘first seen’ rule, which meant that conflicting transactions wouldn’t be accepted in the node’s memory pool (mempool) and forwarded to peers,” a summary described by Bitcoin Magazine details. “With this upcoming release, users can choose to make their nodes accept and forward conflicting transactions if they include a higher fee than (the) earlier transaction(s) they conflict with.”
However, Bitcoin Magazine’s summary does not include the controversial arguments against full-RBF logic. There are many critics who claim transaction replacement damages the network and promotes double-spend attack. Since Bitcoin Core 0.12 was released, the double-spend attack claim has been debated. A Medium article published Oct. 29 also summarises Bitcoin Core version 2.4.0. The author discusses arguments and critics against the full-RBF system. Dario Seidermanis is the founder of Lightning Network (LN), a wallet.
“During the last few days, we have been investigating the latest Bitcoin Core release candidate, and we found some worrying facts about the deployment of opt-in full-RBF,” Sneidermanis explained. The Muun CEO further added that “zero-conf apps (like Muun) must now instantly disable zero-conf features.” Sneidermanis’ critique of the proposed change continued:
Muun must turn off Lightning outbound payments to more than 100,000 users. That is an excellent portion of all Lightning non-fiduciary payments.
Synonym CEO John Carvalho Says RBF Makes ‘Spending Bitcoin More Dangerous for Consumers and Businesses’
The Medium post describing Bitcoin Core version 24.0 also mentions people who disagree with the Muun CEO’s analysis. For instance, Bitcoin Core developer David Harding says the upgrade “does not change transaction substitutability in any significant way.” The blog post details that “Pieter Wuile makes a similar argument,” and software Developer Luke Dashjr has already implemented full-RBF logic in his software Bitcoin Knots codebase. The Medium post was posted a few days ago. Synonym’s CEO, John CarvalhoHe also tweeted about the topic and included accusations.
“A subset of Core devs are currently trying to attack Bitcoin by forcing a pet agenda to make all transactions RBF by default,” Carvalho wroteNovember 3, 2022. “This attack includes bitcoin-dev mailing list lies and lobbying, code changes in Core node, and bribery attempts to miners. Merchants depend on 0-conf.txns to fulfill consumer demands in commerce. RBF makes the mempool less reliable and spending bitcoin more dangerous for consumers and businesses,” Carvalho added.
BTC’s value will increase if there are more users who spend it.
— John Carvalho (@BitcoinErrorLog) November 4, 2022
Carvalho’s opinion was met with controversy and one user tweeted that “relying on 0-conf transactions doesn’t seem very smart when the majority of onchain transactions are only going to be very large value transactions in the future.” Carvalho responded and insisted that “it is not your decision what amount of risk is acceptable to someone else.” Another person told Carvalho that full-RBF “seems [like a]LN is a good motivator and L1 bloating can be reduced. Time interval [obvious]Pain for merchants. But non-RBF is never going to stay profitable for most merchants.”
Synonym CEO responded and stressed:
It is both a prediction and a claim that contradicts observable reality.
Strong Majority of No Votes Shoot Down Carvalho’s Argument, Peter Todd Says Miners Have Contacted Him Asking for Full-RBF
Carvalho also appeared that same day. asked people to prove that “Double spending was always easy and possible.” “Prove it,” the Synonym CEO remarked. “[Double spend]At [Bitrefill], they literally want test examples.” The following day, Carvalho provided his RBF “argument, and solution, simplified, without sensation.”
Carvalho’s argument published to Github was shot down by a large number of NACKs (Vote for No) and one person said: “As someone who has had transactions get stuck before, being able to RBF easily is the best experience for users.” Another person detailed that he believes 0-conf transactions are not safe and stated:
[NACK] zero-conf isn’t a safe, making it a tiny bit harder to RBF is delusional.
Software developer Peter Todd has been arguing against Carvalho’s argument on Github as well and explained that he was contacted by bitcoin miners. “I personally have been recently contacted by miners asking how they can turn [full RBF] on. Obviously, pointing them to a config option is simplest for them,” Todd told Carvalho. Furthermore, Todd stressed that there’s demand for the full RBF feature. “There’s obviously demand for this option,” Todd said. “Seems that the motivation to remove it comes from attempting to make zero conf safer,” the software developer added.
The Github user operating the handle “Greenaddress” wrote: “NACK. I planned to use this feature both personally as well as on production for example on esplora/blockstream.info and Green wallet.” Greenaddress further criticized the replace-by-fee flag mechanism.
“As others have said we can also compile Bitcoin core but it would be an inconvenience and in general I think the [RBF]Flag provides false security, especially since we have seen that even transactions not considered standard can be flagged. [way]To miners. Mostly agree with afilini/ptodd/dbrozzoni’s points,” Greenaddress concluded. One individual, however, questioned the purpose behind Greenaddress, saying that it planned to “use this feature both personally as well as on production.”
“For what purpose?” the individual Frequently Asked QuestionsGreenaddress is on Github. “I haven’t seen an answer to ‘Does [full-RBF]Any other than breaking [zero-conf]Are you a business practitioner? If so, what are they?’ Yet; does the above imply you have one?”
What do you think about the controversy surrounding the full RBF feature that developers have proposed to add to Bitcoin Core’s codebase? What do you think about Sneidermanis’ and Carvalho’s arguments against full RBF logic? Please comment below to let us know your thoughts on this topic.
Images CreditsShutterstock. Pixabay. Wiki Commons
DisclaimerThis information is provided for educational purposes only. This article is not intended to be a solicitation or offer to sell or buy any product, service, or company. Bitcoin.com doesn’t offer investment, tax or legal advice. The author and the company are not responsible for any loss or damage caused or alleged caused by the content or use of any goods, services, or information mentioned in the article.