Consesensus on How to Activate Bitcoin’s Taproot Upgrade is Close

Many of Bitcoin’s most active stakeholders have just about nailed down the activation method for Taproot, the Bitcoin software’s biggest upgrade in years.

In a public meeting on Internet Relay Chat (IRC) Tuesday, Bitcoin developers, miners, business professionals and enthusiasts hashed out the specifics of how to package the Taproot upgrade into an update – and how to activate it once the code has been shipped.

The most active of the 200 or so participants on the chat (mostly, but not all, developers) seemed to agree on the Bitcoin Improvement Proposal (BIP) that would be used to activate Taproot. To prep the BIP for shipment, they also voted to “merge” two “pull requests” (PRs) on GitHub that outline the rules for Taproot’s activation logic into Bitcoin’s source code when the time comes to push the upgrade.

One of these, PR #1021, includes a measure to allow users to force activate the upgrade should miners not support it, while PR #1020 only “recommends” this forcing but does not enable it by default. Since most all participants support BIP 8 without forced activation, as meeting leader and Bitcoin Core developer Michael Folkson noted in the chat, further discussion will pinpoint a date to begin activation – and further discuss the extent to which a “flag day” to force activation is necessary.

Not that miners blocking the upgrade should be an issue for Taproot, which has some 91% miner support, according to a survey run by F2Pool VP Alejandro De La Torre.

The survey provides crucial feedback from miners for Bitcoin’s decentralized organization, which cannot unilaterally coordinate updates the way a centralized software provider can. Upgrades like Taproot require painstaking coordination between miners, full-node users (those running Bitcoin’s open-source code) and other stakeholders to ensure nothing goes wrong (like introducing a bug or splitting the Bitcoin network into two incompatible versions).

Because miners have shown no resistance to Taproot, most participants voiced a preference for BIP8 (false), with the (false) referring to the exclusion of a “flag day” to force activation through full nodes should the upgrade fail through lack of miner activation.

BIP8 as currently devised would give Bitcoin miners and full-node operators a year to adopt the upgrade, after which point the upgrade would be “locked in” with enough support. In one version of this, BIP8 (false), the update simply fails without enough support. In another, BIP8 (true), a “flag day” would force miners to signal for the upgrade when the activation time frame expires if they did not do so beforehand.

Technical note: There are a few ways to upgrade Bitcoin, the easiest being through miner activation where mining pools upgrade and begin mining blocks under the new rules. Failing this, node operators can upgrade and choose to reject blocks from miners who have not signaled support for an upgrade. This so-called “user activate soft fork” (UASF), also used to activate SegWit, would force holdout miners to adopt the new upgrade.

“Completely anecdotal but I’ve not seen any [emphasis theirs] opposition to Taproot,” one willcl_ark said in the chat, referring to whether or not a flag day is necessary. “I think using the lowest common denominator of activation parameters (false) seems like the sensible choice to avoid any purposeful or accidental chain splits in the case miners don’t signal.”

Still others, like prolific Bitcoin Core developer Luke Dashjr, are not convinced the inclusion of a flag day is unnecessary. In fact, it’s a matter of principle to demonstrate that node operators decide software, not miners.

“It doesn’t matter,” he said in the chat in reference to miner support. “Miners do not decide protocol changes,” he continued, intimating that it’s the node operators who decide instead by choosing what software to run. Further, he espoused that BIP8 (false), “let[s] miners decide” the fate of the upgrade. When the time comes, he said later in the chat, he will configure his node to run the BIP8 (true) version that rejects non-Taproot blocks from miners.

“BIP8 with mandatory [activation] is not an unnecessary show of force,” said hsjoberg, reiterating Dashjr’s belief that the user-choice of a UASF is a necessary check and balance on miner apathy.

Still, a show of force could introduce unnecessary risk and set an unwelcome precedent for future upgrade deliberations, especially when miners have given users no reason to be combative, so go the arguments in favor of BIP8 (false).

“[BIP8 false] is safer than [true], so it’s worth doing [false] first given that we know hashpower is ~90% already pro-Taproot,” Bitcoin Core and CoinSwap developer Chris Belcher said.

Others like Suredbits and Bitcoin Core developer Ben Carman pointed out that you could configure the upgrade later on into activation to include the flag day should miners fail to signal, “making it safer and easy for users to enforce the UASF.”

At the end of the meeting, the participants agreed to merge pull requests on GitHub for both a non-forced activation route (PR #1020) and a forced activation route (PR #1021). With both of these rules in Bitcoin Core’s GitHub, the rules for a forced activation could be used only if necessary.

The chain split scenario that willcl_ark described is basically the bogeyman everyone wants to avoid here. The fear is that BIP8 (true) requires 100% of hashrate to signal for the upgrade after the Taproot activation deadline ends. Thus, if enough users went this route at the same time that others use BIP8 (false) for non-forced activation (which only requires 95% of hashrate), the two different code versions may create two incompatible histories of Bitcoin’s transaction ledger.

That’s why, if forced signalling must happen at all, it’s best to do so through AJ Townes’ PR #1021, which “makes it safer for the UASF option which is the most ‘dangerous’ scenario,” Carman wrote in the chat.

For now it seems as if those involved in discussions favor BIP8 (false) with the addition of a UASF through PR #1021 if needed, but further discussion is needed to hammer out the exact timeline of the initial activation period (or how long users have to upgrade after the update goes live), as well as what activation date to set.

These “what ifs” and “whens” will be hashed out, among other matters, in a meeting next Wednesday.