During the last few weeks, a number of individuals have been discussing 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 confirmation advocates have expressed a distaste for the full-RBF idea. 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.”
Ever since replace-by-fee (RBF) was introduced in 2014 by software developer Peter Todd, the topic has been a sensitive subject. Essentially, RBF allows bitcoin users to leverage the feature in order to replace an unconfirmed transaction with an alternative transaction with an increased fee. However, when a transaction is included in a block, it cannot be superseded by RBF at that point. 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 fueled 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. A number of critics have said that transaction replacement harms the network, and that it helps promote double-spend attacks. The double spend attack assertion has been argued since RBF was first introduced into Bitcoin Core version 0.12. In another summary of Bitcoin Core version 24.0, a Medium post published on Oct. 29, the author mentions some of the detractors and arguments against the full-RBF scheme. The author quotes the founder of the Lightning Network (LN) wallet Muun, Dario Sneidermanis.
“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:
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. A few days after the Medium post was published, the CEO of Synonym, John Carvalho, tweeted about the discussion and he included some 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 wrote on Nov. 3, 2022. “This attack includes bitcoin-dev mailing list lies and lobbying, code changes in Core node, and bribery attempts to miners. Merchants rely on 0-conf txns as a way to meet consumer needs in commerce. RBF makes the mempool less reliable and spending bitcoin more dangerous for consumers and businesses,” Carvalho added.
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] good incentive for LN and less L1 bloating. Intermediate time [obvious] pain for merchants. But non-RBF is never going to stay profitable for most merchants.”
The Synonym CEO replied and stressed:
The same day, Carvalho 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:
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 a false sense of security especially as we seen recently even non-standard transactions can find their [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 asked Greenaddress on Github. “I haven’t seen an answer to ‘Does [full-RBF] offer any benefits other than breaking [zero-conf] business practices? If so, what are they?’ Yet; does the above imply you have one?”
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
