Translation of Aharon van Widrum's article for Bitcoin Magazine. Taproot, the proposed protocol update, is in its late stage...
Translation of Aharon van Widrum's article for Bitcoin Magazine.
Taproot, the proposed protocol update, is in its late stages of development. Bitcoin Core developers agree that this update will benefit Bitcoin; much of the broader bitcoin community welcomes the update as well. Therefore, it is very likely that Taproot will be included in the Bitcoin Core release, and later will appear in other implementations of Bitcoin clients.
But one question arises: how to activate updates on the bitcoin network itself? Taproot is a consensus protocol change. This means that the nodes must somehow switch from the old rules to the new ones without dividing the bitcoin network.
Previous soft forks and BIP 9
The Taproot update will be activated through a soft fork. This type of update adds or tightens rules - as opposed to a hard fork, which removes or relaxes rules. The essence of adding or tightening the rules is as follows: everything that the updated node considers valid, the non-updated node also considers valid. If the old node accepts both types of transactions (A and B), and the new rules only allow transactions A, then the old node will remain compatible with the rest.
The earliest soft forks were scheduled to activate on a specific day (flag day). The developers (in particular, Satoshi Nakamoto) indicated in the code of the new bitcoin client the time when the updated nodes would apply the new rules. It was recommended that the system be updated prior to this date to avoid splitting the network (in those days, Bitcoin miners and users were often the same people).
Since the non-updated nodes remain compatible, this means that there is no urgent need to update all nodes immediately when the new protocol rules are applied, which gives more flexibility (although users are still encouraged to accept updates as they are the ones who enforce the new rules by rejecting transactions and blocks that violate them).
Since about 2012, soft forks have increasingly started using hash rates as a coordinating mechanism for the transition to new rules. By adding certain data to their blocks, miners can inform the rest of the network that they have updated their software and are ready to apply the new rules. With sufficient hashrate support, all updated nodes are launched to apply the new rules.
This strategy is described in BIP 9, the Bitcoin Improvement Proposal (BIP). BIP 9 was used to activate the latest bitcoin update called Segregated Witness (SegWit). Miners had a year to activate the update; it was required that 95% of the blocks during any interval of complexity include a signal of readiness to update. If this had not happened a year later, the update activation period would have expired.
However, BIP 9 cannot be called hassle-free. As in some previous updates, some miners did not carry out the update, since they have no significant incentive to carry it out quickly. But the big problem was that some miners began to view this process as a kind of update vote, where instead of signaling readiness, they will (or will not) signal support for it. Even worse, some miners have decided to use this “vote” to try to gain political leverage over the Bitcoin mining process.
After much discussion, SegWit was activated, but only after alternative bitcoin clients enabled new activation schemes. BIP 148, included in the BIP 148 client launched by some users, was programmed to accept only those blocks that signal protocol upgrade support. At the same time, BIP 91 included in the btc1 client actually lowered the hashrate requirements from 95% to 75%. Most Bitcoin Core developers recognized BIP 9 as not the best solution and began to think about alternatives.
BIP 8
BIP 8 was the first BIP 9 alternative solution that was proposed by BIP 148 author Shaolinfry and Bitcoin Core developer Luc Dashir. It differed from BIP 9 in that instead of canceling the update a year later due to insufficient hashrate, the opposite will be done - the soft fork will be forced on a certain day. All updated nodes from now on will start applying the new rules.
The main advantage of BIP 8 was that miners cannot block the soft fork (provided that users support it) and therefore cannot use this influence to their advantage. They can speed up activation and help coordinate a protocol update, but the update will eventually happen even if they don't activate it themselves.
The argument against BIP 8 and its forced (or automatic) activation is that such an update can be very risky for short periods of time. If the majority of the hashrate and some part of the users do not update, then this scheme can divide the network between the updated and non-updated nodes. The developers assumed that the majority of users would support the update and this would ultimately solve the problem in favor of the updated part of the network. However, non-updated users risked losing funds, while non-updated miners would waste hashrate at the expense of network security.
Modern Soft Fork Activation
While the Bitcoin Core developers strive to accommodate the interests of users and try to avoid controversial decisions, they cannot have absolute confidence in the correctness of the update.
In this regard, the developer of Bitcoin Core Matt Corallo proposed a solution called Modern Soft Fork Activation ("Modern activation of a soft fork"). This activation consists of several steps, which are essentially a sequential implementation of BIP 9 and BIP 8.
At the first stage (BIP 9), miners can activate a soft fork with a hash rate. If miners do not activate it (conditionally) after a year, then the first activation window will expire. It then takes developers some time to analyze why the activation failed and reconsider the proposal.
Then comes the third stage - redeploying the soft fork, this time using BIP 8 activation: miners get another chance to activate the offer with a hash rate, but if they fail, the soft fork is activated automatically (during the second period, the activation threshold with a hash rate may also gradually decrease ).
The main argument against Modern Soft Fork Activation is that without the cooperation of miners, this process would have taken a relatively long time, and some believe that the stage with BIP 9 is a waste of time. Corallo's original proposal includes one year of BIP 9, then six months to review the update, and finally two years of BIP 8 with automatic activation. Thus, it could take three and a half years for an update to be accepted. According to some developers, because there is so much time left before a potential automatic activation, miners can use this as a kind of political leverage, since they can simply postpone the update.
BIP 8 + BIP 91
This (as yet unnamed) proposal is best described as a common implementation of BIP 8 and BIP 91. It provides for a long BIP 8. If, for example, after one year the update is not activated, then it will take developers some time to revise the proposal (as in Modern Soft Fork Activation).
If the developers find no problems with the offer (it turns out that it was not activated due to the passivity of the miners), they can choose to deploy a new soft fork via BIP 91, which was used to activate SegWit. It will lower the hashrate threshold, which should speed up the activation process.
On the other hand, if developers find a problem in the proposal, they can deploy a new soft fork that fixes the problem, or even reverse the original soft fork (in this case, Taproot) entirely.
The main argument against this proposal is that it is not very advisable to deploy a soft fork that can reverse another soft fork if necessary.
Sporks
Bitcoin Core developer Jeremy Rubin proposed a concept of a "probabilistic bitcoin soft fork" called Sporks, which offers more incentives than typical hashrate soft forks.
The problem with BIP 9 is that miners can delay updates at no cost, Rubin said. They may simply refuse to signal readiness to upgrade, which could potentially give them political clout.
In Sporks, the ready signal is no longer taken from the data miners include in the blocks they mine. It is retrieved from the hash of the block header - a randomly generated proof of work that they created after spending their time and resources. The updated nodes would agree that a specific subset of the valid block header hashes will trigger the update.
Due to the randomness of hashes, the miner cannot control which hashes he generates - regular hashes or hashes that activate the update; statistically it can randomly generate the latter. If the miner generates a hash that activates the update, he will have two options: either broadcast it to the Bitcoin network, earn a block reward and activate the soft fork, or refuse to broadcast the hash, activate the soft fork and the block reward. Thus, the delay in updating can be costly for miners.
The main problem with Sporks is that it is a relatively new idea and little understood. While some developers find this concept interesting, it is not the most likely contender for Taproot activation at this time.
Addition
Another idea, which began to be actively discussed after the preparation of this article, was to first deploy BIP 8 with a relatively long period (for example, two years) without forced activation at the end. This allows miners to activate the soft fork as they have done several times in the past. However, if after some time (say, six months) the soft fork is not activated, and there is no compelling reason for the delay, BIP 8 with forced activation may be released in the new client. It is assumed that most miners will activate the soft fork either before or during this period with forced activation, and all nodes with BIP 8 (with and without forced activation) will support the soft fork.
Author's note: The debate on soft fork activation (Taproot activation in particular) continues; not all upgrade proposals are presented in the overview.
