Representative Tokens (i.e. Colored coins) on Bitcoin Cash have generated a lot of excitement within the community, and seems to be the raison d’etre for Ethereum. There is even a significant bounty placed on this functionality. The aim of this article is to be a brief introduction to Bitcoin tokens systems, and requirements of such systems.
Currently, there are a number of mechanisms put forth for Bitcoin Representative Tokens, with a spectrum of dependence on the Bitcoin base protocol. There are Omni and Counterparty which use Bitcoin Cash primarily as a data storage mechanism for second layer smart contracts. Andrew Stone has proposed OP_GROUP which makes a small change to the UTXO format and transaction validation rules. Coins can also be colored via a 2 of 3 multisig wallet where a third party enforces rules on transaction outputs. Finally, covenants allow for script to enforce rules on transaction outputs such that the outputs do not lose their coloring.
Each of these solutions have different trade-offs, and in order to evaluate them we should compare them against the requirements for an ideal solution. To determine those requirements, we need to first revisit one of the key properties of Bitcoin to understand how representative tokens differ from normal coins. This property is that Bitcoins are both a unit of account, and a medium of exchange. Knowledge of private keys proves ownership of the associated BCH. This means that blockchain data regarding BCH is always fully congruent with what is actual.
On the other hand, representative tokens represent something else which exists outside of the blockchain. Possession of a private key which controls representative tokens does not guarantee that an individual is physically in possession of the subject of a token, that there is such an object, or that the token may be redeemed. Due to the nature of these tokens, there is always a trusted third party which must issue them and reconcile state when the blockchain and the rest of the world disagree.
An example of such reconciliation was November 20th of 2017. Tether was hacked and erroneously issued 30 million USDT. In order to reclaim those funds, Omni had to perform a hardfork to lock up those tokens. It is likely that private key material was compromised in this hack, thus enabling the attacker to continue to issue USDT at whim had no hardfork occured. If this functionality were within the base-layer of the Bitcoin protocol, Bitcoin itself would have had to perform a hardfork or let USDT become worthless.
Having such trusted third parties is antithetical to the purpose of the Bitcoin ledger. However, it should be acknowledged that having an open standard for transferring assets is valuable, and Bitcoin can perform that function. Yet, it should not be forgotten that such a trusted third party exists simply because a token exists on the Bitcoin blockchain.
As such, any representative token system which is implemented in the base layer of the Bitcoin Cash protocol requires functionality to enable the trusted third party to manage tokens which are, in practice, only on loan to Bitcoin users. Additionally, as the point of including these tokens on a blockchain is to have an open standard for asset transfer, this specifies other requirements.
These requirements are as follows:
1. Ability to issue tokens and destroy tokens by only the administrator of the token
2. Usable in SPV wallets without relying on a proprietary 2nd layer protocol
3. Ability to rotate token issuing key material.
4. Ability to accommodate revocation, and backup, keys.
5. Ability to recall tokens.
Additionally, there may be other functionality that is required to make tokens useful for their intended purpose to users. Taking the example of the ERC20 specification, the following functionality should be supported, or supportable through future Bitcoin Cash protocol upgrades:
6. Verifiable Supply limits
7. Allowances
8. Escrow
9. Transferable only under rules specified by a smart contract.
Finally, the purpose of Bitcoin Cash is to scale to support billions of transactions per day. Any auxiliary use cases are surely welcome additions, but should not hinder that vision. Representative tokens can have an effect on UTXO set management, and the implications that has on future scalability should be carefully evaluated.
At this time, there is no solution which meets all aforementioned requirements, however some of them may be improved in the future. Omni and Counterparty are second layer solutions, and so fail requirement (2) and possibly others. OP_GROUP does not make allowance for transmuting coins without redemption as would be required to meet (3), (4), or (5) and it is unclear how script could be extended to support (6), (7), (8), and (9). Tokens based on multisig wallets require off-chain protocols and thus fail (2). Finally, current ideas for covenant opcodes do not allow for splitting and combining of token amounts.
 

$7.50
$27.20

Reviews
26 of 28 reviewers say it's worth paying for

2 of 28 reviewers say it's not worth paying for

Comments
  earned 25.0¢
Excellent article. I hope CoinGeek's 5M token project is inline with these requirements.
25.0¢
   3yr ago
25.0¢
  earned 0.0¢
Awesome article. Thank you for sharing. Tipped $20.00 to support high quality information about Bitcoin (Cash).
0.0¢
   3yr ago
  earned $2.00
I would argue that you are making a couple of non-technical mistakes in your post here.
First is the most important one, one size will not fit all. There will be usecases that will simply work better on one idea than on another. This is respected in most modern technologies like web but also Bitcoin. Fact is that we have multiple ways to "lock up coins" in Bitcoin. Some in a transaction, some in an opcode. Some even combine the two. None of them are "wrong", they just serve different usecases.
We have just passed the deadline for the proposals for the May hardfork. Criticism towards a proposal can have the effect that we will not get coloured coins for the upcoming fork. This would cost Bitcoin Cash an incalculable amount of market share as our competitors continue to innovate. Don't stall, that's what killed BTC.
We still need a full solution for BCH, nobody is arguing otherwise. Please recognise that OP_GROUP is "good enough" for a huge set of usecases. A lot of ICOs need nothing more than representative tokens. They suddenly become possible. We have a foot in the door. This should be included in ABC.
Please do work on that future option that can be deployed alongside various others. Then we let the market decide which they want to use. And it won't be just one.
Cheers!
$2.10
   3yr ago
25.0¢ 25.0¢ $1.00 25.0¢ 10.0¢ 25.0¢
  earned $1.65
Stalling the simple, yet powerful OP_GROUP will be a huge setback for Bitcoin (Cash).
The Bitcoin Unlimited members gave this proposal from Andrew Stone support with open debates and votes in december last year. (19 voted for, 0 voted against, 3 abstained.)
Please take your time and read Andrew's response to this article here: https://www.yours.org/content/response-to-op_group-criticism-d088a7f1e6ad
Let's not wait for a "perfect" Rube Goldberg machine like Core do with Lightning Network. Time is money.
$1.75
   3yr ago
25.0¢ 25.0¢ $1.00 25.0¢
  earned 25.0¢
Fully agree with Norway.
25.0¢
   3yr ago
25.0¢
  earned 0.0¢
Couldn't agree more with one of the commenters.
Stalling the simple, yet powerful OP_GROUP will be a huge setback for Bitcoin (Cash).
99% of use cases are met with OP_GROUP. The other are met with combination OP_GROUP and other methods described in article.
The article also implies that there is NO OTHER WAY devised (to date) to accomplish all those requirement.
And finally a quote from article in huge favor of OP_GROUP:
Andrew Stone has proposed OP_GROUP which makes a small change to the UTXO format and transaction validation rules.
If this gets postponed until November than BCH risk marginalized as new merchants will not be really get why BCH is better that BTC with current low fees situation.
It is obviously that better aggressively innovate than pray & hope for btc's fees to rise again.
0.0¢
   3yr ago