Bitcoin Core developers accused of forcing transactions with replacement after fee

Synonym CEO John Carvalho has accused a number of Bitcoin Core developers of trying to force Bitcoin to accept replacement-by-fee (RBF) transactions by default. Their proposal would change Bitcoin’s core protocols instead of letting users decide whether to use RBF transactions or zero-confirmation (0conf) at the surface level.

Carvalho says developers have used tactics such as:

• Spreading lies and lobbying tactics over the Bitcoin-Dev mailing list,
• introduces changes to Bitcoin Core’s node code, and
• bribing miners to support RBF.

RBF transactions can replace the 0conf transaction protocols used by most merchants. Carvalho says Synonym supports efforts to make 0conf transactions more resistant to double-use attacks, and he accused developers who value RBF of trying to protect niche, limited-use designs.

0conf transactions are also called ‘unconfirmed transactions’ or ‘proposed transactions’ and by definition, is not included in any block in Bitcoin’s blockchain.

What differentiates RBF transactions from 0conf transactions?

Replace-by-fee can speed up the confirmation of a transaction by replacing an unconfirmed transaction with a low-fee transaction that includes a higher fee. This type of transaction only works when a miner has not yet selected the low-fee transaction for inclusion in a block. The higher fee makes it more likely that a miner will choose the transaction.

RBF transactions come with one error. Senders can replace an unverified transaction with one that has a higher fee and also replace the address to which the transaction goes. This bug does possible for senders of a crypto payment to defraud merchants by sending the money to another address checked by the sender after the seller has delivered the purchase.

Zero-confirmation transactions make it possible to use digital assets without waiting 10 minutes for a transaction to start confirming. A sender can broadcast a transaction and trust the merchant to accept the funds if it appears to be valid at a glance. Merchants favor 0conf transactions because they can transact business as quickly as if the buyer swiped a debit card.

Bitcoin creator Satoshi Nakamoto seemed to foresee 0conf transactions in 2010 when he postulated a “Bitcoin Snack Machine” — a vending machine that could accept transactions in 10 seconds or less with “good enough control.”

Since then, 0conf transactions have see adoption with payment processors such as BitPaywhich helped spread its use among merchants.

Members of the Bitcoin community claimed that senders could still replace 0conf transactions before a miner adds it to a block. Attempts to address problems with 0conf transactions included a proposal to add a Zero Confirmation Forfeit protocol that merchants could use to discourage theft. Zero Confirmation Lost transactions would have required setting up funds that would be lost if the sender attempted to duplicate the funds in the original transaction.

Carvalho argued that the decision to use RBF or 0conf transactions should lie at a superficial level. End users would ideally make the final decision rather than having it forced upon them by Core developers. Wallet developers like Synonym may add options for RBF and/or 0conf transactions.

Read more: This Bitcoin Core update will protect full node operators from hacks

In a post published to GitHub earlier today, Carvalho said: “If I understand correctly, the meta topic here seems to be painting preference/curation/censoring of mempool txns, which templates to provide and which to must have as standard.

“Replacement is just one option a node may prefer… It is up to the individual node to decide.

“We shouldn’t inject bias for any particular preference by default, but we probably need to start with some kind of policy, so this should be set to the current status quo consensus, not a new agenda for RBF to become a first-class default type.

“All this is not to mention the many things I can say that are good about sellers being able to sign up for 0conf, and that the risks there are currently very manageable and exposure can easily be limited to provide great value for sellers and consumers.

“We can have RBF and 0conf coexist, well, we already do! So let’s be thoughtful and address the overall design intelligently and without passively attacking or deciding for users in conflict with the current consensus. Thanks!”

Meanwhile, while all this is happening, some in the Bitcoin community are questioning whether it is part of a plan to distract from the recent LND failure on the Lightning Network.