BTC Taproot plan stumbles as miners fail to show support—who holds the power?

Getting your Trinity Audio player ready...

BTC supporters have been disappointed recently at a lack of miner enthusiasm for the “Taproot” proposal. With just two weeks to go in a signaling period where miners show support for the change in the blocks they mine, only around 62% are in favor—well short of the 90% needed to implement it. The reaction to this is yet another example of an important change to BTC rules being forced upon miners by a small group of centralized protocol developers—thus demonstrating the advantage of a system where protocol rules don’t change, and miners are free to set their own limits.

Bitcoin Satoshi Vision (BSV) matches the original Bitcoin protocol rules set by Satoshi Nakamoto when he released the software in 2009. It has removed limits on transaction block sizes and transaction types, allowing miners to set their own limits depending on who they wish to serve. The Bitcoin protocol in BSV is “set in stone,” meaning its rules cannot be changed. Developers do not have the power to alter its fundamental workings, while processors (aka miners) have more flexibility to decide for themselves what functions they want to perform.

This is important because, when a small cabal of developers hold the keys to a protocol that could form the basis of the world’s digital economy, it consolidates a lot of power in their hands. Bitcoin developers are talented but they are also humans and individuals, meaning they are susceptible to all the same influences and coercions as a normal person. “Anyone can be a BTC developer,” goes the common refrain—but there are many gatekeepers along the way (who has access to the GitHub repository?). It’s a bit like saying “anyone can become an elected representative and change the system,” which is far easier said than done, and the reality for anyone who attempts it is quite different.

Handing more freedom to processors/miners is actually more decentralized than giving all the power to a group of developers small enough to literally sit at a table together. This is a key difference between the way BTC and BSV function, and it’s a critical one for industry.

So what is Taproot?

Taproot, according to the BTC developers pushing it forward, would make complex transactions more efficient and help mask details of contracts, adding privacy by making them indistinguishable from ordinary payment transactions. First proposed by BTC developer Greg Maxwell in 2018, it uses Schnorr signatures and Merkilized Abstract Syntax Trees (MAST) to keep unexecuted parts of a contract off-chain, writing them to the blockchain only after contracting parties sign with top-level signatures.

According to the rules set long ago by BTC’s BIP9, a change like this must receive at least 90% support from miners over a two-week (or 2016-block) period before it can proceed. Miners signal support in the code of the blocks they mine (only support is noted, while doing nothing is counted as non-support). In other words, there must be a total of 90% of 2016 blocks signaling support.

At press time there were 442 signaling blocks (21.92%) and 214 non-signaling (11%), with 1360 blocks to go. The 11% of non-signaling blocks mean it’s now impossible to reach 90% signaling and “lock in” Taproot within the current period.

Among large mining pools, AntPool, F2Pool, Poolin and ViaBTC are considered “supporting” — while BTC.com, Huobi Pool, Binance Pool and 1THash have not (yet). Some miners have sent mixed messages, signaling support with some blocks and not with others.

Discussion surrounding the Taproot proposal on the BitcoinTalk forums has noted the lukewarm miner response, lamenting that it’s already too late to lock in the change, and asking how this could happen (and what could/should be done about it). There have been complaints that BIP9’s 90% support requirement is too high, while others have suggested miners are either lazy or being deliberately contrarian. There have even been some hints that miners not signaling for change should be made to explain themselves, or even “punished” for their inaction.

When someone suggested BTC developers were “neutral” on implementing Taproot, Maxwell himself replied:

“You say a lot of weird stuff. Bitcoin Core developers pushed this out, they’re not ‘remaining neutral’, that would be a terrible abdication of their responsibility as technical experts.”

It harkens back to the years leading up to the 2017 BTC/BCH hard fork, where the contentious issue was on-chain scaling (the “big blockers”) vs. limited on-chain capacity and second-layer transaction networks (the “small blockers”). There clearly wasn’t enough support among miners to reach 90% in a 2016-block period, but BTC Core developers and their backers forced the change with heated arguments, censorship and a negative PR campaign that browbeat miners into accepting it was inevitable. Those who disagreed eventually quit BTC altogether, causing the hard fork and leaving only the miners who supported it, allowing the 90% threshold to be reached.

