Taproot, a proposed protocol upgrade that would improve Bitcoins privacy and flexibility, is in its late stages of development. Bitcoin Core contributors agree that the upgrade would benefit Bitcoin, and so far it generally appears to be welcomed by the wider Bitcoin ecosystem as well. Its therefore likely that Taproot will make its way into a Bitcoin Core release, with other Bitcoin implementations possibly to follow.

But one question remains: how should the Bitcoin network itself upgrade? Taproot is a consensus protocol change, which means that Bitcoin nodes must somehow switch from the old rules to the new rules without splitting the network into factions enforcing different rules. For various reasons, this has in the past sometimes proven to be a challenge.

Improved strategies to activate protocol upgrades are now being contemplated.

The good news is that Taproot will be a soft fork. This type of upgrade adds or tightens rules as opposed to a hard fork which removes or loosens rules. The nice thing about adding or tightening rules is that anything that an upgraded node considers valid, a non-upgraded node considers valid, too. (If an old node accepts both transaction types A and B, but new rules only allow transaction type A, the old node would remain compatible on a network enforcing the new rules.)

Bitcoins earliest soft forks were activated though flag days. Developers (in particular, Satoshi Nakamoto) embedded a future date in the code of a new Bitcoin software client release, specifying a point in time where upgraded nodes would enforce the new rules. Miners and users were encouraged to upgrade before that date to avoid network splits. (As an aside, in those days, miners and users were more often the same people than they are today.)

Since non-upgraded nodes remain compatible with new rules, a handy benefit of soft forks is that if a majority of hash power enforces the upgrade, the entire Bitcoin network finds consensus on their version of the blockchain. This also means there is less of a pressing need for all nodes to be upgraded immediately when the new protocol rules are enforced, allowing users some flexibility. (Though users are encouraged to upgrade nonetheless; they are ultimately the ones enforcing the new rules by rejecting transactions and blocks that break them.)

Since about 2012, soft forks have increasingly utilized hash power as a coordination mechanism to coordinate a switch to new rules. By embedding a bit of data in their blocks, miners can signal to other miners and the rest of the network that they upgraded their software, and thus are ready to enforce the new rules. Once enough hash power signals support, all upgraded nodes are triggered to enforce the new rules.

Over the course of a few upgrades, this strategy evolved into Bitcoin Improvement Proposal 9 (BIP 9). BIP 9 was, for example, the mechanism used to activate Bitcoins last soft fork upgrade, Segregated Witness (SegWit). Miners were given a year to activate the upgrade, requiring 95 percent of blocks within any difficulty interval to include a readiness signal bit. If after a year this hadnt happened, the activation period would expire, and the upgrade would have failed. (It could then of course simply be tried again.)

For SegWit, however, BIP 9 did not play out smoothly. As with some of the previous upgrades, some miners probably didnt get around to upgrading for some time due to apathy: there often isnt a very big incentive for miners to upgrade fast. But a bigger problem was that some miners had come to understand the signaling process as a sort of vote on the upgrade, where instead of signaling readiness, they would (or would not) signal support for it. Worse, some miners ended up using this vote to block the upgrade in order to try and gain political leverage over the Bitcoin development process, and/or they voted against the upgrade in order to covertly benefit from a quirk in the Bitcoin protocol which the upgrade would fix.

After an extended period of intense drama, SegWit ultimately did activate, but only after alternative Bitcoin clients included new activation schemes. BIP 148, included in the BIP 148 client run by some users, was programmed to only accept blocks signaling support for the protocol upgrade starting on a flag day. Meanwhile, BIP 91, included in the btc1 client and run by miners just ahead of the BIP 148 flag day, effectively lowered the hash power requirement from 95 percent to 75 percent. Faced with a potential split network and a possible loss of income, the obstructing miners conceded. But for most Bitcoin Core developers, BIP 9 had revealed itself to be a suboptimal solution, and they started thinking of alternatives.

BIP 8 was an early alternative for BIP 9, proposed by BIP 148 author Shaolinfry and Bitcoin Knots and Bitcoin Core contributor Luke-jr. It initially resembled BIP 9, but with one crucial difference: instead of the upgrade failing after a year of insufficient hash power support, it would do the exact opposite and activate the soft fork at that point in time. Similar to a flag day, all upgraded nodes would from then on start enforcing the new rules. Miners whod still have failed to upgrade would risk mining blocks that upgraded miners and users would reject.

