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).
 

$7.15
$105.25

Reviews
32 of 33 reviewers say it's worth paying for

1 of 33 reviewers say it's not worth paying for

Comments
  spent 20.0¢
A neat post! Also worth mentioning in the description is that Bitcoin Script, like Forth, is stack based. Which is the main similarity to Forth (aside from being compact).
0.0¢
   9mo ago
2.0¢
  spent 20.0¢
Nice write up, I love posts like this!
0.0¢
   9mo ago
2.0¢
  spent 20.0¢
Thanks Eli. Updated the article to mention it but I think you're right, there should be more focus there. I probably glossed over it because I really wanted to write more about what CSW was describing here, but details on how this might work are hard to come by.
0.0¢
   9mo ago
  spent 20.0¢
I've long thought that people should have the option to compute Proof-of-Work themselves as an alternative to transaction fees. Something like OP_TRANSACTIONPOW(nonce) could provide the basis of that feature.
Users could craft a transaction, including OP_TRANSACTIONPOW and iterate through nonces, until the resulting signature is pretended by a significant number of 0's.
If approved, and if miners accept the change, it would allow transactions to be crafted using OP_TRANSACTIONPOW without including a transaction fee while still proving that the transaction means enough to them to give up something in exchange.
0.0¢
   9mo ago
  spent 20.0¢
And what's in it for the miners? I as a miner dont care if you sweat your ass off doing work...
0.0¢
   9mo ago
  spent 20.0¢
Another great post, Satchmo. Tipped $100.00. This is high quality, useful information about Bitcoin Cash, and we need more like this, so I will keep pitching with a bit of funding :)
0.0¢
   9mo ago
  spent 20.0¢
Are you kidding me dude!? You are amazing and so is yours. Glad to be here with you guys. I'll keep writing! Thank you so much!
0.0¢
   9mo ago
  spent 20.0¢
Great beginner article on Opcodes. I would be really interested in more detailed and theoretical possibilities of them and how it could change society.
0.0¢
   9mo ago
  spent 20.0¢
Thanks. I notice a lot of newcomers frequenting yours so I was struggling to keep this palatable for them too. It's really easy to get in the weeds with this stuff. Thanks for letting me know there's a demand for a more technical perspective. Hope to deliver on that soon ;)
0.0¢
   9mo ago
  spent 20.0¢
the TL:DR for the non-tech savvy people is that OP_CODES enable developers to make Bitcoin Cash more useful and valuable.
In turn, a coin with more utility = higher market value and a larger network effect.

0.0¢
   9mo ago
  spent 20.0¢
I bought the article as well and I tipped! I want more content like this!
0.0¢
   9mo ago
  spent 20.0¢
> And what's in it for the miners? I as a miner dont care if you sweat your ass off doing work...
The worst thing Blockstream ever did was create the fee market and then use it to convince miners that they deserve extra fees from users. The transaction fee isn't supposed to be to pay miners for their work, that's what the block reward is for. The fee was supposed to be a way to show that a transaction is valuable to a user. If there can be an alternative way to accomplish that, then it would benefit the network because it would prevent the fee market from ever coming back in Bitcoin Cash.
0.0¢
   9mo ago
  spent 20.0¢
Well if you think like that you should check out XRB and the likes.
0.0¢
   9mo ago