The importance of backward compatibility

Earlier we wrote briefly about the difference between a hard fork and a soft fork and the importance of preventing a hard fork. This is all about maintaining backward compatibility.

Not just excluded

When someone chooses to participate in bitcoin, they agree to the rules of the protocol. These rules cannot simply be broken, because this would mean that some of the users suddenly can no longer participate or suddenly become part of a system of agreements with which they do not agree.

‘Upgrading’ bitcoin is therefore difficult: some new features that people would like to see added can have consequences for the rules that were agreed in the past. For example, with a forced upgrade, a hard fork, someone who chooses not to use a new feature can no longer participate in the system. In a system like bitcoin, this must be prevented, because it damages the reliability and stability of bitcoin.

As a refresher, let’s quickly tell the difference between a hard fork and a soft fork. With an upgrade via hard fork, the existing rules are expanded, so the new rules do not fall within the current agreements. This creates a break in backward compatibility. With an upgrade via soft fork, you operate within the existing rules. This preserves backward compatibility.

A different way of developing

Therefore, a lot of effort is put into the development of bitcoin to implement new additions as much as possible in such a way that an upgrade is optional; through a soft fork. By making the upgrade optional, no one is left out. One cannot be expected to download the latest version of ‘the rules’ before they continue. Also, it cannot be expected that everyone just agrees with new rules. A bitcoin is a bitcoin, and its definition should be the same today as it will be 100 years from now. By applying a conservative policy, it is now possible to open your wallet or node from five years ago and perform a transaction. This is accepted by the bitcoin network without any problems.

Those who want to use the new feature can do so and those who don’t can continue to make payments as they always have. An example of such a voluntary upgrade is the segregated witness soft fork, which currently accounts for approximately 40% of transactions. The other 60% were not affected. If segregated witness had been implemented as a hard fork, then two different blockchains would have emerged, each with their own rules. Implementing upgrades through a hard fork therefore creates a series of endless splits of the network.

Safety, decentralization and resilience come first

When debating whether or not to implement a change, the debate is often not even entirely about the change itself, but rather about maintaining backward compatibility. If adding a certain feature is at the expense of backward compatibility, then the option is to keep backward compatibility.

If this is not done, old versions of the software can no longer unite with the current network and the rules that new software adheres to are considered invalid by the old software. A system where this is possible is not a stable platform on which to run a global means of payment. A hard fork is only considered when it is really necessary to implement a change. For example, if it turns out that the current cryptography is no longer secure and needs to be replaced.

In addition, the possibility of making a change that breaks backward compatibility would be sensitive to all kinds of influences from different parties with different interests: it makes bitcoin vulnerable. Who determines which change is forced to be implemented? In a decentralized system like bitcoin there is no authority for this. Only the network as a whole can implement a change.

Having a policy of preserving backward compatibility at all costs may seem like a rigid policy for a software project, but it serves as a way to coordinate the project without leaving the project vulnerable to takeover by a single party. This guarantees the continuity of bitcoin.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

© 2024 Cryptocoin