The main idea behind BIP 9 is that assuming of course that users upgrade miners cant block the soft fork and therefore cant use this leverage to their benefit. They can speed activation up and help coordinate a smooth protocol upgrade, but the upgrade will eventually happen even if they dont activate it themselves.

A more recent draft of BIP 8 includes some notable changes. For one, BIP 8 allows nodes to be configured for two different policies when the signaling period is about to expire: forced activation, as explained in the previous two paragraphs, or no forced activation, like with BIP 9. Furthermore, instead of activating the upgrade itself, nodes (if so configured) actually enforce signaling for the upgrade. Blocks that do not signal support for the upgrade are then rejected, hence still guaranteeing the upgrade, at least for the upgraded nodes. The combination of these two changes has the interesting property that if a majority of all Bitcoin hash power is compelled to signal support for the upgrade, even BIP 8 nodes that arent configured to enforce signaling will go along with the upgrade,

An argument against BIP 8, and its forced signaling (or automatic activation) in specific, is that it can be risky, especially on a shorter timeline. If a hash power majority and at least some users dont upgrade, this scheme could split the network between upgraded and non-upgraded nodes. Assuming most users support the upgrade, this would likely resolve in favor of the upgraded part of the network eventually. But non-upgraded users would risk losing funds in the meantime, while non-upgraded miners would waste hash power to the detriment of Bitcoins security.

This risk is probably best countered by offering enough time to upgrade. Unfortunately, not everyone agrees on how much time is enough; some think forced signaling could start within a year, others believe it should take several years.

Another complication with BIP 8 is setting defaults for forced signaling. If forced signaling is switched off by default, users could find themselves uncoordinated, increasing the risk of network splits. If on the other hand forced signaling is chosen as the default in a Bitcoin Core release, the historically widespread adoption of Bitcoin Core virtually guarantees that the upgrade will happen. Some believe this would give Bitcoin Core developers too much influence over Bitcoins protocol rules. For this reason, BIP 8 coauthor Luke-jr prefers BIP 8 with forced signaling to exclusively be deployed through special clients, similar to the BIP 148 client.

Others argue that Bitcoin Core developers always release software to their best judgement, while keeping user demand in mind and avoiding contentious upgrades; setting BIP 8 defaults should be no exception to this policy. If anyone disagrees with the choices Bitcoin Core developers make after all, they can simply choose not to upgrade to a new release or even fork the Bitcoin Core code to launch a competing client altogether.

While Bitcoin Core developers indeed seek to take user demand into consideration and try to avoid contentious upgrades, not everyone is convinced this is always perfectly possible. Perhaps concerns about a proposed upgrade only surface when the software is deployed in a new release. Perhaps whole new issues arise after this release. Or perhaps Bitcoin Core developers simply missed something.

This is one reason why Bitcoin Core contributor Matt Corallo proposed a strategy dubbed Modern Soft Fork Activation. Modern Soft Fork Activation consists of three steps, together essentially realizing a combination of BIP 9 (or: BIP 8 without forced signaling) and BIP 8 with flag day activation (though forced signaling could be an option as well).

As the first step, BIP 9 would allow miners to activate the soft fork through hash power. If miners dont activate it in (say) a year, the first activation window expires. Then, as the second step, developers take some time to analyze why activation failed, and reconsider the proposal if they do find a concern with it. If they find there was no problem with the proposal, however, the third step is redeployment of the soft fork, this time using BIP 8 with flag day activation: miners get another chance to activate the proposal with hash power, but if they fail again, the soft fork activates when this second signaling period ends. (During this second signaling period, the hash power activation threshold could also be incrementally lowered over time, Bitcoin Core contributor AJ Towns suggests.)

By explicitly committing to BIP 8 redeployment if it turns out theres nothing wrong with the proposal, Corallo believes the strategy would offer the benefits of BIP 9 without the downside. The code is put out there during the first signaling period for everyone to consider, miners can coordinate a smooth upgrade if they so choose, and with no forced activation developers can take their time to reconsider the proposal if activation does initially fail. Meanwhile, miners would have much less to gain from blocking the upgrade for no good reason, as everyone knows it will eventually activate anyways.

