• Bitcoin miners, who account for around 91% of the network’s hash power, have shown that they support Bitcoin’s largest upgrade in years, Taproot.
  • These activation methods vary the length of time required and whether to include any action that would force the upgrade through full nodes with a user-activated soft fork.
  • Given the support from miners, Bitcoin developers believe that regardless of the proposal selected, the upgrade should be activated without a hitch.

Now that most of the major mining pools have promised to support Bitcoin’s Taproot upgrade, all that remains is the actual activation – but members of the Bitcoin open source community must first select the method.

There are currently a handful of proposals vying for attention among Bitcoin stakeholders. In summary, some of these activation times take longer than others, and others allow the upgrade to be “forced” by full node activation if miners don’t put their hashrate where their mouth is when the time comes.

Bitcoin Upgrade: Multiple Paths to One Destination

Taproot, the largest upgrade of Bitcoin in half a decade, will enrich Bitcoin’s smart contract scripts and make it easier to execute highly complex transactions on the Bitcoin blockchain. Among other things, this improves the multi-signature software and data protection for the network.

(Anna_Ieni / iStock / Getty Images Plus, modified by CoinDesk)

Bitcoin developers have suggested several ways to start the upgrade, but all of them rely on a version of Bitcoin Improvement Proposal 8 or Bitcoin Improvement Proposal 9 (BIP8 and BIP9 for short). Each proposal is similar but offers slightly different approaches to enabling the upgrade, which requires both Bitcoin miners and node operators to work together smoothly.

There are two major versions of BIP8 that vie for attention: A version called BIP8 (true) contains a “flag tag”. At this point, the update will be forced through full node activation even if miners do not take it over. and a version called BIP8 (false) where the upgrade simply fails if miners don’t take it over. “True” indicates that GDP contains forced activation, while “False” indicates a version of GDP that does not have forced activation.

Why the addition of forced activation, you might ask? One concern in the activation discussions was whether or not mining pools would undertake the upgrade, given the reluctance of miners to hinder the activation of SegWit in 2016 and 2017.

Mining pools, which account for around 91% of Bitcoin hashrate, have announced their support for the upgrade as part of an initiative led by Alejandro De La Torre, a vice president of Bitcoin mining company Poolin. Torre said Poolin’s finding from the survey was that “BIP9 is the cheapest choice” to activate.

Bitcoin cannot detect the time, so BIP9 assigns a signaling period that is measured against Bitcoin’s block time (a predefined period of time is measured using Bitcoin’s block map, which can be irregular). If enough miners take over the upgrade during this period, it will be banned and considered successful. If this threshold is not met, the upgrade will fail.

Bitcoin miner support could mean easier activation

With miners behind the upgrade, BIP9 could be the fastest and easiest way to activate it, Ben Carman, a bitcoin developer who helped verify the Taproot code, told CoinDesk.

“In the beginning I was for BIP8 because I was concerned that miners might block the upgrade. However, with things like taprootactivation.com, I went with BIP9. It seems we basically have everyone on board to do the upgrade, and BIP9 would be the easiest and only requires a few lines of code to get started. Other methods would require major code changes to implement new activation logic. “

The other activation methods that Carman mentions, the different versions of BIP8, are similar to BIP9 without significant changes: BIP8 contains an option to force the update by a “flag tag” if the miner signaling fails (this option would be used with BIP8 used [true] Activation method). In addition, a minor change measures activation time based on block height, rather than BIP9 using block times.

This change means that if miners don’t take over Taproot, the update can be forced by full node activation at some point with BIP8 (true) or the upgrade can be stopped with BIP8 (false) and continued later.

However, if not enough miners take over the upgrade during the signaling period for BIP9, the process will fail and must be restarted from the beginning.

The BIP9 style activation could come from BIP8

BIP9 has been used in the past for Bitcoin soft forks (upgrades compatible with previous software versions). It was originally used to enable the SegWit upgrade, but not enough miners were signaled for the update so other means were required. If, according to this scheme, not enough miners support an upgrade, the signaling period just expires and the process can be repeated.

Jonas Nick, a Bitcoin Core developer who was one of the main people responsible for Taproot, told CoinDesk that “BIP9-style activation is the least disruptive path and therefore a reasonable choice,” but that it most likely came from BIP8, which is why this route is referred to as the “BIP9 equivalent”.

