A release date and activation timeline are set for Bitcoin’s Taproot upgrade, but developers and other stakeholders are still debating the best method to coordinate Bitcoin’s biggest upgrade since SegWit.
Per a public IRC chat discussion, the code for the fully primed-and-ready Taproot upgrade will be deployed sometime between March 17 and March 31 (or April if necessary), but the actual signaling that kick-starts the activation process probably won’t start until July.
If everything goes as planned, then Bitcoin’s “economic majority” (miners and node operators who run Bitcoin’s code) could update within two weeks of the signaling period’s start. Come August 2022, Taproot’s activation period will reach its timeoutheight
and signaling will end.
Assuming mining pools reflecting 90%+ of Bitcoin’s hashrate support Taproot before the timeoutheight
(as one survey indicates), then the vast majority of support would ensure Taproot is a success, and the other 10% or so (the “economic minority”) can update without consequence afterward.
But what happens if the mining pools don’t signal to activate Taproot? Well, that’s where the hang-up is in discussion right now. But for some of Bitcoin’s stakeholders the hang-up shouldn’t even exist.
First, a quick note about Bitcoin upgrades.
Unlike a centralized network, whose central operators can mandate an upgrade whenever and however they choose, Bitcoin’s network is decentralized, so upgrades require deliberate decision-making and discussion among Bitcoin’s stakeholders (namely, developers, miners, business and power users). Taproot is a “soft fork,” meaning a change that is compatible with previous versions of the software (unlike a “hard fork,” where newer rule-sets and older rule-sets are incompatible).
Soft fork or not, at the heart of the matter for activating Taproot is whether to give node operators (those individuals running Bitcoin’s source code) an option to force activate the upgrade if a supermajority of miners fail to support it before the timeout.
This would allow node operators to reject blocks from miners who don’t support the upgrade. This sort of measure (a so-called “user-activated soft fork”) was used to prod along the SegWit upgrade activation in 2017 and is believed to have budged the Overton window for miners to accept the upgrade.
The other option is to not include this feature at all. These Bitcoin Improvement Proposal (BIP) options to force or not force the upgrade are referred to respectively as BIP8 (true) and BIP8 (false), also known as LOT=true and LOT=false. LOT is short for lockinontime
, a feature that dictates whether Taproot will be “locked in” if network-wide activation isn’t reached when the timeoutheight
is reached; the (true) option automatically mandates the upgrade after the activation window expires, while (false) lets it fail entirely.
Opponents of BIP8 (true) say this aggressive measure is gratuitous because Taproot isn’t at risk of failing. As Bitcoin Core contributor Andrew Chow put it, with the Taproot activation survey sent to miners, “the community has already decided to activate, [so] there’s no need to [do] LOT=true. Miners are part of the community.”
Still others in favor of BIP8 (true) believe it is a necessary feature for coordinating the upgrade, which in the rarer circumstance of extreme discoordination, could split the Bitcoin network into incompatible versions if something goes wrong.
“LOT=true does not split the chain. It strictly reduces the likelihood of that,” BIP8 (true) primary proponent Luke Dashjr said in the chat.
Dashjr shares this view with others, like hsjoberg, who noted, “Lot=true would make sure upgraded nodes mandate a specific chain.” This means that node operators who run true would mandate that the Taproot-activated version of Bitcoin is the “real” chain, so theoretically this would help coordinate consensus between actors to avoid a split.
One brg444 contended that “if lot=true activates there will be a network split.” But this would only be if the forced activation went through. Brg444 said they think this is unlikely, because the threat of this very split would be enough to scare miners into activating before the forced activation occurs.
But is a scare tactic really necessary or is it an egregious show of force?
“[In my opinion, people] have PTSD from SegWit … [they’re] being preemptively defensive for seemingly no reason other than they’re afraid of past events that now seem to have a low probability of actually occurring,” Lightning Labs CTO Olaoluwa Osuntokun said in the chat, referring to miners originally opposing the activation of SegWit.
“[P]pl are just shadow boxing casper rn lol,” he said later. “Let’s give [BIP8 (false)] a shot and revise afterwards if stuff actually happens.”
After all, if six months or so after activation begins miners haven’t signaled for Taproot, then LOT=true could be coded in after the fact to enforce the upgrade.
Still, this would add yet another step to the process, and making this change post-factum would be more cumbersome than just including it in the initial release. But some think it’s a more prudent decision, especially considering the stigma that brands Bitcoin development as a closed garden that is subject to the tending of developers only.
“LOT=true appears as if the developers are forcing a change upon the community. While that may not necessarily be the case, the appearance of that happening is not a good thing. Given that we don’t believe there will be any issues with activation, I would prefer LOT=false to avoid this view,” Chow said.
Notably, the last meeting to discuss Taproot seemed to indicate majority support for LOT=false. With only 100 or so attendees this round (as opposed to nearly double the attendance last time), and some favor growing for LOT=true, though, “we can’t really measure ‘community consensus,’” contributor Darosoir said.
According to the Taproot activation wiki, 26 attendees in yesterday’s meeting vocally favored LOT=false while 19 favored LOT=true (some more neutral parties indicated they would be fine with either).
Hardly representative of Bitcoin’s sprawling international community, the IRC chatters left the meeting without clear consensus on the precise activation parameters, with some voicing the need to boil down the complexities of the process to get a more informed opinion from the wider community.
“I will say, though, that I think this discussion would have benefitted from having a more clear view of the community overwhelmingly supporting this. Off topic for this meeting, but anyone interested in how to get better data around this, I’d be interested to work with,” Keagan McClelland, co-founder of Start9 Labs, wrote in the chat.
With a date set for the end of March and the bulk of the activation parameters chosen in BIP8, the final question to answer for Taproot’s deployment is whether or not to include the “user activated soft fork” measure from the get-go or not.
Taproot will ship by BIP8 in late March and activation is slated for July, so this question will have to be answered within the month.