The main argument against Modern Soft Fork Activation is that without miner cooperation, the process would take relatively long, and some consider the BIP 9 step a waste of time altogether. Corallos original proposal includes one year of BIP 9 signaling, followed by six months to reconsider, and finally two years of BIP 8 signaling before automated activation: a total of three-and-a-half years. While this timeline is of course not set in stone yet, shortening the different steps by too much would leave less time for reconsideration and/or upgrading (increasing the risk of network splits).

Due to the long time until potential forced activation, some also argue that miners can try and gain some political leverage after all: they can delay the upgrade for years.

Another, recent suggestion circulating through Bitcoins tech channels is perhaps best described as a bit of a merger between BIP 8 and Modern Soft Fork Activation, at least in spirit. The unnamed proposal would deploy a long BIP 8 signaling period, perhaps as long as Modern Soft Fork Activations three-and-a-half years, after which forced signaling triggers. However, if after (say) one year the upgrade didnt activate yet, developers would take some time to reconsider the proposal, like they would with Modern Soft Fork Activation.

If developers would find no problem with the proposal, and instead were to conclude that it simply hadnt activated due to miner apathy or another invalid reason, they could opt to deploy a new soft fork in the style of BIP 91, used during SegWit activation. This would effectively lower the hash power threshold for activation, presumably speeding up the process.

If, on the other hand, developers would find a problem with the proposal after all, they could deploy a new soft fork that would fix the problem, or even undo the original soft fork (in this case, Taproot) altogether. Assuming Modern Soft Fork Activations three-and-a-half-year timeline until forced signaling, there ought to be enough time left to take care of this.

The main argument against this proposal is probably that its not very elegant to deploy a soft fork that undoes another soft fork, if so needed. More concretely, it requires that miners and users upgrade to new releases before deadlines are reached, or risk splitting the network.

Finally, as a bit of an outlier idea, Bitcoin Core contributor Jeremy Rubin suggested that a concept he invented called Probabilistic Bitcoin soft forks, or Sporks, might be more incentive compatible than typical hash power enforced softforks.

The heart of the problem of BIP 9, Rubin argues, is that miners can delay upgrades at no cost of their own. Simply refusing to signal readiness for an upgrade is free, while it potentially offers them political leverage.

With Sporks, the readiness signal is no longer taken from a bit of data that miners include in the blocks they mine, but derived from the block header hash: the randomly generated proof of work they produced by investing time and resources. Upgraded nodes would agree that a small subset of valid block header hashes statistically to only be found every six months or so would trigger the upgrade.

Per the randomness of hashes, a miner would not control whether he produces regular block header hashes or upgrade-activating block header hashes; hed statistically just happen to churn out one of the latter sporadically. So, if his invested resources happen to generate an upgrade-activating block header hash, hed have two choices. Either, publish it to the Bitcoin network, earn the block reward, and activate the soft fork. Or, withhold from publishing, delaying the soft fork by about six months on average in our example but in doing so also giving up the block reward. Delaying the upgrade would come at a significant cost.

The main problem with Sporks right now is probably that its a relatively new idea, that hasnt been developed yet let alone tested in the wild. While some do consider the concept interesting, its as of yet not the most likely contender for Taproot activation.

Authors note: The debate on soft fork activation (and Taproot activation in specific) is in flux; this is a non-exhaustive overview of the different upgrade proposals, especially when it comes to variants of the proposals with alternative parameters and other tweaks, and all their pros and cons.

Another idea, which has been gaining some traction since this article was written (mostly), is to first deploy BIP 8 with a relatively long signaling period (say, two years), configured without forced signaling at the end of this signaling period. This allows miners to activate the soft fork relatively normally, as they have done several times in the past. However, if after some time (say, six months) the soft fork isnt activated, and there doesnt appear to be a good reason for the delay, a new client can be released with BIP 8 configured to force signaling near the end of the existing signaling period, or sooner. Assuming most miners then activate the soft fork either before or during this forced signaling period, both sets of BIP 8 nodes (with and without the forced signaling configuration) would enforce the soft fork on activation.

Read the original:

Bitcoin And Modern Soft Fork Activation Bitcoin Magazine - Bitcoin Magazine