Assuming that the upgrade is applied during the signaling period, the upgrade is performed as described in BIP9 (i.e. via full miner support) but using BIP8’s activation logic which measures the activation window over block times and is easily retried can if the upgrade fails.

That’s why Nick, although “no one can say for sure,” believes that the suggestion from Taproot development colleagues, leading AJ Townes’ suggestion (a slight modification of the so-called “gently discouraging apathy” route), could win.

The details and schedules of the competing activation proposals from Taproot (Alejandro De La Torre / Screenshot / Github)

Taproot ‘Flag Day’

Under this program, miners would have a year to signal the upgrade. If miners present 95% of Bitcoin’s hash stream signals for the upgrade during this period, Taproot will be activated without further action. If not, the update will undergo a period of review in which developers and miners work together to iron out the kinks.

After this period has expired, a “flag tag” is encoded into the update to force the upgrade through mandatory signaling, whereby node operators only accept blocks from miners who support Taproot. This would effectively be a “User Activated Soft Fork” (UASF), the same method proposed to activate SegWit, although the method proved unnecessary as miners adopted the update after the UASF proposal gained momentum. This method is known as “forced activation”.

By giving miners ample time to upgrade, but also maintaining a flag tag just in case, the proposal is intended to discourage miners from “not upgrading out of laziness,” Dustin Dettmer, developer of KoinKeep’s Bitcoin wallet, told CoinDesk.

Townes outlined what this proposal would look like, but the code for it was not included in the Bitcoin software. The method includes BIP8 (false) so this code would need to be checked and inserted into Bitcoin Core first, Nick said.

Taproot: Rooted in Risk?

While Nick and Townes are advocating the modified BIP8 implementation, Matt Corallo, another reviewer of the Taproot code, believes the activation method is too risky, even with miners mostly on board.

“The forks in Bitcoin define, for better or worse, the process and yardstick by which future changes will be made and assessed,” he told CoinDesk. The SegWit block size wars set “an incredibly high standard” for “easy changes at first sight”[s]“Made with Bitcoin’s software – with conservative considerations that take as little risk as possible.

Corallo believes that the mandatory flag day activation method proposed in other methods is unnecessarily bold and indicates too much influence from the Bitcoin developer community unless all other activation methods are exhausted.

“Throw some of the proposed activation methods that are discussed [the lessons learned from SegWit] This is a visible precedent for Bitcoin to be changed with almost only one developer buy-in and a forced and slightly riskier activation, opening the door to re-engagement with years of debate. “

Corallo doubts activation [will] be a problem, ”but he concluded by saying,“ I see no reason to take this risk unless all other options have been tried. “

Corallo’s own Modern Activated Soft Fork (MASF) offers its alternative and takes parts of both BIP8. This activation path includes a one-year signaling period for miners. If not enough miners are upgraded during this period, the upgrade will be paused as per BIP8 (false) for a six month review to make changes (if any) to the proposal.

If Taproot still does not have enough support after this point in time, a period of two years begins during which node operators can postpone the update with a non-mandatory opt-in flag tag. In contrast to a mandatory option that would force Taproot to be activated on all nodes running the latest version of Bitcoin on flag day, Taproot would only run on those nodes that have been upgraded with an opt-in flag on that day have chosen not on the entire network.

Opponents of the MASF proposal say the long activation time could lead to apathy among users if they lose interest in the upgrade in fast motion and do not adopt the code. Still others say it’s an unnecessarily long process, especially for an upgrade that benefits multi-signature and privacy technologies that are waiting for Taproot to get their projects off the ground.

Bitcoin miners’ preferences

Only one of the respondents to Poolin’s miners survey, BTC.com, endorsed Corallo’s method. Slush Pool and Ant Pool both responded in favor of the original BIP 8. Poolin itself and NovaBlock want the BIP9 equivalent, which uses BIP8 (false) with no flag tag, while Luxor bets its chips on BIP9.

Regardless of which proposal wins, Jonas Nick conservatively estimates that Taproot activation will begin sometime this year. Given that the upgrade is not controversial and is backed by miners, the actual difference between each activation method could be of little concern, Nick said.

“I think a lot of developers would be happy with a reasonable suggestion because the support for Taproot has been overwhelming,” he concluded.

Many thanks to Dustin Dettmer for the rating and feedback.

LEAVE A REPLY

Please enter your comment!
Please enter your name here