Bitcoin Core devs accused of forcing replace-by-fee transactions

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

Carvalho says the developers have used tactics like:

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

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

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

What makes RBF transactions different 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 hasn’t yet selected the low-fee transaction for inclusion in a block. The higher fee makes it more likely that a miner will select the transaction.

RBF transactions do come with one flaw. Senders can replace an unconfirmed transaction with one that has a higher fee and also replace the address that the transaction goes to. This flaw makes it possible for senders of a crypto payment to defraud merchants by sending the funds to another address controlled by the sender after the merchant delivers their purchase.

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

Bitcoin creator Satoshi Nakamoto appeared to anticipate 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 checking.”

Since then, 0conf transactions have seen adoption with payment processors like BitPay, which helped spread their use among merchants.

Members of the Bitcoin community argued that senders could still replace 0conf transactions before a miner adds it to a block. Attempts to solve issues with 0conf transactions included a proposal to add a Zero Confirmation Forfeit protocol that merchants could use to discourage theft. Zero Confirmation Forfeit transactions would have required putting up funds that would be forfeited if the sender attempts to double-spend the funds in the original transaction.

Carvalho argued that the decision on using RBF or 0conf transactions should be left at the superficial level. End users would ideally make the final decision instead of having it forced on them by Core developers. Wallet developers like Synonym could 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 templating for preference/curation/censorship of mempool txns, which templates to provide, and which to have as default.

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

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

“All of this is not to mention the many things I could say that are great about merchants being able to opt in to 0conf, and that the risks there are currently very manageable and exposure can easily be limited to provide great value to merchants and consumers.

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

Meanwhile, as all this is happening, some in the Bitcoin community are questioning whether it’s all part of some plan to distract from the recent LND bug on Lightning Network.