Bitcoin Cash Scripting Applications: Representative Tokens (OP_GROUP)

Representative money is the term used for any token that has no intrinsic value but may be exchanged for a defined quantity of a commodity (typically gold or silver). This section addresses the use of satoshis as representative money, and more generally the use of satoshis to represent ownership of anything — stocks, bonds, physical goods, other cryptocurrencies, and “ICOs” (initial coin offerings) for example — an application that was named “Colored Coins” by the bitcoin community.

I believe that the recent success of Ethereum has been driven not by complex contracts (there is some question as to whether real, practical contracts will ever be useful in a blockchain) but to create ICOs (Initial Coin Offerings). The value of representative tokens is now proven in practice, for those who doubted.

But the ability to create representative tokens within the Bitcoin Cash blockchain, if done properly, could allow the tokens to take advantage of all of Bitcoin’s basic features (permissionless, trustless, no 3rd party, pseudo-anonymity, etc), all of the scripting features, and the nearly frictionless exchange of the representative token with Bitcoin Cash and other tokens.

The key justification for placing all representative money on the Bitcoin Cash blockchain (rather than each in its own blockchain) is atomic, trustless, permissionless, pseudo-anonymous exchange between any combination of bcc and representative token types. This feature enhances Bitcoin Cash from “an electronic payment system” (as worded in the Bitcoin white paper) into “an electronic exchange system”.

One extremely interesting feature of an electronic exchange system is pseudo-anonymous exchange. In a Bitcoin Cash with representative tokens, this can be implemented using “half-transactions”. Essentially, a half-transaction is a signed set of inputs and outputs that do not balance. For example, a participant (the “maker”) could choose to make a partial transaction with one input of 200 tokens of color “red”, and one output of 100 tokens of color “blue”. Another participant (the “taker”) may choose to “accept” this bid by appending an input of 100 tokens of color “blue” and an output of 200 tokens of color “red” (and perhaps a final BTC input and output that serves as transaction fee and change). This now constitutes a valid transaction since the input quantities equal the output quantities and therefore can be committed to the blockchain.

While there are many drawbacks to the above exchange — such as the difficulty of the “maker” to withdraw his bid — there are also many advantages since it constitutes an ad-hoc, trustless, anonymous, permissionless, peer-2-peer exchange mechanism. Note however that law enforcement can still require identification at the boundary between the representative token and real commodity — that is, when an individual attempts to redeem his representative token for the underlying good, identity will likely be required.

Another important feature is a commonality of addresses between the representative token and Bitcoin Cash. This allows automatic payment of interest or dividends (if necessary) to every holder of a token by making a payment in Bitcoin Cash to every address holding the token.

Finally, since the Bitcoin Cash wallet already allows arbitrary strings to be signed, it is a small extension to sign a string with every address in the wallet holding a particular colored coin. This can be used to implement per-share voting.

Regardless of your opinion of the recent controversy around ICO (initial coin offerings) ponzi schemes and fraudulent offerings, colored coins provide valuable features that can beneficially be used by legitimate offerings, ultimately including registered securities. In fact, all of these features together remove a lot of inefficiencies surrounding the current financial system — settlement is eliminated, shareholder registration and tracking for dividend payments happens automatically, and shareholder voting is simple.

There are currently several forms of colored coins proposed in Bitcoin today, which I describe in detail at the end of this document. But I would like to propose a new implementation of colored coins for Bitcoin Cash that can be implemented by adding a single opcode to clients, and has advantages compared to existing proposals.

The fundamental “killer app” advantage of this proposal compared to others is that it allows SPV wallets (phone wallets) to handle representative tokens using the same security model and mechanism as SPV wallets handle Bitcoin today.

OP_GROUP Colored Coins

OP_GROUP colored coins allow direct representation of assets as satoshis and embed the colored coin transfer and validation into the Bitcoin scripting language in a manner that allows colored coins to take advantage of scripting and that makes them very easy to implement for existing Bitcoin Cash implementations.

A new instruction is added to the scripting language called OP_GROUP. When the OP_GROUP instruction is encountered, it uses the data on the top of the stack as a group identifier, and adds/subtracts the value of this input/output to an integer (initialized to zero) that is associated with the group. This integer is called the “group balance”. If there is no OP_GROUP, the input/output is assumed to be in a default “bitcoin cash” group. At the end of transaction processing, every group balance must be zero except for the “bitcoin cash” group whose inputs may exceed its outputs to form the transaction fee (as occurs today). In other words, within every colored-coin group the satoshis input balance the satoshis spent.

The basic “colored” pay 2 public key hash script therefore looks like:

OP_DATA(group address)
OP_GROUP
OP_DROP
OP_DUP
OP_HASH160
OP_DATA(pubkeyhash)
OP_EQUALVERIFY
OP_CHECKSIG

This should look familiar. It is simply the P2PKH script we use today with 3 group instructions (OP_DATA, OP_GROUP, and OP_DROP) prepended. Note that the OP_GROUP instruction does not pop the group from the top of the stack, requiring a subsequent OP_DROP command. This is awkward but it allows un-upgraded clients to interpret the OP_GROUP as a no-op, making the transaction valid on clients that do not understand OP_GROUP (it looks like push data, no-op, pop data…). This scripting change therefore does not need a hard fork.