(For the record, the 2017 hard fork actually concerned the implementation of segregated witness, or SegWit, rather than block size directly—however the issues were intrinsically linked. Adding SegWit to the BTC protocol changed its rules in a fundamental way. It was sold with the accompanying provision that another hard fork would increase block sizes to 2MB a few months later. However as soon as SegWit was firmly in place, a new PR campaign appeared to demonize the block size compromise, and that change was nixed. You may see yet more similarities here to the way many “democracies” function.)

BTC’s controllers, supposedly driven by the user base demand and “community consensus”, have many ways at their disposal to manipulate opinions and media messages to indicate a hunger for rule changes. But it is only an illusion of grassroots support; the real decisions are made behind closed doors before miners and users even hear about them, the people at the top get the changes they want to suit their own purposes.

The best solution is: don’t change the rules and don’t allow developers to change them.

Why aren’t miners signaling support for Taproot?

On the surface, Taproot appears to have vocal support among BTC’s user base, and fits with the commonly-held belief in BTC that changes that improve “privacy” (or anonymity) by keeping some transactions off-chain are a good thing.

There aren’t so many arguments against Taproot in principle, and the “news” reaching the public via the BTC-friendly blockchain media machine is overwhelmingly in favor. Arguments against, where they exist in BTC, include: that it introduces complexity that miners and application developers will have to deal with; that too many radical rule-changes are troublesome; and that Taproot may not actually do what it promises (just as SegWit was pushed as a solution to low block capacity and high transaction fees).

We should clarify that signaling support (or lack of support) for a new proposal with transaction blocks doesn’t necessarily refer to ideology. It’s more a gauge of readiness to upgrade, and perhaps whether a miner or pool considers the proposal a priority. Many miners are conservative about upgrading their software even for regular updates and bug fixes, since it’s a disruption to their operations and thus income even if everything goes smoothly.

Support-signaling for Taproot has increased as the 2016-block period advances, but it may not be enough to reach 90% of total blocks. However, there’s always the option to repeat the procedure at any future point, when enough miners have been “convinced.” Just as some governments have been accused of rehashing referendum questions until the required “yes” vote is achieved, it might take a few formal voting rounds for BTC miners to come around. If the centralized protocol developer cartel running BTC wants something changed, and can orchestrate a PR campaign to convince enough “users” that it’s something good for them… the developers will get their way.

Punish the miners if they don’t let us change the rules!

Several commentators expressed disappointment at BIP9’s 90% threshold, suggesting another change be made to end that (and presumably set it much lower). Others, like JayJuanGee, suggested miners simply don’t like being rushed to make a firm commitment, referring to those who are “either passive aggressively failing to signal, incompetent to signal or not providing some kind of reasonable explanation why they are currently not signaling.”

He added:

“If such non signaling pool is able to provide some reasonable and plausible explanation regarding their failure/refusal to signal and to provide a date, such as June 1 or some other date that they will start to signal, then sure, maybe no need to punish such pools…”

The notion that recalcitrant miners ought to be “punished” for not supporting rule changes, dropped so casually into that conversation, is revealing. It demonstrates not only that this is possible, but that non-mining stakeholders resent the power miners still have, and feel entitled to force them to accept change where necessary.

It’s also possible that many miners are simply apathetic towards BTC rule changes—the too much complexity, too many new rules problem. They won’t benefit from Taproot directly and there will be just as much demand for their services whether Taproot exists or not, but they will have to do extra work to implement it. Even in BTC there’s a significant desire among the community to leave things as they are.

While miners may eventually signal enough support for Taproot to be implemented, in either this voting period or a future one, it’s clear they’re not as hungry for change as the centralized protocol developers pushing the new rules. If and when they do change their minds, it’ll be the result of the same kind of closed-door planning and message manipulation BTC has become well-known for.