Bitcoin Coders Confront an Old Quandary: How to Upgrade an Entire Network

An old debate is resurfacing in the Bitcoin developer community, underscoring one of the critical challenges facing decentralized systems: how to update the software when ostensibly no one’s in charge.

The catalyst this time is called Taproot/Schnorr, a years-in-the-making privacy and scaling upgrade that’s seen exciting progress recently, especially now that the code in the form of a “pull request” is being reviewed and tested, bringing a change first discussed years ago closer to reality.

The code change itself isn’t controversial among developers so far. What is up for discussion is the best way to activate the change, making it finally possible to send Bitcoin (BTC) transactions in this new way.

At the heart of why there’s a question about this at all is that Bitcoin has no leader and is distributed across the globe. How does the whole network smoothly upgrade in a way that’s backward-compatible, allowing those with older versions of the software to continue participating? What’s the best way for Bitcoin to make this type of change without disruption?

To be clear: Bitcoin‘s code is updated almost every day by the open-source project’s global web of developers. But “consensus” code changes, which strike at a deeper part of Bitcoin, require a “soft fork,” which in turn requires a certain amount of coordination to go through smoothly.

“There are a series of soft-fork designs which have recently been making good progress towards implementation and future adoption. However, for various reasons, activation methods … have gotten limited discussion,” Bitcoin Core contributor Matt Corallo wrote in an email to the Bitcoin developers’ list last month that reopened the debate.

There are two main options for enacting a soft fork. One option, Bitcoin Improvement Proposal (BIP) 9, has been used for a few soft forks in the past. It ensures the miners are prepared in advance of a soft fork, to make sure a change smoothly ripples throughout the network. A common objection to this approach is that it gives miners too much power.

Alternatively, there’s BIP 8, also known as the user-activated soft fork (UASF), which activates regardless of whether miners signal they are ready or not. Depending on execution, this approach could cause other problems, Corallo cautioned.

History lesson

The discussion started in 2017, when BIP 9 was used to activate Segregated Witness, or SegWit, a change integral to Bitcoin‘s great scaling debate. To protect miners from mining invalid blocks and losing money, SegWit would not activate until 95 percent of miners raised a flag showing they were ready.

The majority of mining pools (groups of miners who combine their computational power on the network) declared they would not back SegWit – essentially vetoing it – unless it was paired with an increase in the block size parameter. (Bitcoin’s mysterious creator had set the ceiling at 1 megabyte, limiting the number of transactions that could be stuffed into blocks, which are published every 10 minutes or so.)

This was a controversial demand that many believed could lead to the centralization of the network (and couldn’t be executed successfully unless Bitcoin were centralized, anyway).

Long story short, the incident showed mining pools could use the 95 percent threshold to extract other changes instead of the intended purpose: to help them ease into the change so they wouldn’t lose money.

Many Bitcoiners did not like this, seeing it as miners trying to use their power to push through a change not all users wanted.

As this debate raged on, a mysterious developer going by the handle Shaolinfry pointed out that Bitcoiners could still make the upgrade. The root of the idea is that Bitcoin users and exchanges should decide whether a change should go through, and miners would follow their desires – not the other way around. This method had been used to activate other Bitcoin changes. Shaolinfy formalized this idea in BIP 8, otherwise known as a UASF.

A large swath of users loudly declared support for the SegWit UASF on social media and began running the software. This seemed to have the desired effect. Before the day the UASF would activate, miners started flagging support for SegWit.

Notably, there were a couple of flavors of UASF circulating during this tumultuous time, one more cautious (and more conservatively timed) and less controversial than the other. But without getting into the weeds, the takeaway for some Bitcoin developers was that UASF was a better way to enact changes.

At the time, Rusty Russell, a developer at Bitcoin startup Blockstream, went as far as to apologize for playing a part in constructing BIP 9.

“I hadn’t expected that this checkpoint would be used as a chokepoint to ransom the network. This significantly changes the risk model; BIP-8 is now a far superior method for network upgrades, where miners can only accelerate the process, not block it,” he wrote in a Medium post.

Long memories

Remembering all this drama, some…

Article Source…