all about cryptop referances
Over the past few weeks, a number of people have discussed the upcoming release of Bitcoin Core version 24.0 and how the codebase will include full-replace-by-fee (RBF) logic. The discussion has become controversial as a few Lightning Network and zero verification advocates have expressed distaste for the idea of full RBF. Synonym CEO John Carvalho has been a vocal critic of the proposal on Twitter, and on November 3, Carvalho noted that a subset of Core developers “are currently trying to attack Bitcoin by forcing a pet agenda to make all transactions RBF by default.”
Ever since replace-by-fee (RBF) was introduced in 2014 by software developer Peter Todd, the topic has been a sensitive one. Essentially, RBF allows bitcoin users to exploit the feature to replace an unconfirmed transaction with an alternative transaction with an increased fee. However, once a transaction is included in a block, it cannot be replaced by RBF at that time. The scheme only works with zero-confirmation (0-conf) transactions (txns). Zero-confirmation transactions are transfers that can be accepted by a merchant or service via a network broadcast, well before a miner confirms the transaction in a block.
According to various reports, Bitcoin Core version 24.0 will provide full RBF logic, and the idea has led to more controversy. “Until now, Bitcoin Core nodes used the ‘first seen’ rule, which meant conflicting transactions would not be accepted into 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 have their nodes accept and forward conflicting transactions if they include a higher fee than (the) previous transaction(s) they are conflicting with.”
However, Bitcoin Magazine’s summary does not include the controversial arguments against full-RBF logic. A number of critics have said that transaction replacement damages the network and that it helps promote double-spending attacks. The double-spending attack claim has been argued since RBF was first introduced in Bitcoin Core version 0.12. In another summary of Bitcoin Core version 24.0, a Medium post published on October 29, the author mentions some of the critics and arguments against the full-RBF scheme. The author quotes the founder of the Lightning Network (LN) wallet Muun, Dario Sneidermanis.
“Over the past few days, we’ve been investigating the latest Bitcoin Core release candidate and we found some worrying facts about the deployment of opt-in full-RBF,” Sneidermanis explained. Muun’s CEO further added that “zero-conf apps (like Muun) must now immediately disable zero-conf features.” Sneidermani’s criticism of the proposed change continued:
We at Muun will have to turn off outgoing Lightning payments for more than 100,000 users, which is currently a good portion of all non-administrator Lightning payments.
The Medium post describing Bitcoin Core version 24.0 also mentions people who disagree with the Muun boss’s analysis. For example, Bitcoin Core developer David Harding says the upgrade “does not change transaction substitution in any significant way.” The blog post describes that “Pieter Wuile makes a similar argument,” and software developer Luke Dashjr has already implemented full-RBF logic in his software Bitcoin Knots codebase. A few days after the Medium post was published, the CEO of Synonym said, John Carvalhotweeted about the discussion and he included some accusations.
“A subset of Core developers are currently trying to attack Bitcoin by forcing a pet agenda to default all transactions to RBF,” Carvalho wrote November 3, 2022. “This attack includes bitcoin dev mailing list lies and lobbying, core node code changes, and attempted bribery of miners. Merchants rely on 0-conf txns as a way to meet consumer needs in commerce. RBF makes the mempool less reliable and the use of bitcoin more dangerous for consumers and businesses,” Carvalho added.
The more users there are using BTC, the more valuable it is.
— John Carvalho (@BitcoinErrorLog) 4 November 2022
Carvalho’s opinion was met with controversy and a 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 high value transactions in the future.” Carvalho black and insisted that “it’s not your decision how much risk is acceptable to someone else.” Another person told Carvalho as full-RBF “seems [like a] good incentive for LN and less L1 bloat. Intermediate time [obvious] pain for merchants. But non-RBF is never going to remain profitable for most sellers.”
Synonym CEO replied and stressed:
It is a claim and prediction that is in conflict with observable reality.
Same day, Carvalho asked people to prove that “Double spending was always easy and possible.” “Prove it,” said the Synonym boss. “[Double spend] on [Bitrefill], they literally want test samples.” The next day, Carvalho made sure of 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 stuck before, being able to RBF is easily the best experience for users.” Another person said that he believes 0-conf transactions are not secure and stated:
[NACK] zero-conf is not a safe, which makes it a bit harder to RBF is delusional.
Software developer Peter Todd has argued against Carvalho’s argument on Github as well, explaining that he was contacted by bitcoin miners. “I personally have recently been approached by miners asking how they can turn around [full RBF] on. Pointing them to a configuration option is obviously easiest for them,” Todd told Carvalho. Furthermore, Todd emphasized that there is a demand for the full RBF feature. “There is obviously a demand for this option,” Todd said. “It appears that the motivation to remove it comes from trying to make zero conf safer,” the software developer added.
The Github user who operates 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 flag mechanism for compensation by fee.
“As others have said, we could also compile Bitcoin core, but that would be a disadvantage and general I think [RBF] the flag provides a false sense of security, especially as we’ve recently seen that even non-standard transactions can find theirs [way] to miners. Broadly agree with afilini/ptodd/dbrozzoni’s points,” Greenaddress concluded. However, one person questioned the intent behind Greenaddress, saying it planned to “use this feature both personally as well as on production.”
“For what purpose?” the individual asked Green address on Github. “I haven’t seen an answer to ‘Do it.’ [full-RBF] offer benefits other than breaking [zero-conf] business practices? If so, what are they? Yet; Does the above mean you have one?”
What do you think about the controversy surrounding the whole RBF feature that developers have proposed to add to Bitcoin Core’s code base? What do you think of Sneidermani’s and Carvalho’s arguments against full RBF logic? Let us know what you think about this topic in the comments section below.
Image credit: Shutterstock, Pixabay, Wiki Commons
Disclaimer: This article is for informational purposes only. It is not a direct offer or solicitation of an offer to buy or sell, or an endorsement or recommendation of products, services or companies. Bitcoin.com does not provide investment, tax, legal or accounting advice. Neither the company nor the author is responsible, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with the use of or reliance on content, goods or services mentioned in this article.
