Since October 11, the proportion of Ethereum blocks that are compliant with orders made by the United States Office of Foreign Asset Control (OFAC) has decreased to its current level of 47%, which is the lowest level since that date.
The most recent achievement in the fight against censorship comes about two and a half months and one day after the proportion of OFAC-compliant blocks reached its all-time high of 79% on November 21.
OFAC-compliant blocks are ones that do not include any transactions that involve parties who have been blacklisted by the Office of Foreign Assets Control within the United States Treasury Department.
Those individuals who are opposed to censorship inside the Ethereum ecosystem may see a decrease in the number of compliant blocks as a victory.
According to a statement released by the blockchain consulting company Labrys, the originator of MEV Watch, the decline may be linked to more validators choosing to utilize MEV-boost relays that do not filter transactions in compliance with OFAC standards.
The majority of the shift in market share has been taken up by the BloXroute Max Profit relay, the Ultrasound Money relay, and the Agnostic Boost relay in particular.
MEV-boost relays play the role of trustworthy middlemen between block producers and block builders, which paves the way for Ethereum validators to delegate the construction of their blocks to third-party block builders.
The Chief Executive Officer of Labrys, Lachlan Feeney, issued a statement on February 14 in which he expressed his satisfaction with the manner in which the Ethereum community has reacted to the censorship problem ever since it first appeared during the Merge event.
He pointed out that the recent decline of censorship-compliant blocks was especially noteworthy since it was accomplished without the involvement of a user-activated soft fork (UASF). He made the observation that “many individuals” of the Ethereum community had requested the soft fork prior to the Merge in order to resist censorship.
“I am incredibly proud of the Ethereum community for the progress we have made with this issue,” said Feeney, adding: “When we released the MevWatch tool drawing attention to a flaw within Ethereum, the community did not stick its head in the sand but instead rose to the occasion and made significant progress addressing the issue.” “When we released the MevWatch tool drawing attention to a flaw within Ethereum, the community did not stick its head in the sand but instead rose to the occasion and made significant progress
However, as Feeney emphasized, “there is still a great deal more work to be done.”
On August 8, OFAC sanctioned wallet addresses that transact using the Ethereum-based privacy mixing technology Tornado Cash. These wallet addresses are associated with Ether (ETH) and USD Coin (USDC).
On September 16, during the first 24 hours of Ethereum’s new proof-of-stake consensus mechanism, just 9% of blocks were filtered by OFAC.
Nevertheless, this number shot up dramatically over the subsequent two months, reaching its highest point of 79% on November 21.
After then, the proportion of OFAC-compliant blocks stayed anywhere between 68 and 75% until the 29th of January, when it dropped to 66%. Since then, in spite of a few brief increases, it has been consistently going down.
SegWit has come a long way since its first appearance during the 2015-2017 blocksize war. However, despite its relative success as a Bitcoin upgrade, crypto exchanges including Binance and Gemini are still not committed to using SegWit addresses for sending Bitcoin (BTC).
Implemented in 2017, segregated witness (SegWit) is a soft fork upgrade that separates “witness” data from the base transaction. In an “explain like I’m five” kind of way, SegWit allows for a safer and faster Bitcoin, making scaling the network easier.
While most exchanges and individuals were quick to upgrade their infrastructure to take on SegWit, reaching the 50% mark for Bitcoin transactions in 2019, the largest exchange, Binance has been dragging its feet.
Glassnode’s report states that Binance “had trivial SegWit adoption rates of only 10% up until the end of 2021.” However, it has finally “made an earnest effort to push SegWit adoption near the end of 2021.” Its adoption rate is currently at 50%, paling in comparison to Coinbase and FTX at 100%.
Altogether, crypto exchanges consume roughly 40% of Bitcoin block space. Crucially, however, Coinbase and Binance make up the lion’s share of block space, responsible for “25% of consumed block space” last month. If leaders such as Binance, or large players such as Gemini fail to fully adopt SegWit, Bitcoin will struggle to reach its true scaling potential.
Tomer Strolight, editor in chief at Swan Bitcoin, illustrates the argument:
“The fee savings provided by SegWit (and also batching and Taproot) will inevitably lead to their near-universal use. These have succeeded already in vastly reducing congestion and lowering fees. Ironically, however, their success to date means that we may have to wait until fees become a problem again to give the late adopters the kick in pants they need to fully switch.”
Glassnode’s report also shares a more accurate measure for reading SegWit adoption, SegWit utilization. When applied to single entities, such as exchanges, it provides a more detailed picture.
Of the 18 major exchanges that Glassnode investigated, one-third are bona fide SegWit supporters at over 90% adoption levels. The second third–including Binance–are taking their best shot at adopting SegWit ranging from 50% to 80%, while the final six are still using Bitcoin addresses beginning with the number 1, rather than SegWit’s 3.
Related:88% of all BTC transfers are overpaying transaction fees
Here is the graph detailing the exchange SegWit ranking:
It’s unlikely that the laggard exchanges will upgrade to Taproot, the most recent Bitcoin soft fork, any time soon. As Strolight points out, we might have to wait until fees rise before they wake up.
The Bitcoin (BTC) network successfully activated the Taproot soft fork following a 90% lock-in consensus from miners and mining pools between blocks 709,488 and 709,632. The milestone signifies the first major upgrade for Bitcoin since August 2017, which saw the launch of Bitcoin’s leading layer-two solution, the Lightning Network and Segregated Witness (SegWit).
The Taproot upgrade aims to improve the scripting capabilities and privacy of the Bitcoin network. To do this, the soft fork introduces the concept of Merkelized Abstract Syntax Tree (MAST). According to a Taproot-dedicated website run by prominent Bitcoin developer Hampus Sjöberg:
“[MAST] can help make smart contracts more efficient and private by only revealing the relevant parts of the contract when spending.”
Speaking to Cointelegraph, Sjöberg pointed out that Taproot activation shows that Bitcoin can do network upgrades again, which is extremely important for the longevity of the Bitcoin network. “I think that’s the greatest win,” he added.
Sjöberg, who is also a developer of a Bitcoin Lightning wallet Blixt Wallet, believes that the Taproot upgrade allows exploring off-chain capabilities, as to not put too much burden on the Bitcoin nodes of the network.
Taproot is a 100 years softfork.
Merging every contract and use-case under a single transaction type “Pay to Taproot” will in the long-run yield a more fungible and robust blockchain.
This is how you do it.
This is how you design a blockchain.
— Hampus Sjöberg ⚡ (@hampus_s) June 3, 2021
In addition, Sjöberg believes that MAST can also help improve the privacy of the older Lightning Network “if the Lightning implementations choose to adopt Taproot.” The developers of the various Lightning Network node implementations met in Zurich, Switzerland just a few weeks ago at the LN Summit 2021 to discuss possible upgrade paths:
“One of the things that were discussed in the meeting was whether it’s best to upgrade Lightning in small iterations or do it as one big package.”
Moreover, Sjöberg explained how payment channels under normal circumstances can be made indistinguishable from normal transactions using Taproot for the Lightning Network:
“It’s not possible to tell if a Taproot transaction is just a normal payment or if it belongs to a Lightning channel. This is important for the fungibility and thus the censorship resistance of Bitcoin.”
Taproot’s successful activation is attributed to Speedy Trial, a soft fork deployment method that requires 90% of the miners to signal the deployment of the upgrade. As explained by Sjöberg, “the signaling method works in periods of 2016 blocks, meaning that within a 2016 block period, 90%, or 1815 of the 2016 blocks have to signal for readiness.”
Back in June 2021, the Bitcoin miners achieved a 90% consensus for the first time and Sjöberg tweeted the announcement:
WE HAVE LOCK IN! #Bitcoin #Taproot
Video by: @TheGuySwann!https://t.co/rCUp5VNCBX pic.twitter.com/YFLMTenWW0
— Hampus Sjöberg ⚡ (@hampus_s) June 12, 2021
However, the Taproot upgrade also marks the end of Speedy Trial deployments and future upgrades to the Bitcoin network will require provision for new soft fork deployment methods. “Taproot opens a world of possibilities, but the first thing I personally would like to see is a “MuSig 2″ transaction.” Sharing advice for fellow Bitcoin developers, Sjöberg said:
“While we should not take anything for granted in Bitcoin, I personally would like to eventually see “Cross-Input Signature Aggregation” as a future soft fork for Bitcoin.”
Related:Bitcoin Lightning nodes and channels hit record highs
In Bitcoin’s near 13 years of existence, the Bitcoin network has undergone numerous community-driven hard and soft forks. While the Taproot upgrade is yet to prove its worth in time to come, the Lightning Network continues to attain new heights.
On Sept. 28, the Lightning Network witnessed a 160% increase in the number of nodes in the span of 12 months in addition to seeing a jump of 170% in the number of channels since January 2021.
As of Nov. 11, Bitcoin’s network capacity prior to Taproot soft fork was at an all-time high of 3,220 BTC, nearly worth $210 million.
Real-world use cases are one of the main adoption drivers for every crypto ecosystem, which also holds true for the Bitcoin (BTC) network. In the next seven days, the Bitcoin protocol will undergo a soft fork in the name of Taproot upgrade, which aims to improve the network’s privacy, efficiency and smart contracts capability.
Taproot is Bitcoin’s first major upgrade since August 2017, which saw the introduction of Segregated Witness (SegWit) and resulted in the launch of Lightning Network. While the previous fork primarily sought to fix transaction malleability and improve Bitcoin’s network scalability, the Taproot upgrade aims to revamp transaction efficiency, privacy and support smart contracts initiatives.
The Taproot upgrade was set for deployment after achieving a 90% consensus among the Bitcoin miners (mining nodes). On the same day in June 2021, Bitcoin developer Hampus Sjöberg tweeted the announcement:
WE HAVE LOCK IN! #Bitcoin #Taproot
Video by: @TheGuySwann!https://t.co/rCUp5VNCBX pic.twitter.com/YFLMTenWW0
— Hampus Sjöberg ⚡ (@hampus_s) June 12, 2021
The Taproot soft fork will see the introduction of Merkelized Abstract Syntax Tree (MAST), which introduces a condition that allows the sender and receiver to sign off on a settlement transaction together.
In addition, Taproot will also implement Schnorr Signature, an algorithm that will allow users to aggregate multiple signatures into one for a single transaction, reducing the inherent visible difference between regular and multisig transactions.
Schnorr’s signature scheme can also be used to modify the user’s private and public keys, in a manner that can be verifiable to confirm the legitimacy of each transaction. According to the original Taproot proposal from January 2018 put forth by Gregory Maxwell:
“I believe this construction will allow the largest possible anonymity set for fixed party smart contracts by making them look like the simplest possible payments. It accomplishes this without any overhead in the common case, invoking any sketchy or impractical techniques, requiring extra rounds of interaction between contract participants, and without requiring the durable storage of other data.”
At the time of writing, Taproot.Watch, a website built by Sjöberg, shows that the Taproot upgrade will be activated on Nov. 14th after the successfully minting 1020 blocks.
Related:Bitcoin network tags record high for daily settlement volume
Just last month, the Bitcoin network’s daily settlement value hit an all-time high after settling $31 billion worth of on-chain transactions.
Compared to the beginning of 2020, the network’s daily settlement volume has seen an increase of 40 times, supported by Bitcoin’s mainstream adoption in El Salvador and other jurisdictions.
There was $31 billion of value settled on the bitcoin network in a single day last week.
This is an all-time high for a single day of settlement value.
The global, decentralized payment system continues to become more dominant. (h/t @kerooke) pic.twitter.com/a6Q2FbPY3C
— Pomp (@APompliano) October 10, 2021
“[The Bitcoin network is] presently doing ~$190k per second. Compare this to $130k per second by Visa for US customers and $55k per second for Mastercard,” according to On-chain analyst Willy Woo.
The Taproot upgrade has achieved the first significant milestone on the road to activation as 90% of the Bitcoin (BTC) mining hash rate signaled for the protocol improvement within the current difficulty epoch.
Data from Taproot.watch, a webpage created by Bitcoin developer Hampus Sjöberg, shows the lock-in stage is now completed.
All recognized mining pools signaled for the upgrade with Slush Pool being the first to do so. It is perhaps fitting that Slush Pool also mined block 687285 that sealed the Taproot lock-in.
TAPROOT LOCKED IN AT BLOCK 687285 BY SLUSHPOOL pic.twitter.com/FFDdibtmGt
— pourteaux (@pourteaux) June 12, 2021
AntPool and F2Pool — the top two Bitcoin mining pools by hash rate share — were also among one of the earliest supporters of the Taproot activation in the BTC mining arena
In a conversation with Cointelegraph Bitcoin core developer Pieter Wuille explained the activation step for Taproot, stating: “According to BIP341, once locked in, activation is automatic at block height 709632 – expected around November 14, 2021.”
Wuille also commented on the significance of Taproot, adding:
“It’s the first consensus change since Segwit activated in august 2017. It extends Bitcoin’s script capabilities in ways that make certain things cheaper (especially more complex applications like multisig and layer 2 things), and somewhat more private by often hiding what the exact spending rules were.”
According to Wuille, the activation in November is only the beginning as the real work will be building the software to leverage the benefits of the protocol improvement.
June 12’s historic significance for Bitcoin has also moved beyond Taproot as the day seen a record number of transactions mined in a single block. Data from blockchain explorer Blockchair shows 4,075 transactions in block height 687249.
Source: Blockchair.com
This record figure is almost twice the average transactions per block recorded on June 11 and is four times the typical transaction count for Bitcoin blocks.
With hash rate declining amid mining restrictions in China, Saturday’s transaction count average might be due to a slowdown in block production forcing more transactions to be included in a single block.
In this episode of “The Van Wirdum Sjorsnado,” hosts Aaron van Wirdum and Sjors Provoost discussed Speedy Trial, the proposed Taproot activation mechanism that has been gaining traction in recent weeks.
They explained that Speedy Trial would give miners three months to signal support for the Taproot upgrade with their hash power. If a supermajority of miners signals support for the upgrade within these three months, Taproot will activate a couple of months later: six months since the release of the software client that includes the activation logic. If miners don’t signal support within three months, the upgrade will expire and a new upgrade path can be considered. (It is, as of yet, not defined what the potential alternative upgrade path would look like.)
Van Wirdum explained that Speedy Trial was born out of a compromise between developers and users who preferred different upgrade mechanisms for the Taproot soft fork, while Provoost detailed what some of the more technical implementation considerations of Speedy Trial are, like the benefits of using block heights instead of timestamps, and the extended delay between signaling and enforcement. Finally, the hosts discussed some of the downsides and risks of Speedy Trial.
The discussion on Taproot activation appears to have reached its final stage, with the remaining decision revolving around the activation parameter LOT.
The code for Taproot, a proposed Bitcoin protocol upgrade for compact and privacy-preserving smart contracts, has been included in the most recent version of Bitcoin Core, currently the de-facto reference implementation for the Bitcoin protocol. The only remaining step is for the upgrade to activate on the Bitcoin network.
But as a consensus system without central authority, Bitcoin protocol upgrades can be challenging. If one segment of the network upgrades to a new version of the protocol before another segment does, different nodes might enforce different rules, introducing the risk that the network fractures between them.
A soft fork upgrade, which Taproot is, is backwards compatible to minimize this risk. As long as a majority of miners (by hash power) enforce the new rules, both upgraded and non-upgraded nodes accept their version of the blockchain: upgraded nodes because the new rules are properly enforced, and non-upgraded nodes because none of the legacy rules are being broken.
Several of Bitcoin’s previous soft forks have therefore been deployed by leveraging hash power as a coordination mechanism, which is referred to as a miner activated soft fork, or MASF. Once (usually) 95 percent of newly mined blocks included a bit that signaled readiness, all upgraded nodes would start enforcing the new rules. If this threshold wouldn’t be met within (usually) a year, the upgrade would instead expire.
In 2017, the Segregated Witness (SegWit) MASF got close to expiring; in the midst of a heated scaling debate, miners refused to signal readiness for the upgrade. In response, a grassroots group of users and some developers released a special Bitcoin software client: the BIP 148 client. The BIP 148 client would activate SegWit on a given date even if there was insufficient hash power support to meet the original 95 percent threshold, an upgrade mechanism referred to as a user activated soft fork, or UASF. Right before the SegWit UASF would activate, miners started signaling readiness.
Now, about four years later, the events around SegWit activation have spurred a new discussion on soft fork activation in the context of the Taproot upgrade. This discussion is in a small part about the hash power threshold and duration of the activation period — but these seem to have mostly settled on 90 percent and one year, respectively. (Which the remainder of this article will also assume.)
The last remaining point of contention is about the lock-in on timeout (LOT) parameter, which can be set on either “true” (LOT=true) or “false” (LOT=false).
What Are LOT=true And LOT=false?
The mechanics of both the LOT=true and LOT=false options are straightforward. In either case, miners have a year to activate Taproot through hash power signaling. If within that year 90 percent of hash power signals support for the upgrade, Taproot-ready nodes will start enforcing the new rules.
The difference lies in what happens if, when the year is up, miners have not signaled for activation.
In the case of LOT=false, the activation simply expires, like a regular MASF. At that point, Taproot would not have activated, and nodes continue to use the current Bitcoin protocol without Taproot. A new activation period could then be scheduled, this time presumably using LOT=true.
In the case of LOT=true, the activation wouldn’t expire. Instead, like a UASF, nodes in the final weeks of the activation period start rejecting blocks that don’t signal for Taproot activation. When only blocks that signal readiness for Taproot are accepted, the activation threshold will necessarily be reached, assuming of course that Taproot-signaling blocks are mined at all. (There is actually a little bit more nuance to this process, because a small number of non-signaling blocks would still be allowed, but that’s a technical detail and not very important in the context of this article.)
The main argument in favor of LOT=true, is that LOT=false would give miners a “veto” on the upgrade. They could block Taproot activation by refusing to signal readiness, even when there is broad consensus for the upgrade. During the SegWit activation period, it appeared that this veto was being leveraged by miners in an attempt to influence Bitcoin protocol development.
LOT=false proponents, however, argue that this veto isn’t really a veto at all, since it can be overruled. In the end, miners cannot block Taproot activation, because users can always upgrade to LOT=true clients, even if they initially used LOT=false. This can be done in two main ways. Either, users switch to LOT=true clients before the activation period is over, that is, before the end of the year. Or, as already mentioned, they can wait until the activation period is over, and schedule a new activation period.
Proponents of LOT=true however point out that these two different options to overrule the veto could be another recipe for community conflict. If, say, six months into the activation period miners haven’t signaled support for the upgrade, one segment of users may prefer to deploy LOT=true clients before the year is over, while another segment may prefer to wait until after the first activation period before deploying a new activation mechanism. This would essentially reintroduce the current debate between LOT=false and LOT=true, but this time with only six months to resolve the issue. This is easily avoided, LOT=true proponents figure, by simply not giving miners a (sort of) veto in the first place.
But there are arguments in favor of LOT=false and against LOT=true as well.
For one, LOT=false more closely resembles the activation mechanics of previous soft forks, most of which rolled out fairly well. While the SegWit upgrade wasn’t as smooth, LOT=false proponents argue this was due to exceptional circumstances of the “scaling wars,” which are now behind us. (Some LOT=true proponents however believe that LOT=false might invite such circumstances again.)
Second, given that most mining pools have indicated support for the Taproot upgrade, LOT=false is likely to do the job without it ever coming to a timeout scenario. This makes LOT=true unnecessary. (LOT=true proponents instead argue that stated intentions shouldn’t be a factor in designing a technical upgrade mechanism, and that LOT=true would best align incentives to ensure that miners indeed upgrade before the end of the year.)
Third, in the unlikely scenario that a problem with Taproot is found, LOT=false makes it easy to back out of the upgrade: miners would simply refrain from signaling readiness, and the proposal would expire without requiring users to upgrade their software again. (LOT=true proponents believe Taproot is well reviewed, and shouldn’t be up for activation in the first place if that weren’t the case. And even if a problem is found after all, it should be relatively easy to defuse Taproot activation through technical means.)
Fourth, LOT=true could feed into the perception that Bitcoin Core developers have the power to change the Bitcoin protocol. Since LOT=true would “guarantee” Taproot activation, their code would “force” this change of the protocol rules. This perception could attract unwanted attention towards developers.
This perception would be mostly false, as also pointed out by proponents of LOT=true. In the end, users would need to voluntarily choose to adopt the new Bitcoin Core software. Developers can ship code, but they can’t make users run it. Most LOT=false proponents agree, but argue that the perception of developer power might be there regardless, and that perception alone may be harmful enough — even if wrong.
But probably most importantly, the fifth argument for LOT=false and against LOT=true is that LOT=true could in some scenarios result in an unstable network and perhaps even a split in the blockchain. This could lead to a loss of funds for users and miners, and undermine trust in the Bitcoin project altogether.
LOT=true proponents, however, argue that it’s the other way around, and LOT=false in Bitcoin Core would represent the greater risk of this scenario unfolding.
To understand this discrepancy, let’s look at some scenarios…
What If There Is No Network Consensus On LOT?
If there is consensus on either LOT=true or LOT=false — that is, all nodes on the network use one or the other — the scenarios are straightforward. In either case, Taproot would probably activate during the activation period. If not, the upgrade would activate by the end of the year in the case of LOT=true, and miners would have little choice but to accept this (else they’d mine blocks that the network rejects, and they’d be wasting their hash power). Or, in the case of LOT=false, the proposal would expire, and a new activation period would be deployed, this time presumably using LOT=true. (Unless consensus already shifted to LOT=true before the end of the activation period, in which case Taproot would also activate before the year is over.)
It becomes more complex if there is no consensus on either LOT=true or LOT=false. In the unlikely event that the activation period expires, and one segment of the network runs LOT=true clients while another segment runs LOT=false clients, it comes down to the support for each option. (We’ll ignore a third, but important segment for now: users that run neither LOT=true or LOT=false… more on this group in a bit.)
The first thing to note is that if any majority of miners (by hash power) signals support and uses LOT=true, Taproot is guaranteed to upgrade. These miners would by the end of the activation period start rejecting blocks that don’t signal readiness, and since they’d produce a longer blockchain than the minority of non-signaling miners, and because both LOT=true and LOT=false clients would accept this chain as valid, everyone would accept this Taproot-signaling blockchain and activate the upgrade. In other words, the hash power activation threshold would in the last weeks effectively drop from 90 percent to 51 percent.
But if less than half of all miners use LOT=true and the signaling period expires, the Bitcoin blockchain could “split” between LOT=true and LOT=false nodes. LOT=true nodes would only accept signaling blocks, even if non-signaling blocks make a longer blockchain. They would essentially be on their own “LOT=true chain.” LOT=false nodes, meanwhile, would reject the LOT-true chain in favor of the longer “LOT=false chain.”
The result would be a blockchain fork, and ultimately perhaps two different blockchains, each with their “own” transaction history, and essentially their own coins, potentially with their own exchange rates: a “coin split.” Users of either blockchain might consider their own version the “real Bitcoin.”
Barring further protocol changes on the LOT=false chain, however, the LOT=true chain would in this case have a strong game-theoretic advantage. LOT=true nodes and miners would never accept the LOT=false chain, no matter how much longer it were to become. In a “worst case” scenario, it would remain a minority coin.
See Also
LOT=false nodes, in contrast, would accept the LOT=true chain if it ever became the longer chain. They’d then abandon “their own” LOT=false chain, and lose any coins they received or mined on it since the split. In short: LOT=false nodes and miners would risk losing money. Therefore, they’d have a strong incentive to just join the LOT=true chain before this can happen. (Especially since they, presumably, don’t object to the Taproot upgrade itself.)
The incentive to join the LOT=true chain would be particularly strong if most users prefer the LOT=true chain, or more accurately, if this chain would have the “economic majority.” If most of the Bitcoin economy prefers to accept and hold coins on a hypothetical LOT=true chain, these coins should demand a higher price and more transaction fees, which would draw in the most miners. This would in turn ensure that the LOT=true chain becomes the longest and therefore only chain.
Here’s the rub. The incentive to join the LOT=true chain before a potential split to be on the “safe side,” would only have an effect if users and miners are aware of what’s going on to begin with. Anyone who assumed that LOT=false would be the upgrade mechanism and therefore didn’t switch, could still lose money if and when a split occurs and the LOT=false chain is abandoned afterwards.
The same is true for the third segment of users, the segment we ignored so far but is actually important to take into consideration: users that run neither LOT=true or LOT=false. These could for example be users that, for whatever reason, don’t keep up with Bitcoin’s upgrade process at all. Like LOT=false users in this scenario, these unsuspecting users could lose money, arguably through no fault of their own.
LOT=false proponents argue that LOT=true essentially “forces” other users to upgrade, which they consider undesirable, if not downright unethical. LOT=false proponents therefore believe LOT=true should only be used as a last resort, if a MASF fails.
LOT=true proponents counter this by positing that the best way to avoid such damage is to deploy LOT=true in a Bitcoin Core release. They believe some segment of users will run a LOT=true client even if it’s not included in Bitcoin Core, and while this may be a small group, it might be big enough to cause a chain split, and the outcome could be ugly.
Implementing LOT=true in Bitcoin Core would therefore be safer, they argue. Since it’s the most widely used Bitcoin implementation on the network, a Bitcoin Core release with LOT=true would likely guarantee that the economic majority uses LOT=true, ensuring that incentives for miners to activate Taproot would be too strong to ignore, minimizing the risk of a coin-split scenario.
So What Will Actually Happen?
It’s impossible to predict how the discussion around LOT=true and LOT=false will resolve — if it will resolve at all.
As a general principle, the Bitcoin Core development process is guided by rough consensus; contentious code shouldn’t make it into a new release. This is of course very true for protocol upgrades like Taproot, but it is probably equally true for code that activates protocol upgrades. While there appears to be rough consensus for Taproot itself, so far there is no rough consensus for an upgrade mechanism.
Perhaps consensus eventually settles on either LOT=true or LOT=false (or perhaps some other solution, like a configurable option for users to choose between the two). But as long as no rough consensus emerges for either, it’s possible that neither option will be included in Bitcoin Core. The Taproot upgrade would effectively be put on hold, at least temporarily.
Another possibility is that consensus emerges to include LOT=false in Bitcoin Core after all, but only because LOT=true proponents independently release an alternative client with LOT=true. This would resemble how SegWit was activated, with the BIP 148 client serving as the equivalent of a LOT=true client. This would however open the door to some of the coin-split risks described in this article.
It’s also possible (but probably less likely) that neither LOT=true or LOT=false is adopted by Bitcoin Core, but either or both options are included in alternative clients. If enough users switch to such alternative clients — even if these are LOT=false clients — Taproot could activate without Bitcoin Core’s involvement. Bitcoin Core could then release a Taproot-compatible version of its software once the rest of the network has upgraded. (This is similar to how some alternative Bitcoin clients, like Libbitcoin, have historically adopted protocol upgrades.)
Or perhaps, a new possibility will present itself.
Author’s note: Some of the arguments and scenarios described in the article are simplified for the sake of readability. In the event of a chain-split, more factors could affect the outcome, while a lack of consensus on LOT=true or LOT=false could also result in smaller (but still harmful) disturbances than the ones described.
To keep up with the Taproot activation process, thebitcoin-dev mailing listand the #taproot-activation channel on Freenode (IRC) are currently the most relevant discussion channels.
