Andrew Stone has an interesting proposal out to add native colored coins to Bitcoin Cash. Years ago similar proposals were made for Bitcoin but were roundly rejected by the Core developers because the functionality falls outside of the core Bitcoin value proposition. But given that we're starting fresh with Bitcoin Cash, it allows us to reevaluate these things. Maybe we want to consider extending the functionality in ways that make the chain more useful? I'll give one example of something that could have been built using such a protocol. Before Token Mania we saw a number of small Bitcoin related companies raising funds through illegal IPOs. Basically selling shares of stock in the company that would be traded illegally (maybe I should write "illegal" like this because I don't believe such things should be illegal as it helps open up access to capital for everyone not just the super rich). Satoshi Dice was one such example of these companies. At the time the primary exchange for these illegal securities was BTCT.co (Bitcoin Trading Corp). But this was basically a centralized exchange and the operators eventually got cold feet and shut it down (and I believe they were fined by the SEC). In the wake of that closure I REALLY wanted to build a decentralized asset exchange that could carry on the illegal trading. Colored coins would have been perfect. Sure there were colored coin protocols out there using OP_RETURN but then all clients would need to run full node, reducing the number of participants and reducing the liquidity of the exchange. So I waited to see if anything else would come along that would be an improvement over those protocols and nothing ever did. What Andrew has proposed is an SPV compatible protocol that would work fairly well for that purpose as well as a number of other use cases. So what follows is I'm just going to try to provide a plain English explanation of his proposal.
The Protocol A standard Pay-To-Pubkey-Hash address looks like this: OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG For colored outputs we just prepend a new OP_GROUP opcode as well as a group identifier. The identifier is a 160-bit hash as we will see, but for the sake of this example I'm just going to use the word blue to represent the hash. <blue> OP_GROUP OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG The only addition to the Bitcoin Cash protocol would be a requirement that when a transaction contains a colored input, that an equal value colored output must also be included (and vise versa). The only two exceptions to this rule would be the Mint and Burn (uncolor) transactions. MINT Transactions The following is an example MINT transaction in JSON showing hypothetical inputs and outputs. { "inputs": [ { "outpoint": XXXXXXXXXX, "value": 1000000, "linkedScript": OP_DUP OP_HASH160 <blue> OP_EQUALVERIFY OP_CHECKSIG } ], "outputs": [ { "value": 1000000, "script": <blue> OP_GROUP OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG } ] } You'll notice above that while the output script contains an OP_GROUP opcode the input does not. Normally this would cause transaction validation to fail. However, since the data element in the linked input script is the same hash as the group identifier, this is treated as a valid MINT transaction. Basically only the person who controls the private key to the "blue" address can mint new blue coins. Also this transaction does not pay a fee. If the sender wished to include a fee, he would need to attach another uncolored input and an uncolored change output. The same will be the case for all colored coin transactions. SPEND Transactions { "inputs": [ { "outpoint": XXXXXXXXXX, "value": 1000000, "linkedScript": <blue> OP_GROUP OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG } ], "outputs": [ { "value": 1000000, "script": <blue> OP_GROUP OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG } ] } SPEND transactions follow the normal rule of colored input and output values matching. There can be more than one type of colored input and output in the transaction so long as they match. This would allow atomic swaps to be done in a single transaction. BURN Transactions The BURN transaction uncolors the coins and turns them back into normal Bitcoin Cash coins. The rule here is if any output does not include the OP_GROUP identifier but does pay to that group's identifier, then the transaction is considered valid. Presumably something like the following would uncolor the blue coins and send the normal Bitcoin Cash to an address of your choice. { "inputs": [ { "outpoint": XXXXXXXXXX, "value": 1000000, "linkedScript": <blue> OP_GROUP OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG } ], "outputs": [ { "value": 1000000, "script": OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG }, { "value": 0, "script": OP_RETURN <blue> } ] } Fixed Supply Coins The above protocol proposed by Andrew allows the issuer of the coin to continue issuing more coins after the first MINT transaction. This is probably what you want for most cases (like a gold backed coin, or a stock token). But there might be some other cases where you just want a fixed supply (maybe you've got some specific use case for a token in your app when you want/need the supply to be fixed). Is there a way we could prevent further issuance? A solution I came up with could be to use a P2SH address instead of P2PKH for the group address. The redeem script could look something like this: OP_CHAINHEIGHT <505500> OP_LESSTHAN OP_VERIFY <pubkey> OP_CHECKSIG This says, "This output can only be spent before block 505500". This would mean the issuer could mint new coins up to block 505499 but no more after that. OP_CHAINHEIGHT does not exist today and I think would need to be a hardfork to include, but if we're doing a hardfork to include script enhancements it might be worth considering adding that opcode as well. Conclusion This is a pretty interesting proposal. I know some people will say "why not just use ethereum?". Sure, that works. But if you're already building an app which uses Bitcoin Cash for payments it would be a royal pain to also have to bundle an Ethereum node with your app just to get access to a token. This protocol gives you a fairly lightweight way of using a token in your app and does so with fairly negligible overhead on the Bitcoin Cash network. Is it worth doing? I think it might be. How about you?
 