Creating and Destroying OP_GROUP Colored Coin Tokens

Next, we must make “mint” and “burn” operations that essentially are exceptions to the rule that the input and output within a group must always sum to zero. Luckily, we have also not yet defined a format for the data is that defines a group. So let us define a group identifier to be the hash160 of a ECDSA public key (in other words, a Bitcoin address). This will allow us to create an elegant mechanism to add and remove satoshis to the group.

To “mint” new coins into a group, if a transaction has an input that is signed by the same Bitcoin address as the OP_GROUP identifier, then the value of that input MAY be placed either in the group or in the bitcoin group (or part in each) in the outputs. Additionally, the first “mint” transaction could contain an optional OP_RETURN that contains a short human readable name for the group (a stock symbol, for example) and the hash of a document/contract that describes the group in detail. For example, a valid transaction could have an input of 200 BCC satoshis located at address ABC, and an output of 200 ABC.

To “melt” coins (remove them from the group), we use the same strategy. If a transaction input is grouped and signed by the same Bitcoin address as the OP_GROUP identifier, then the value of that input MAY be placed either in the group or in the bitcoin group (or part in each). For example if a transaction has an input worth 200 TOK on address TOK and 2 outputs: 100 TOK paying to any address and 100 BCH satoshis paying to another address, then this transaction balances.

In this way, only the owner of a group address can mint new colored coins or melt them back into BCH.

Some Observations

Decidability

One problem with this approach is group decidability. Essentially, if the OP_GROUP is inside a complex script (or even just an “if” statement), it may be impossible to determine at transaction validation time what group coins belong to (doing so would break the famous “halting problem” proof). But Turing’s result applies to “arbitrary programs”, so to solve this we can limit the scope of valid scripts. To begin with we will require that exactly one OP_GROUP exist, that it be immediately preceded by a data push of the group identifier, and that this OP_DATA(…), OP_GROUP pattern be the first 2 script instructions (as shown above).

Note that this exact problem exists today in Bitcoin and Bitcoin Cash when a wallet attempts to determine whether a particular transaction contains coins “owned” by the wallet. The solution is to limit the script types that wallets produce and that nodes relay to a small set of templates. Any “nonstandard” script that a miner includes in a block is ignored by the wallet.

Since limiting valid scripts is effectively how Bitcoin-family blockchains operate from the user’s perspective today, limiting valid OP_GROUP scripts to ones that follow specific templates is not a large difference.

So why make it an opcode at all, as compared to just a piece of data associated with every output? First, an opcode can be integrated with Bitcoin Cash’s transaction format easily, and second we leave the door open to relax some of these restrictions — to add new OP_GROUP transaction templates — if use cases emerge. For example, we could add a template that allows the OP_GROUP to be specified inside an “if X” statement if exactly one other output exists that also includes the OP_GROUP inside an “if !X” statement.

Hard fork, Soft fork, No fork?

Note that OP_GROUP colored coins can happen even without a hard or soft fork — all we need is a single miner to not reject these transactions as “nonstandard”.

But this would mean that illegal OP_GROUP transactions (where the inputs do not balance the outputs per group) could be added to the blockchain by a miner that accepts nonstandard transactions but interprets the OP_GROUP as a no-op. In this case it would be possible to simply define that the coloring is lost on every output in the illegal group transaction, and have a working system. This “hamstrung” operating mode is similar to the other colored coins proposals (summarized below).

However I believe that it is important to soft fork so that Bitcoin Cash miners enforce correct OP_GROUP semantics to ensure that coloring is not accidentally lost. No one wants shares of GOOG to be sent to someone as a couple of satoshis because they accidentally used an old wallet!

I believe that the problem of accidentally losing coloring, the lack of an agreed-upon standard, the transaction space supply issue, and the sense that colored coins do not have “commitment” from the maintainers of the blockchain software have deterred people from using colored coins. Instead they have opted to use a blockchain like Ethereum that embraces multiple token types wholeheartedly. However, a soft fork solves all of these issues.

Why Not Use Ethereum?

I believe that there is a place for representative tokens that allow only limited scripting functionality. There have been several high visibility bugs in Ethereum scripts that have resulted in significant loss of value for stakeholders. If a token does not need the power of the Ethereum turing-complete language, that power becomes a liability.

Summary

Compared to the other approaches described below the disadvantage of the OP_GROUP approach is that there is additional OP_GROUP data that is added to each colored coin output totaling 22 bytes, although it should be possible to compress this down to a few bytes by using a chainref (of course, “normal” bitcoin cash outputs are exactly as they look today so therefore require no additional space). The advantages are:

  • light and SPV wallet support,
  • minimal changes to existing Bitcoin script interpreters,
  • unambiguous and local token/color designation (other proposals require knowledge of the coin history to determine color which is why they are able to encode outputs more efficiently),
  • miner enforcement of correctness (this means that like bitcoin, a transaction sufficiently deep in the blockchain can be assumed correct by light wallets)
  • outputs that are limited to exactly one color,
  • integration with the scripting language,
  • and the ability to use half-transactions for anonymous p2p exchange.

