Bitcoin Developers Divided on Specifics of Taproot Activation – Coindesk

The code for Taproot, Bitcoins biggest upgrade in years, is finalized and has been packaged into a forthcoming update. Only, its not ready to be deployed yet because Bitcoin developers have differing opinions on the best route to activation.

Taproot will enhance Bitcoins smart contract capabilities by implementing a new digital signature scheme, Schnorr. Implementing the upgrade requires a soft fork of Bitcoins 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.

The results of the survey show that, while developers are generally aligned when it comes to the big picture of Taproots activation, they disagree on the details. As they debate the finer points, the developers 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 Bitcoins 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.

Segwits 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 Bitcoins software and keep a copy of its ledger reject transactions from the miners who hadnt updated to SegWit to expedite its adoption.

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 Bitcoins 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 dont 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 Corallos Modern Softfork Activation, fuses BIP 8 with BIP 9 (the latter being the proposal originally adopted to activate Segwit but which proved inadequate).

Corallos 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 Bitcoins 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 theres enough early support, a flag day may not be necessary at all).

If activation doesnt 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 havent 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 dont 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 Segwits 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 Taproots 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.

Whats 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 shouldnt take four years to activate, especially since it has already been so-long in the making.

After all, if Taproots been in the works since 2018, shouldnt miners and node operators know what to expect?

As Blockstream CEO Adam Back put it on Twitter, Taproot cant be a surprise after several years.

Read more from the original source:
Bitcoin Developers Divided on Specifics of Taproot Activation - Coindesk