Bitcoin nodes don’t ‘vote’ on rule changes—but developers shouldn’t propose them

Getting your Trinity Audio player ready...

Dr. Craig S. Wright has reminded everyone that transaction processors, or “miners,” are not supposed to have a “vote” on which version of the protocol software to use. Updates ultimately are mandatory, and the only choice is between updating or leaving the network.

This becomes an important issue if BTC Core developers, who are only a small handful, decide to change how Bitcoin transactions are ordered or validated. This had happened a few times in the past, most notoriously in 2017 when Core developers implemented “segregated witness” (SegWit) signatures.

The question over what decisions miners can/can’t make arose again this week with the latest release candidate to BTC’s protocol software, version 24.0.

Remember, you don't vote in BTC or Bitcoin.

Devs set rules, users suck it up in BTC.

In Bitcoin, the protocol is set. https://t.co/mdpkDPQd12

— Dr Craig S Wright (@Dr_CSWright) November 28, 2022

Note that the ability for developers to make rule changes applies only to those using the BTC network. It does not apply to Bitcoin SV, the original Bitcoin protocol. With BSV, the fundamental transaction rules are “set in stone.” The rules may not be changed according to developers’ (or their financial/ideological sponsors’) whims.

If you record a transaction on the Bitcoin network today, it must still work and be valid hundreds of years into the future (if the Bitcoin network itself is still running). For everyone from ordinary spenders to enterprise-tier projects to use and build on Bitcoin, they must be able to trust that the rules won’t change; the goalposts can’t be moved; the ground can’t shift underneath them.

This is important for potential long-term transactions such as those involving trusts, business contracts, or tokenized assets. Bitcoin is a timestamped ledger of events where it’s essential to know what happened and exactly when. It would be dangerous to allow a handful of individuals, who can be influenced and/or compromised, to have the ability to decide policy.

Compare this to Ethereum, which over the past few years, has shifted the entire network from a secure proof-of-work (PoW) processing algorithm to proof-of-stake (PoS). Finally activated in 2022, this radically changes the economic incentives for validators on the network. Where previously the “miners” had to invest in physical hardware to participate, all that’s required now is a hefty sum of ETH to stake—and who knows whose ETH they’re staking?

Imagine you’d just deployed an enterprise-tier application on a network like that…and then a few years later, protocol developers decided to make changes that could potentially wreck your business model or force you to spend millions revising your own system. No one in their right mind would want to do it. It’d be like trying to do business in a country that changed its constitution and legal system every year or two.

This is why processors/nodes/miners shouldn’t be regarded as “reaching a consensus” or “voting” on changes, and why developers shouldn’t be proposing fundamental changes in the first place. Updates should address operating efficiencies or fixing bugs, making updates uncontroversial. Nodes simply enforce the rules.

BTC Core’s controversial update

But back to BTC. ‘Bitcoin’ Core’s 24.0 update, the latest in BTC’s six-monthly release schedule, introduces new rules regarding how processors (miners) decide which transactions should be validated. Specifically, it alters the rules for BTC’s “replace-by-fee” (RBF) handling mechanism that allows users to replace an existing (unconfirmed) transaction with another, presumably with a higher fee.

RBF exists on the BTC network because that network can only handle about 3-4 transactions per second worldwide. If your transaction gets “stuck” in the mempool of unconfirmed transactions for hours or days, you can increase the fee in the hope miners will process it faster than others.

Bitcoin Core 24.0 rules say that any transaction may now be replaced. Previously, RBF was optional when a transaction was initially sent. This could create problems for BTC businesses accepting zero-confirmation transactions or transactions that are still waiting to be confirmed—and in BTC, there are many of these.

#Bitcoin Core 24.0 was just released.

This one comes with a lot of controversy.

A new feature effecting big industry players, the networks scalability and security.

I'm talking about the mempoolfullrbf configuration option.

Let me break it down as simply as I can. 🧵 👇

— Thomas | heyapollo.com (@thomas_fahrer) November 25, 2022

As Dr. Wright has pointed out before, accepting transactions instantly with zero confirmations shouldn’t present any risks. RBF increases the risk of a double-spend attempt, as happened in one notable instance in January 2021.

What matters here, though, is that the controversy shouldn’t exist in the first place. Developers shouldn’t have the power to change important policies, and miners shouldn’t be expected to “vote” on them. Satoshi Nakamoto set out these expectations in the 2008 Bitcoin white paper as such:

“The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.”

Watch: The BSV Global Blockchain Convention panel, Tokenizing Assets & Securities on Blockchain