Many of Bitcoin’s most active stakeholders have just determined the activation method for Taproot, the largest upgrade to Bitcoin software in years.
In a public meeting on Internet Relay Chat (IRC) on Tuesday, Bitcoin developers, miners, business people and enthusiasts explained the details of how the Taproot upgrade can be packaged into an update – and how it can be activated after the code has been sent .
The most active of the 200 or so participants in the chat (mostly, but not all developers) seemed to agree on the Bitcoin Improvement Proposal (BIP) that would be used to activate Taproot. To prepare GDP for shipping, 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 move forward with the upgrade .
Connected: Myanmar military blocks Facebook as global internet disruptions intensify
One of them, PR # 1021, contains a measure that allows users to force the upgrade to be enabled in case miners don’t support it, while PR # 1020 only “recommends” this enforcement but does not enable it by default. Since almost all participants support BIP 8 without forced activation, as the meeting leader and Bitcoin Core developer Michael Folkson noted in the chat, a date for the start of activation will be set in a further discussion – and the extent to which a “flag day” will Force activation is necessary.
Why a taproot flag tag is (probably) not needed
Not that miners blocking the upgrade should be an issue for Taproot, which has 91% support from F2Pool Vice President Alejandro De La Torre, according to a survey.
The survey provides important feedback from miners for the decentralized organization of Bitcoin, which cannot unilaterally coordinate updates like a central software provider. Upgrades like Taproot require careful coordination between miners, full node users (who run Bitcoin’s open source code), and other stakeholders to ensure nothing goes wrong (such as introducing a bug or splitting the Bitcoin network in two incompatible versions).
The story goes on
Since miners showed no resistance to taproot, most participants expressed a preference for BIP8 (false), where (false) referred to excluding a “flag day” to force activation by full nodes in case the upgrade was due to lack of miner activation fails.
Connected: Saylor, MicroStrategy Offers Playbook for Corporate Bitcoin Adoption at Annual Summit
BIP8, as it is currently being developed, would give Bitcoin miners and full node operators a year to undertake the upgrade. After that, the upgrade would be “blocked” with sufficient support. In one version of this, BIP8 (false), the update simply fails without adequate support. In another case, BIP8 (true), a “flag tag” would force miners to signal for the upgrade when the activation period expires if they have not done so before.
Tech Note: There are a few ways to upgrade Bitcoin. The simplest option is to carry out miner activations, where mining pools are updated according to the new rules and mining of blocks is started. Otherwise, node operators can upgrade and reject blocks from miners who have not signaled support for an upgrade. This so-called “User Activate Soft Fork” (UASF), which is also used to activate SegWit, would force holdout miners to adopt the new upgrade.
“Completely anecdotal, but I haven’t seen any [emphasis theirs] Opposition to Taproot ”, a willcl_ark said in the chat, referring to whether a flag day is necessary or not. “I think using the lowest common denominator of the activation parameters (false) seems like a sensible choice to avoid deliberate or accidental chain splitting in case miners don’t give a signal.”
Why the delay?
Still others, like prolific Bitcoin Core developer Luke Dashjr, are not convinced that including a flag day is not necessary. Indeed, it is a matter of principle to show that node operators choose software, not miners.
“It doesn’t matter,” he said in the chat regarding the miners’ support. “Miners don’t make decisions about protocol changes,” he continued, suggesting that it is the node operators who decide instead what software to run. He also advocated that BIP8 (incorrectly) “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 version (true), which rejects non-taproot blocks from miners.
“BIP8 with compulsory [activation] is not an unnecessary show of force, ”said hsjoberg, reiterating Dashjr’s belief that the choice of who to use a UASF is a necessary control and balance of miners’ apathy.
Still, a show of force could pose unnecessary risk and set an undesirable precedent for future upgrade considerations, especially if miners haven’t given users a reason to fight. So go to the arguments for BIP8 (false).
“[BIP8 false] is safer than [true]So it’s worth it [false] For the first time since we know that Hashpower is already 90% per taproot, ”said Chris Belcher, developer of Bitcoin Core and CoinSwap.
Others like Suredbits and Bitcoin Core developer Ben Carman pointed out that in case miners don’t signal, you could later configure the upgrade to include flag day, “making it safer and easier 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-enforced activation route (PR # 1020) and a forced activation route (PR # 1021). With these two rules in Bitcoin Core’s GitHub, the forced activation rules can only be used when needed.
The chain split scenario described by willcl_ark is basically the bogeyman that everyone here wants to avoid. It is feared that BIP8 (true) needs 100% of the hashrate to signal for the upgrade after the taproot activation period has expired. So if enough users have gone this route at the same time and others use BIP8 (false) for non-forced activation (which only requires 95% of the hashrate), the two different code versions can create two incompatible Bitcoin transaction book histories.
Therefore, if forced signaling is required at all, it is best to do so via AJ Townes’ PR # 1021, which “makes the UASF option, which is the” most dangerous “scenario, safer,” Carman wrote in the chat.
At the moment it seems like those involved in discussions would prefer BIP8 (wrong) with the addition of a UASF by PR # 1021, but further discussion is needed to get the exact timeline of the initial activation period (or how long users have ) find out the upgrade after the update goes live) and which activation date should be set.
These “what if” and “when” will be discussed in a meeting next Wednesday.