Bitcoin Cash Scripting Applications: Representative Tokens (OP_GROUP)

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.

OP_DATA(group address)

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.

Some Observations



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.

Put the Group Data in OP_RETURN

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

  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.


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.

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.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store