Daily Archives: 2017-02-05

Idea: Colored Coins on Monero

Published by:

While the main goal of Monero is obviously to be a fungible cryptocurrency, lots of cool things can be done with the technology. Recently I saw an article about “Confidential Assets” by a start-up called “Chain”.

The Confidential Assets that Chain is proposing are basically a form of issued tokens that can be transferred anonymously between parties on the same network. The issuance can be anonymous and the balances of the accounts are unknown to an observer. There is a downside however: the history of the assets/tokens can be tracked. This scheme can for example be used for creating virtual poker chips,  company shares or even cryptofiat backed by a reputable bank who holds the currency on balance.

While this is a cool idea, I don’t think it needs its own blockchain or other form of “decentralized” database with some weak consensus mechanism. If you want fungible assets however, then a different approach is certainly needed. Monero lends itself perfectly for this job because all transactions are untraceable, unlinkable and with RingCT the amount isn’t visible. In this small article I propose a system for building Colored Coins on the Monero network. These Colored Coins are fungible, the transactions use RingCT, the issuer can be anonymous and an observer who isn’t part of the CC-network doesn’t necessarily need to know the amount of Colored Coins in circulation.
Seems like a cool idea? :)

How does the Colored Coins on Monero looks like in general?

1) Monero is divisible into 1 trillion (10^12) atomic units (“etoj”). To create a specific Colored Coin, the Issuer needs to first define the amount of Coins he wants to issue. He also needs to take into account how much decimals the token can have. If a bank for example wants to issue 1 million USD on the blockchain with 2 decimals, then there are 100 million atomic units. To issue this particular Colored Coin, the Issuer will need 0.000100000000 XMR. Every eto will represent 0.01 USD.

2) Now that the Issuer defined the amount of atomic units, he can do the “Issuance Transaction”. The Issuer simply sends a transaction with the required output to an address he controls. There is no need for a paymentID. No special measures need to be taken. This transaction just looks like any other transaction on the blockchain.

3) The Issuer then needs to perform the Enabling Transaction: this is the first transaction which uses the full supply. Let x be the minimum Ring Size, then this Enabling Transaction needs to have at least x outputs.

4) From this point onwards, transactions which use this specific Colored Coin are required to only use txo’s that stem from the Issuance transaction in the ring sigantures. If any other txo’s are used in the ring signature, then all the outputs will lose their Color. These txo’s won’t be recognised anymore by the Colored Coin network.

5) There is one problem however with this scheme: monero transactions aren’t free. But to be able to pay for the fee, additional inputs in the transaction are needed and it will need to be possible to verify that all the additional real XMR is spent as a fee payment. This would require tweaks in the RingCT protocol, disclosing a lot of info about the transaction to the public, etc.
A more private solution is the following: when you spent a colored txo, you’ll usually have at least 3 outputs: the payment, the change and a 0-output. This 0-output will then be spent again in another transaction using a ‘Child Pays for Parent’ scheme. The result will be that this 0-output will lose its Color, but who cares? It was a 0-output anyway.
Note: currently CPFP is not yet possible on Monero. Maybe another solution for the fee problem is possible. But I suggest that this system would reveal as little data about the Colored Coin transaction as possible.

The result of this scheme is that someone is able to issue Colored Coins on the XMR blockchain. The transactions will use RingCT. The issuer can chose to disclose the amount of coins created, or not. The Colored Coins will be fungible. Downside: it will be pretty easy to spot colored coin transactions on the blockchain, even if an observer isn’t aware of the Issuance public key and/or or the Enabling transactionID. If regular Monero users use real XMR in a ring sig in combination with txo’s that are inside the Colored Coin system, an observer will be able to discard those Colored txo’s as real inputs of the transaction.

Assuming CPFP will be implemented, a practical implementation of this scheme seems pretty easy: what is needed?

A) a special wallet that is “Color Aware”. The user needs to be able plug the public key of the Issuance transaction (the key that contained the whole supply) and the txid of the Enabling Transaction into the wallet. By doing this, the wallet recognises that a certain transaction contains all issued tokens and that a specific transaction enabled the network. Note that the txid is needed, because nothing stops normal users of the Monero network to use the public key of the Issuance Transaction in a regular ring signature.

B) Optionally, the user can add more sets of public keys and txid’s later on. If the Issuer decides to create more tokens (for example new shares) then the user can decide to accept this new issuance.

C) The Color Aware wallet needs to be able to recognise incoming Colored transactions and check their validity.

D) The Color Aware wallet needs to be able to pick the txo’s from the approved list when creating Colored Coin transactions.

E) The Color Aware wallet needs to add a 0-output to every transaction and pay 0 fee when sending a Colored transacion

F) The Color Aware wallet needs to spend the 0-output with a “double fee” using CPFP to confirm the Colored transaction.

G) Optionally, a public database can be created that has the info of certain Colored Coins with the data needed to add it to the Color Aware wallet. The Issuer can decide to publish it or not. Optionally, he can also disclose the amount of tokens issued by disclosing the TX private key of the Issuance transaction and the originating address of the Enabling transaction.

ShapeShiftOpenAlias