- Bitcoin miners representing roughly 91% of the network’s hashpower have demonstrated support for Bitcoin’s biggest upgrade in years, Taproot.
- These activation methods vary the length of time required and whether or not to include a measure that would force the upgrade through full nodes with a “user activated soft fork.”
- Given miner support, Bitcoin developers believe the upgrade should activate without issue, regardless of the specific proposal chosen.
Now that most all major mining pools have pledged support for Bitcoin’s Taproot upgrade, all that’s left is the actual activation – but the members of Bitcoin’s open-source community have to pick the method first.
There are currently a handful of proposals vying for attention among Bitcoin’s stakeholders. Summing up the differences between them, some of these allot longer activation times than others, and some would allow the upgrade to be “forced” through 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
Bitcoin’s biggest upgrade in half a decade, Taproot will enrich Bitcoin’s smart contract scripts, making it easier to execute highly complex transactions on the Bitcoin blockchain. Among other things, this will improve multi-signature software and privacy for the network.
Bitcoin developers have proposed multiple ways to bootstrap the upgrade, but they all rely on some version of Bitcoin Improvement Proposal 8 or Bitcoin Improvement Proposal 9 (BIP8 and BIP9, for short). Each proposal is similar but offers slightly differing approaches to activating the upgrade, which will require cooperation from both Bitcoin miners and node operators to go smoothly.
There are two primary versions of BIP8 vying for attention: one version, called BIP8 (true) includes a “flag day,” at which point the update will be forced via full node activation, even if miners fail to adopt it; and one version, called BIP8 (false), wherein the upgrade simply fails if miners don’t adopt it. “True” designates that the BIP includes forced activation, whereas “false” designates a version of the BIP that doesn’t have forced activation.
Why the addition of the forced activation, you might be wondering? One apprehension going into activation discussions has been whether or not mining pools would adopt the upgrade, considering miner reluctance stymied SegWit’s activation in 2016 and 2017.
Mining pools that represent roughly 91% of Bitcoin’s hashrate, though, have announced their support for the upgrade as part of an initiative spearheaded by Alejandro De La Torre, a VP at bitcoin mining firm Poolin. Torre said Poolin’s takeaway from the survey is that “BIP9 is the most favorable choice” for activation.
Bitcoin cannot tell time, so BIP9 allots a signaling period that is gauged by Bitcoin’s block time (whereby a pre-defined period of time is measured via Bitcoin’s block schedule, which can be erratic). If enough miners adopt the upgrade during this timeframe, it is locked in and considered successful; if this threshold is not reached, then the upgrade fails.
Bitcoin miner support could mean easier activation
With miners behind the upgrade, BIP9 could provide the quickest and easiest route to activation, Ben Carman, a Bitcoin developer who has helped review Taproot’s code, told CoinDesk.
“In the beginning I was in favor of BIP8 because I was worried about miners being able to block the upgrade. However, with things like taprootactivation.com I have moved to being in favor of BIP9. It seems we have basically everyone on board to do the upgrade and BIP9 would be the simplest, as well as only require a couple lines of code to be started. Other methods would require larger code changes to implement new activation logic.”
The other activation methods Carman mentions, BIP8’s differing versions, are similar to BIP9 sans a crucial tweak: BIP8 includes an option to force the update through a “flag day” if miner signaling fails (this option would be employed with the BIP8 [true] activation method). Additionally, a smaller change measures activation time by block height instead of BIP9’s use of block times.
This change means that if miners don’t adopt Taproot, the update can be forced through full node activation at a certain date with BIP8 (true), or the upgrade can be paused per BIP8 (false) and resumed later.
If enough miners don’t adopt the upgrade during the signaling period for BIP9, though, the process fails and must be started over from the beginning.
‘BIP9-style activation’ could come from BIP8
BIP9 has been used in the past for Bitcoin soft forks (upgrades that are compatible with previous software versions). It was originally used to activate the SegWit upgrade, but not enough miners signaled for the update so other means were required. Under this scheme, if not enough miners support an upgrade the signaling period for it merely expires and the process can be repeated.
Jonas Nick, a Bitcoin Core developer who has been one of the leads on Taproot, told CoinDesk that “BIP9 style activation is the least disruptive path and therefore a reasonable choice,” but that it would most likely come from BIP8, hence why this route is called the “BIP9 equivalent.”
Assuming the upgrade will be adopted during the signaling period, the upgrade would be adopted as outlined in BIP9 (i.e., via complete miner support), but using BIP8’s activation logic, which measures the activation window through block times and which can easily be tried again if the upgrade fails.
That’s why, while “no one can say for sure,” Nick believes that fellow Taproot development lead AJ Townes’ proposal (a slight modification of the so-called “gently discourage apathy” route), could win out.
Taproot ‘flag day’
Under this scheme, miners would have a year to signal for the upgrade. If miners representing 95% of Bitcoin’s hash power signals for the upgrade during this period, Taproot activates without further action. If not, the update undergoes a reviewal period during which developers and miners cooperate to iron out the kinks.
After this period ends, a “flag day” would be coded into the update to force the upgrade through mandatory signalling, whereby node operators would 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, though the method proved unnecessary because miners adopted the update after the UASF proposal gained traction. This method is known as “forced activation.”
By giving miners plenty of time to upgrade but also maintaining a flag day just in case, the proposal is meant to discourage miners from “not updating out of laziness,” KoinKeep Bitcoin wallet developer Dustin Dettmer told CoinDesk.
Townes has sketched out what this proposal would look like, but the code for it has not been included into Bitcoin’s software. The method includes BIP8 (false), so this code would need to be reviewed and inserted into Bitcoin Core first, Nick said.
Taproot: Rooted in risk?
Even as Nick and Townes put their weight behind the modified BIP8 implementation, Matt Corallo, another reviewer of the Taproot code, believes the activation method is too risky, even if miners are largely on board.
“The forks in Bitcoin, for better or for worse, define the process and benchmark by which future changes are made and evaluated,” he told CoinDesk. The SegWit block size wars, he continued, set “an incredibly high standard” for how “on-its-face simple change[s]” are made to Bitcoin’s software – namely, with conservative deliberation that takes as few risks as possible.
Corallo believes the mandatory flag day activation method proposed in other methods is unnecessarily brazen and indicates too much influence from Bitcoin’s developer community, unless all other activation methods have been exhausted.
“Some of the proposed activation methods being discussed throw [the lessons learned from SegWit] away, setting a visible precedent that Bitcoin can be changed with almost only developer buy-in and with coercive and marginally riskier activation, opening the door to re-litigating years-settled debates.”
Corallo “doubts activation [will] be an issue,” but he concluded by saying, “I see no reason to take that risk unless all other options have been tried.”
Offering his alternative, Corallo’s own Modern Activated Soft Fork (MASF) takes bits and pieces of both BIP8s. This activation path involves a year-long signaling period for miners. If enough miners do not update during this timeframe, then the upgrade would pause per BIP8 (false) to be subject to a six-month review to make changes (if any) to the proposal.
If, after this point, Taproot still doesn’t have enough support, then a two-year period begins wherein node operators can push the update through an opt-in, non-mandatory flag day. As opposed to a mandatory option, which would force activate Taproot on all nodes running the latest version of Bitcoin on the flag day, this opt-in flag day would get Taproot up and running only on nodes whose operators chose to upgrade, not the entire network.
Opponents of the MASF proposal say the long activation timeline could result in apathy among users, where the time-lapse has them losing interest in the upgrade so they don’t adopt the code. Still others say that it’s an unnecessarily lengthy process, especially for an upgrade that would benefit multi-signature and privacy technologies waiting for Taproot to bring their projects to fruition.
Bitcoin miners’ preferences
Only one of the respondents to Poolin’s miner poll, BTC.com, favors 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 wherein BIP8 (false) is used sans the flag day, while Luxor is putting its chips on BIP9.
Regardless of which proposal wins out, Jonas Nick conservatively estimates that Taproot’s activation will kick off sometime this year. Given that the upgrade is non-controversial and miners support it, the actual difference between each activation method could be of little consequence, Nick said.
“In my perception, because Taproot has overwhelming support many developers would be fine with any reasonable proposal,” he concluded.
Thank you to Dustin Dettmer for review and feedback.
