The code for Taproot, Bitcoin’s biggest upgrade in years, is finalized and has been packaged into a forthcoming update. Only, it’s not ready to be deployed yet because Bitcoin developers have differing opinions on the best route to activation.
Taproot will enhance Bitcoin’s smart contract capabilities by implementing a new digital signature scheme, Schnorr. Implementing the upgrade requires a “soft fork” of Bitcoin’s code, and there are a few competing proposals for how to activate it.
In a bid to expedite implementation discussions, Bitcoin Core contributor A.J. Towns recently surveyed 12 other developers who have been active in the implementation process to glean their thoughts on what activation should look like.
Related: Market Wrap: Bitcoin Tests $13.6K as DeFi Total Value Locked Dips Below $11B
Read more: Bitcoin’s Future: Exactly How a Coming Upgrade Could Improve Privacy and Scaling
The results of the survey show that, while developers are generally aligned when it comes to the big picture of Taproot’s activation, they disagree on the details. As they debate the finer points, the developer’s conservative, careful deliberation may seem like nitpicking to outsiders.
But it shows that so-called “soft-fork” upgrades like Taproot are not entirely riskless events – and that the specter of the controversial Segwit soft fork has haunted discussions.
Taproot activation proposals, explained
The Segwit transaction load increase was Bitcoin’s last soft fork, or an upgrade that is “backwards compatible,” meaning software running the old version of the code can still interact with the upgraded version.
Related: Ethereum Developers Pencil In January for Eth 1.x ‘Berlin’ Hard Fork
Segwit’s activation was anything but smooth and relied on tweaks along the way after miners failed to adopt the upgrade in its first year. To keep the upgrade from failing, a new implementation proposal was adopted in the middle of the activation process. In an effort to put pressure on miners to upgrade, one proposal even suggested that node operators – those Bitcoin users who run Bitcoin’s software and keep a copy of its ledger – reject transactions from the miners who hadn’t updated to SegWit to expedite its adoption.
Read more: Taproot Has Been Merged Into Bitcoin Core: Here’s What That Means
In a perfect world, both node users and miners would upgrade simultaneously to ensure no conflict would “split” the chain – or result in two rival factions supporting two different versions of Bitcoin’s code.
Even though Taproot is a non-controversial upgrade, the memory of Segwit is making developers cautious when evaluating this latest upgrade.
Two proposals
Two of the leading implementation proposals for Taproot rely on a mix of miner signaling and user activation. BIP 8, introduced in 2017 by Bitcoin developers Luke Dashjr and Shoalinfry, would include a signaling period for miners; if enough miners don’t activate to reach consensus on the upgrade, then a “flag day” for activation would automatically upgrade Bitcoin nodes that have downloaded v0.21 of Bitcoin Core.
These nodes would reject blocks and transactions from miners who do not support Taproot, so in theory, this method would incentivize miners to adopt the new ruleset lest they lose out on profits.
In a second Taproot implementation proposal, Core developer Matt Corallo’s Modern Softfork Activation, fuses BIP 8 with BIP 9 (the latter being the proposal originally adopted to activate Segwit but which proved inadequate).
Corallo’s hybrid model first includes a one-year signaling period for miners. Second, if a super-majority of miners does not update during this timeframe, then the upgrade would be subject to a six-month review to make changes (if any) to the proposal.
The third and final step is a BIP 8-style activation period of two years, with a non-mandatory flag-day for node users to activate the update.
What Bitcoin developers think
For the first question in his survey, AJ Towns asks developers what percentage of miners need to signal an upgrade for it to be considered a safe majority. Eight believe that nothing less than 85%-95% would be sufficient. The thinking is that anything less threatens a network “split” where some miners run the older code and some the newer code, which would create two conflicting transaction histories.
Failing a miner-signalled activation, seven respondents think a flag day for node-enforced activation could come as soon as 12-18 months after activation begins. If too few miners adopt the upgrade, this would mean nodes could enforce the Taproot ruleset and only accept blocks from miners who also signaled for the upgrade.
In a perfect world, both node users and miners would upgrade simultaneously to ensure no conflict would “split” the chain – or result in two rival factions supporting two different versions of Bitcoin’s code.
Almost all of the developers surveyed want to wait to see if miners and users adopt the upgrade on their own before deciding on a hard date for flag day (if there’s enough early support, a flag day may not be necessary at all).
If activation doesn’t come to pass through voluntary activation, then a flag day activation is the last option on the table. Most respondents were in favor of a mandatory flag day to automatically signal the update. This would mean updated nodes would reject blocks from miners who haven’t signaled for the upgrade.
Disagreements on the finer details
So-called forced signaling through the flag day would have the benefit of making Taproot default on any Bitcoin Core node running v.21; in turn, these nodes would only accept block data from miners who have also signaled the update, so in theory this would encourage miners to upgrade lest they lose their business.
But what if the miners have node users who do accept their blocks?
This is one caveat to forced signaling: If too many miners and node users don’t accept Taproot and refuse to update their software, then the network could split into two competing chains. If enough economic interest backs the “old” version of Bitcoin, then the result could be two competing assets.
This outcome is partly why some developers, like Matt Corallo, think that forced signaling is unnecessary.
Since Taproot has been largely uncontroversial, it would be a political risk to force signal the upgrade, he argues. He considers the activation method a relic of Segwit’s “user-activated soft fork,” a proposal to activate Segwit through similar means after miners failed to adopt the upgrade. Segwit was very controversial and political. Taproot is not, but Corallo believes enforced signalling threatens to make it that way.
In his post, Towns writes the mandatory signaling would be a way to definitively enforce Taproot’s network-wide activation after enough consensus has been established through discussion and miner support.
“If you want to maximize the number of nodes that will enforce the rules should a flag day occur, but also only choose the flag day after an initial activation attempt is already widely deployed, then you have no choice but to make signaling mandatory when the flag day occurs,” Towns writes.
What’s the holdup?
Towns introduces an alternative activation proposal in the survey which features a four-year activation time frame. As ever in Bitcoin development discussion, this, too, received some pushback.
“Once the decision to activate has overwhelming support from developers and users, the longer the timeframe for activation (beyond that practically required for miners to safely upgrade) the more things that can go wrong,” former Bitcoin Core developer Eric Lombrozo said to Towns on Twitter.
Risks aside, if most developers and Bitcoiners think Taproot is a shoe-in for an upgrade, it shouldn’t take four years to activate, especially since it has already been so-long in the making.
After all, if Taproot’s been in the works since 2018, shouldn’t miners and node operators know what to expect?
As Blockstream CEO Adam Back put it on Twitter, “Taproot can’t be a surprise after several years.”
Related Stories