$7.80
$11.55

Reviews
3 of 3 reviewers say it's worth paying for

0 of 3 reviewers say it's not worth paying for
Comments
  earned 54.8¢
Sounds like a good idea to me. Would be great to see native colored coins and/or tokens in Bitcoin Cash. As you say, this would be extremely useful for any apps that are already built on Bitcoin Cash, e.g. Yours, as bundling an Ethereum wallet just for tokens would be far more complicated.
I would love to see an analysis that compares this proposal with the other (non-native) implementations of colored coins that already exist. There are several such implementations that all vary in details. None of those are native, though, and therefore don't work with SPV, so that is a huge advantage of this approach.
50.0¢
   12mo ago
2.0¢ 25.7¢ 25.0¢ 10.0¢ 10.0¢ 10.0¢ 9.9¢ 10.0¢ 10.0¢
  spent 20.0¢

0.0¢
   12mo ago
2.0¢
  earned 3.3¢
I like this idea a lot.
0.0¢
   12mo ago
2.0¢ 10.0¢ 9.9¢ 10.0¢
  spent 10.0¢
Mycelium wallet used colored coins to distributed tokens to Colu who seem to maintain a switchboard service but are a non entity. Lets ask them some questions on this topic before doing anything.

0.0¢
   12mo ago
2.0¢ 10.0¢
  earned 40.0¢
Anna <cs@colu.com> Reply|Mon 23/10, 13:51YouYou replied on 23/10/2017 14:36.Hi Matthew,  Unfortunately, this product is no longer supported & there is nothing I can do to help you with it. You can visit coloredcoins.org to find more info about other opensource products.  Best, Anna
On Sun, 22 Oct at 11:18 AM , Matthewshaw1 wrote:Can I log in? Get Outlook for Android From: Anna <cs@colu.com> Sent: Sunday, October 22, 2017 8:30:47 AM To: matthew Subject: Re: Colu App support (not developers) Hi Matthew, For any issues regarding Mycelium tokens, please contact them directly. Colu doesn't provide any support in regards to Mycelium activity, and we have no association with Mycelium. Best Regards, AnnaOn Thu, 19 Oct at 8:48 PM , wrote:Topic: Colu App support (not developers) Name: Matthew Email: matthew Message: Hi, I purchased mycelium tokens and would like to access my wallet where they were deposited please. the password reset for my email matthewshaw1@hotmail.co.uk dosen't work Oops! This is awkward. You don't have permission to access this page. Contact your community manager to learn more. CONTACT thank you📷
50.0¢
   12mo ago
2.0¢ 50.0¢
  earned 0.0¢
There are another very important feature needed in colored coin ecosystem:
Lock up: Token economy usually involves a certain kind of incentive scheme that want to encourage token holders to behave according to the long term goodness of the system. Lock the token up from a few months up to a few years usually is required.


0.0¢
   9mo ago
  spent 2.0¢
@transcitizen Lock up can be done through P2SH outputs that include OP_CLTV. Definitely if colored coin wallets are implemented, they should include support for this kind of lock up address.
0.0¢
   9mo ago
  spent 2.0¢
I'm all for it. I was critical of OP_GROUP but after looking at it in more detail I'm more and more convinced that this is the right way to do it.
0.0¢
   8mo ago