Let’s talk spec – #2 More opcode primitives

2018-11-23T11:53:15.000Z Honest Cash

This article is part of the Let’s talk spec series. We are writing a specification for a Bitcoin Cash protocol upgrade. Please read the introduction if you haven’t.

One of the central elements of Bitcoin is Script. Script is a programming language used in Bitcoin transactions. Bitcoin is programmable money.

The coins in your wallets are a collection of transaction outputs with a locking script on them. You own the coins because only you know how to to unlock them.

A more expressive Script language allows for more expressive locking scripts.

Opcodes (also called functions or commands) are how we can express our intention in Script. One simple example is the addition opcode OP_ADD. We can express the calculation of 1 + 1 as 1 1 OP_ADD.

In the last upgrade we introduced a new OP code that allows for amongst other things Forfeit Transactions, Pay to Identity and on-chain betting.

Addition of new op codes have several risks associated with them. They can introduce bugs such as crashes, inflation or excessive CPU consumption hindering scaling. It is also argued that too powerful scripting language interferes with the main purpose of Bitcoin - to be Digital Cash.

Four new OP codes are proposed for activation in this specification. These are:

  • Multiplication (OP_MUL)

  • Bitwise right shift (OP_RSHIFT)

  • Bitwise left shift (OP_LSHIFT)

  • Bitwise invert (OP_INVERT)

These were previously a part of Bitcoin, but disabled because at least one of them had a implementation crash bug.

As for my opinion, these functions are basic parts of any useful programming language and worth reintroducing. These are also enabled and being battle tested on the BCHSV chain.

Do these break the economics of Bitcoin? Do we want them? Should we add this to our May specification?

This article can be discussed here on reddit

Responses