Bitcoin creator Dr. Craig S. Wright reminded everyone that transaction processors or “miners” don’t have to “vote” which version of the protocol software to use. Updates are ultimately mandatory and the only choice is between updating the network or exiting.
If only a small handful of BTC Core developers decide to change how Bitcoin transactions are ordered or confirmed, this becomes an important issue. This has happened several times in the past, most famously in 2017 when Core developers implemented “detached witness” (SegWit) signatures.
The question of what decisions miners can/cannot make came up again this week with the latest release candidate for BTC’s protocol software, version 24.0.
Remember, you are not voting in BTC or Bitcoin.
Devs set rules, users accept it in BTC.
A protocol is built on Bitcoin. https://t.co/mdpkDPQd12
– Dr Craig S Wright (@Dr_CSWright) November 28, 2022
Note that developers’ ability to make rule changes only applies to users of the BTC network. This does not apply to Bitcoin SV, the original Bitcoin protocol. Basic transaction rules with BSV are “set in stone”. The rules cannot be changed at the whims of the developers (or their financial/ideological sponsors).
If you record a transaction on the Bitcoin network today, it should still work and be valid hundreds of years into the future (if the Bitcoin network itself is still working). For everyone from casual spenders to enterprise-level projects to use and build on Bitcoin, they need to believe that the rules won’t change; the goalposts cannot be moved; the ground cannot slide under them.
This is important for potentially long-term transactions such as trusts, business contracts or tokenized assets. Bitcoin is a ledger with timestamps of events, which is important to know what happened and exactly when it happened. It would be dangerous to allow a few who could be influenced and/or compromised to have the ability to make policy decisions.
Contrast this with Ethereum, which over the past few years has transformed its entire network from a secure proof-of-work (PoW) processing algorithm to a proof-of-stake (PoS) algorithm. Finally activated in 2022, it fundamentally changes the economic incentives for validators on the network. Whereas before “miners” had to invest in physical hardware to participate, now all that’s required is a large amount of ETH to bet – and who knows whose ETH they’re getting?
Imagine you’ve just deployed enterprise-grade software on such a network… and a few years later, the protocol developers decide to make changes that could potentially destroy your business model or force you to spend millions to overhaul your system. No one in their right mind would want to do that. It would be like trying to do business in a country that changes its constitution and legal system every two years.
This is why processors/nodes/miners shouldn’t be considered to “reach consensus” or “vote” on changes, and why developers shouldn’t propose major changes in the first place. Updates should make updates non-controversial by eliminating operational efficiencies or bugs. Nodes simply enforce the rules.
BControversial update of TC Core
But back to BTC. The latest in BTC’s six-month release schedule, the ‘Bitcoin’ Core 24.0 update introduces new rules for how processors (miners) decide which transactions are approved. In particular, it changes the rules of BTC’s “replacement with payment” (RBF) management mechanism, which allows users to replace an existing (unconfirmed) transaction with another, possibly with a higher fee.
RBF exists on the BTC network, as this network can only handle 3-4 transactions per second worldwide. If your transaction is “stuck” in the cache of unconfirmed transactions for hours or days, you can increase the fee, hoping that miners will process it faster than others.
Bitcoin Core 24.0 rules say that any transaction can now be modified. Previously, RBF was optional when the transaction was initially sent. This can cause problems for BTC businesses that accept transactions with zero confirmations or transactions that are still waiting for confirmation, and BTC has a lot of these.
#Bitcoin Core 24.0 has just been released.
This comes with a lot of controversy.
A new feature that affects major industry players, network expansion and security.
I am talking about the mempoolfullrbf configuration option.
Let me make this as simple as I can. 🧵 👇
— Tom⚡ (@thomas_fahrer) November 25, 2022
Dr. As Wright mentioned earlier, accepting transactions immediately with zero confirmations should not pose any risk. The RBF raises the risk of an attempted double spend, as happened in a notable case in January 2021.
But what’s important here is that the argument shouldn’t exist in the first place. Developers should not have the power to change important policies and miners should not be expected to “vote” them. Satoshi Nakamoto expressed these expectations in his 2008 Bitcoin white paper:
“The web is robust in its unstructured simplicity. Nodes operate simultaneously with little coordination. There is no need to identify them, as messages are not forwarded to any specific destination and should only be delivered on a best-effort basis. Nodes can leave and rejoin the network at will, taking the proof-of-work chain as proof of what happened when they left. They vote with CPU power, signal acceptance by working on expanding valid blocks, and reject invalid blocks by refusing to work on them. With this consensus mechanism, any rules and incentives can be applied.”
See BSV Global Blockchain Convention panel, Tokenization of Assets and Securities on Blockchain
width=”562″ height=”315″ frameborder=”0″ allowfullscreen=”allowfullscreen”>
New to Bitcoin? Check out CoinGeek Bitcoin for beginners The section is the ultimate resource guide for learning more about Bitcoin and blockchain as envisioned by Satoshi Nakamoto.