Bitcoin's Dead Sea Scrolls - Disabled Opcodes to be Resurrected by Bitcoin Cash
Since Bitcoin smashed its way into our lives in 2009, a slue of competing cryptocurrencies have emerged to solve lots of interesting problems Bitcoin just wasn't designed to handle... or was it?
The Elegant Roots of Bitcoin
Bitcoin uses a 'simple' internal stack based scripting language called Script. It has been criticized by some for it's lack of Turing completeness, and heralded by others for it's role underpinning Bitcoin's security. It is similar in nature to Forth, also a stack based language known for its compactness, simplicity, low resource consumption, and as a result, stability and maintainability.
For a visual example, this code:
: hp 15 0 do 5 f 1 t loop 15 0 do 2 f -1 t loop ; : petal hp 30 t hp 30 t ; : flower 15 0 do petal 4 t loop ;
Was used to create this flower in Forth:
Many Forth applications have been in production for decades in the wild because of these properties. It seems only natural that a system intended to be as critical, resilient, and constrained as Bitcoin would draw inspiration from Forth. While Forth is a Turing complete language, Script is not. Instead it is made up of a limited set of opcodes that perform various functions. This was entirely intentional. For example, looping is not available in Script, making lot's of typical tasks nearly impossible to code.
One fantastic example of why looping was considered more "dangerous" and excluded from Script in the earliest versions of Bitcoin was the DAO hack on the Ethereum blockchain. Ethereum's scripting language does allow for looping. It is commonly used in ETH smart contracts, not only because it's very convenient and powerful, but because there's no other (obvious) way to do it.
With great power, comes great responsibility
The DAO hack required the exploit of two functions working together to provide the deadly results. Ultimately, it came down to a recursive call to a split function that stole the funds. In order to create a recursive loop, you must be able to loop in the first place. No loop, no DAO hack, but then again probably no DAO either...
Besides the intentional omissions of some Forth functionality, Satoshi created but disabled several of the original opcodes. Erring on the side of caution, these were intended to be enabled carefully as Bitcoin matured. Turning them back on would require careful implementation to prevent serious risks to the network. In addition, implementing new op codes or re-enabling them would require a hard-fork. This was something Bitcoin core developers wanted to avoid for obvious reasons.
Due to the great risks associated with enabling op-codes, many were removed from the codebase with the intention of resurrecting them in Script v2, which was never released. A few prominent Bitcoin core developers, such as Gregory Maxwell, continued to search for answers using off-chain solutions, bypassing the problems altogether. With the shelving of these opcodes, and the intensification of the scaling debate, some exciting use-cases faded from conversation for the time being and layer 2 solutions became a research and development focus. The good news is, thanks to the Bitcoin Cash fork, the original idea of enhancing Script is once again alive and well.
Bitcoin's Dead Sea Scrolls
There are 15 opcodes that are still disabled in Bitcoin to this day. Programmers will notice many of these are very basic bitwise, string handling, and arithmetic functions:
If I went through each of these and described a potential use case I might finish this article some time next week so in the interest of pressing the publish button, I'm only going to cover a couple. If any of the others present an interesting use cases please let me know in the comments so I can update the article.
What could Bitcoin do with these opcodes enabled?
These are low level building blocks that would be used in a variety of programming patterns and potentially many use-cases we haven't yet considered. It's not always straight forward to list use-cases because it's an embarrassment of riches. These opcodes would be used a lot once enabled. To paint a rough picture of what might come to light, I'll name one or two examples for each opcode category. Keep in mind there will be many, many more examples for each of these in practice:
OP_CAT, OP_SUBSTR - String Manipulation What they might enable: Improved multi-signature techniques, improved 0-confirmation transaction security, and new opcodes outlined in paid section. Why OP_CAT is disabled: OP_CAT concatenates two strings (think signatures). Pretty simple. The problem with things like this are related to resource consumption. Whenever you concatenate (combine), you're potentially taking up more space on the stack and risk a memory exhaustion attack with exponential growth. This type of attack would "blow up" the Bitcoin stack and crash all the nodes, particularly in conjunction without OP_DUP. There are many proposed approaches to dealing with this risk such as limiting the total size OP_CAT can output, but limits themselves can lead to serious bugs if they are not consistently enforced everywhere in the code. OP_SUBSTR is a similar to OP_CAT, but reduces stack size, and so it is considered much less risky. Note on 0-confirmation: We know that Satoshi believed 0-conf transactions on the Bitcoin network could be secure enough to verify a transaction within 10 seconds or less, but only in a network topology where miners sustain many simultaneous "edges" or active connections. This would ensure fast propagation through the network, putting double spend attempts with even a slight delay from the original at a severe disadvantage, and highly unlikely to be confirmed before the original. Despite this, many have over-emphasized the risk of 0-conf transactions and exacerbated the problem by introducing replace-by-fee transactions which make the possibility of double spending much higher. This effectively breaks the security of fast 0-confirmation transactions. Lucky for us, BCH does not have this impedance and we are sure to see innovation in this area.
OP_AND, OP_OR, OP_XOR, OP_INVERT - Binary Operations In programming, bitwise operators like AND ( & ) OR ( | ) and Exclusive OR ( ^ ) allow the comparison of binary data (the 1s and 0s), which is much more efficient than using standard arithmetic or string comparisons. This has implications for data integrity and compression (scaling), and would be a useful toolset for coding smart contracts too. Things like 'unbreakable' XOR Ciphers become possible. These have also been mentioned in conjunction with introducing true transaction anonymity.
OP_MUL, OP_DIV, OP_2DIV, OP_2MUL, OP_MOD - Basic Arithmetic These represent basic arithmetic and I don't think I need to explain how math would be useful in Script. Some of these are also necessary for implementing the newly proposed OP_DATASIGVERIFY.
New Op Codes Below I share the deets on the two newly proposed opcodes OP_DATASIGVERIFY and OP_GROUP which unlock some exciting and innovative new functionality for Bitcoin (Cash).
32 of 33 reviewers say it's worth paying for
1 of 33 reviewers say it's not worth paying for