The rest of this document reviews other colored coin proposals

Put the Group Data in OP_RETURN

(note this is not about running an entire meta-blockchain within OP_RETURN)

Placing what is effectively an attribute of the vout in the script is not as perfect as placing data in a data-only location. Unfortunately there is no such data-only location in the vout, but putting it in a separate vout marked with OP_RETURN (technically also a script, but one that is entirely data) is another possibility. Since this data would contain exactly what OP_GROUP contains, the two are functionally equivalent. However there are implementation problems that make it an inferior choice:

  1. Vouts are independent. This proposal creates a validation dependency between the OP_RETURN vout and the other vouts that would necessitate large code changes.
  2. OP_RETURN is able to be discarded by miners. This is fundamentally what it was designed to do and why its “value” must be 0. Miners would have to change code to keep them around, and break OP_RETURN’s original purpose.
  3. OP_RETURN has data size limits that would dramatically limit the number of vouts, even given proposed OP_RETURN size limit increases (to 220 or 520 bytes).
  4. Partial transaction signing would no longer work because a signer needs to sign vout N, AND some subset of OP_RETURN.
  5. The UTXO set database is organized by vouts, so you would basically have to extract the relevant data from OP_RETURN and put it into the database record associated with the vout — but this is exactly where it already exists if OP_GROUP is used.

Put a Meta-Blockchain in OP_RETURN

Specific technologies to do this are described below, but all have the following common problems:

  1. No SPV (phone) wallets. Data in OP_RETURN that makes up the meta-blockchain is not miner validated. So bogus info can be placed in the blockchain. This could create a lot of waste, but more importantly it means that all transactions must be client validated, requiring a full node. It effectively reduces the blockchain to a time-stamping machine. But bitcoin is both a time-stamping machine AND a transaction validator for good reasons.
  2. Limited OP_RETURN space.
  3. Weak integration with the “native” coin, since the meta-blockchain is mostly independent. Essentially, the only “integration” is that you can atomically issue a BCH and meta-blockchain transaction.
  4. A lot more complexity, code, and maintenance since an entirely new and separate blockchain with its own scripting and consensus rules is created.
  5. Independent is better. Any meta-blockchain technology can be more efficiently implemented as its own independent chain. It will be hard for any technology crammed into OP_RETURN to compete with its more functional, more efficient independent version.

EPOBC

This system uses satoshis as a token of representative money so basic Bitcoin functionality and scripting are possible. However, miners do not enforce the colored coin semantics. This means that it is possible to have committed transactions that are ambiguous or incorrect from the perspective of the colored coins. In these cases, the protocol defines the coloring as “lost”, which is a major drawback.

Input colors are assigned to outputs via an order-based scheme described here. In essence, all the input satoshis are lined up and marked by color in the order they appear. Next all the outputs are lined up against the inputs and the colors are transferred 1-to-1 from input satoshi to output. This algorithm results in some complexities; first, a single output may contain different tokens with different colors (for example, if the first 2 inputs are 500 satoshis each and colored red and blue, and the first output is 1000 satoshis, then that output is colored both red and blue). The quantity of each of these colorings and the color ordering within the output must be remembered. To determine the coloring one must track all transactions back to the color genesis, making light wallets very hard to implement).

Finally, the strict ordering of color makes it impossible to make bids using half-transactions, since one cannot create a partial transaction with the first input of color “red” and the first output of color “blue”.

But this protocol encodes the coloring more efficiently than my proposal since it encodes coloring exactly once per coin in the blockchain history.

Colu Colored Coins

The Colu Colored Coin protocol does not designate satoshis as representative money. It creates independent representative money tokens in the arbitrary data that is placed in the OP_RETURN data field of a transaction. This data contains instructions that transfer certain quantities of multiple assets from a particular input to a particular output. So the normal transfer of bitcoins from inputs to outputs is augmented by the transfer of arbitrary color amounts.

Since bitcoin miners ignore the OP_RETURN data field, it seems possible to include arbitrary data (spending colored coins you do not own, for example) in transactions. At best, these transactions can only be ignored by Colu Colored Coins clients, resulting in a potentially significant amount of bogus data in the blockchain and increased likelihood of client bugs.

Since the system does not use satoshis as representative money, none of the bitcoin scripting, signature validation, etc applies. It really seems to be effectively a completely separate system piggy-backing on the bitcoin blockchain.

Examining the transfer instructions located here, it seems that the assets being transferred are implied by the assets known to be on the inputs, and their order. This cannot be determined by looking at the prior spend in the blockchain history, you need to trace back the entire spend history since the asset was created. However “light-clients” and SPV wallets will not have this history so creating this type of client is likely difficult.

But by being located on the Bitcoin blockchain, the Colu Colored Coins can be atomically exchanged with bitcoin.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.