Limited change to bring stability

Something people fail to understand about bitcoin is it is intentionally limited in what it can do and how it can be changed. This is purposeful. Bitcoin is designed to be stable money and for that reason it is not designed to have new opcodes added outside the need for a few security based replacements or to be altered. The very limited number of reserved words within bitcoin are incredibly necessary. If these are wasted, the future of bitcoin as a protocol is extremely limited. Some of these have already been wasted to implement time-based functions that could have been and have been enabled using nLockTime more efficiently.

These keywords within bitcoin are:

· OP_RESERVED, OP_RESERVED1 & OP_RESERVED2

· OP_NOP1-OP_NOP10

OP_NOP2 and OP_NOP3 have already been wastefully squandered to provide the following opcodes:

· OP_CHECKLOCKTIMEVERIFY

· OP_CHECKSEQUENCEVERIFY

Neither of these opcodes were necessary within the bitcoin system but were added solely to enable the theft of network effect in an attempted migration to a separate system using lightning. There is no business case that cannot be completed with CLTV that could not have used nLockTime based Bitcoin transactions. The same or better result can be delivered using nLockTime as CLTV. So, there is no purpose for CLTV.

Contrary to the false Core narrative, new opcodes are not designed to be added using a soft fork. Soft forks are not a part of bitcoin and destroy the competitive nature of the system.

In this blog post I will describe the reasoning behind these (spare) opcodes and why it is important that they are not wasted on foolish experiments. Bitcoin was designed with a limited number of these codes in advance to ensure a long-term monetary migration on a stable system.

OP_NOP(x) and OP_RESERVED(x)

The extended no_opcodes are needed to replace the hash variables within bitcoin. OP_SHA1 is already at the end of life and is known to be compromised as SHA1 has been demonstrated to have known collisions.

OP_RIPEMD160 is not expected to last more than a decade due to weaknesses in the RipeMD160 algorithm strength. OP_HASH160 is a joint process where the input to this function is hashed twice: first with SHA-256 and then with RIPEMD-160. When RipeMD160 needs to be replaced, the requirement is that two of the OP_NOP(x) opcodes be redeployed and the OP_VER (and related) op codes are updated to mark the script change at a certain height and for the transitional period.

SHA256 remains strong for the present, but all hash functions will have a lifespan. There are three (3) opcodes in Bitcoin that are directly based on SHA256, these are:

· OP_SHA256 The input is hashed using SHA-256.

· OP_HASH160 The input is hashed twice: first with SHA-256 and then with RIPEMD-160.

· OP_HASH256 The input is hashed two times with SHA-256.

Further, there are a number of indirect opcodes that use SHA256 that would need to be replaced if any weakness in the hash functions used by Bitcoin was discovered, these are:

· OP_CHECKSIG

· OP_CHECKSIGVERIFY

There are seven listed functions here and additionally, when, note not if but when problems happen as a result of the currently deployed ECDSA-256 bit curve, ECDSA-512 or some other public private key algorithm will need to be integrated requiring the replacement of:

• OP_CHECKSIG

• OP_CHECKSIGVERIFY

• OP_CHECKMULTISIG

• OP_CHECKMULTISIGVERIFY

All up, the current version of the bitcoin protocol has implemented 10 OP_NOP(x) opcodes, 2 OP_RESERVE(x) opcodes and OP_RESERVED for other miscellaneous problems.

That is, we have a complete total of 12 opcodes changes that need to be maintained for the future bitcoin. There are 10 functions within bitcoin that will need to be changed in the future that are defined. As we have two wasted spare opcodes, we actually have no room for error in future updates. As an absolute minimum there needs to be two hash functions in the public private key algorithm.

The minimum for updating the hash functions will be four (4) opcodes. The absolute minimum on updating the digital signature is also four (4) opcodes.

The consequences if we want bitcoin to remain and be a viable system that will last more than 20 years, we are down to two spare opcodes already. Of the total of 10 that are needed for hash and digital signature algorithms only eight remain.

Bitcoin was set in stone as of version 0.1.0

This is a part of what this means. The design of bitcoin is not to create an idealised socialist utopia, it is to create stable global money. To do this, it is required that we have a system that does not change without reason. We have already seen this being subverted by developers. The idea at present is to experiment first play by adding bells and whistles and hope for the best. This may be the way that many applications work within Silicon Valley, but it is not how money works and this is one of the key problems right now.

In bitcoin cash, we had the foolish attempt to mindlessly add additional opcodes and the reason was that this would bring traffic. It is exactly the opposite of what is needed. Financial organisations and even the idea of a listed ETF derived from stability. Right now, this is the one thing bitcoin fails to exhibit as people constantly try to change it.

Bitcoin cash is bitcoin and we’re going to work to return it to the version 0.1.0 implementation and lock that protocol. The reasons for reserved opcodes should be clear. They are necessary to create a script system that is stable and can be used as a financial system. To do this, we need to be able to create contracts that can last not one, or five, or even 10 years. There are financial instruments that last over 100 years. If bitcoin is money, it must be able to handle these and that requires stability.

With the existing script code fully re-enabled, there is nothing that could be conceivably desired that cannot be done within bitcoin. The lack of vision of one developer does not require that the entire system and protocol is changed.

Right now, everything that developers are doing to alter bitcoin is an experiment that drives adoption away.

Bitcoin needs to be a stable system to be money. We have invested in hash power and intend to use that for the sole goal of scaling and stabilising bitcoin.

Bitcoin is explicitly designed not to allow people to start arbitrarily altering the structure of script.

The primary deliverable in bitcoin is a stable system. When you are told that we need to develop to integrate to grow, the reality is that this is about scaling the existing bitcoin protocol and developing on top of that protocol. Bitcoin is an economic system it is not designed to be altered frequently.

Traditionally, banks used marble edifices to signal their stability. This was designed to say that they would be there unchanging unflinching and available for the foreseeable future. It’s time that we started bringing this to bitcoin and making bitcoin cash.

Stability

Unfortunately, there are many things in Bitcoin (including the OP_Codes added above like CLTV and CSV) that have been added and must now remain. P2SH is one of these horrible kludges. These cannot ever be removed. This is not the same as making a bad script and losing a little of your own funds. Any additions to the protocol we have just noted are permanent. Bitcoin cannot ever be altered to reverse these changes.

The atomic structure of Gold is defined.

If you add or remove a proton, it is no longer gold. Some changes (P2SH) are analogous in Bitcoin to adding a neutron to gold, it can be done, but the resulting system is less stable.

It is time to start moving away from the idea that Bitcoin is broken and to start scaling it and allowing it to become what it was designed to be — Stable money.