How is the Bitcoin network updated? Update overview

Taproot, a proposed protocol upgrade, is in late stages of development. Bitcoin Core Developersagree that this update will bringthe benefits of 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

Taproot update will be activated insoft 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 planned to be activatedon 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 network separation (in those days, Bitcoin miners and users were often the same people).

Since the non-updated nodes remaincompatible, this means that there is no urgent need to immediately update all nodes when new protocol rules are applied, which gives more flexibility (although users are still encouraged to accept updates, since they are the ones who enforce the new rules by rejecting transactions and blocks that violate them ).

Since about 2012, soft forks have increasingly starteduse the hash rate as a coordination 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 new rules. With sufficient hashrate support, all updated nodes are launched to apply the new rules.

This strategy is described in BIP 9 Proposal forimprovement of bitcoin (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 would (or not) signal support for it. 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, butonly after alternative bitcoin clients have 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 reduced the hashrate requirements from 95% to 75%. Most Bitcoin Core developers recognized BIP 9 as not the best solution and started thinking about alternatives.

BIP 8

BIP 8 was the first alternative solution to BIP 9,which was suggested by BIP 148 author Shaolinfry and Bitcoin Core developer Luc Dashir. It differed from BIP 9 in that instead of canceling the update after a year due to insufficient hashrate, the exact 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 minerscannot block a soft fork (provided that users support it) and, therefore, cannot use this influence to their advantage. They can speed up activation and help coordinate the protocol update, but the update will eventually happen even if they don't activate it themselves.

The argument against BIP 8 and its enforced (orautomatic) 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 not updated nodes. The developers assumed that the majority of users would support the update, and this would ultimately solve the problem in favor of an 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, Bitcoin Core developer MattCorallo proposed a solution called Modern Soft Fork Activation. This activation consists of several steps, which are essentially a sequential implementation of BIP 9 and BIP 8.

In the first stage (BIP 9), miners canactivate soft fork with hashrate. 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 - repeateddeployment of a 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 ForkActivation 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 oneyear BIP 9, then six months to review the update, and finally two years on 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 the bestdescribe as an option for the general implementation of BIP 8 and BIP 91. It provides for a long period of BIP 8. If, for example, after one year the update is not activated, then the developers will take some time to revise the proposal (as in Modern Soft Fork Activation).

If the developers find no problems withproposal (it turns out that it was not activated due to the passivity of miners), they can choose to deploy a new soft fork on 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 findthere is a problem in the proposal, they can deploy a new soft fork that fixes the problem, or even completely reverse the original soft fork (Taproot in this case).

The main argument against this proposal is that it is not very advisable to deploy a soft fork, which, if necessary, can cancel another soft fork.

Sporks

Bitcoin Core developer Jeremy Rubin suggesteda concept of a "probabilistic bitcoin soft fork" called Sporks, which offers more incentives than typical hashrate soft forks.

According to Rubin, the problem with BIP 9 isthat bitcoin miners can defer updates at no cost. 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 fromdata that 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 the hashes, the miner cannotcontrol which hashes it generates - regular 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 isthat this is a relatively new idea and little studied. While some developers find this concept interesting, at the moment it is not the most likely contender for Taproot activation.

Addition

Another idea that began to be actively discussedafter preparing 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 so thatas 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 to 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 forced activation period, 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.

</p>

Rate this publication