Colored Coins protocol proposal by Colu

June 24, 2015
New Implementation

The Colored Coins team at Colu has been working over the past few months on creating a proposal for a new Colored Coins implementation. Our intent at the beginning was to achieve consensus between all the existing players in the Colored Coins space (Coinprism – Open Assets, Coinspark and Chromaway) and create one unified protocol for issuing assets over the Bitcoin Blockchain. That has proved to be difficult and time consuming, so we decided to draft our own proposal.

The new proposal was created by our “Colored Coins” team (Rotem Lev, Tal Beja, Eliran Zach) that worked on it for the past 6 months and today we are publishing it together with it’s open-sourced code implementation.

These are the components included in this release:

  1. New Colored Coins protocol specifications
  2. Colored Coins Github project code
  3. Colored Coins issuance API based on the new protocol
  4. Colored Coins getting started guide
  5. Colored Coins asset Block Explorer

Read more on our Github Wiki

This implementation is based on attaching value to transactions using the OP_RETURN field on the Blockchain. The main objective is to create a coloring scheme that can compress more data into a very limited space, and for this purpose a new coloring scheme had to be built to support scalability issues and new functionality we wanted to implement.

This release also introduces for the first time a clear specification for handling the Metadata attached to a digital assets, and to a revolutionary way of storing the metadata in a decentralized manner using Torrent technology. By using torrents, every asset created with our protocol, is published publicly and stored on different computers that can be incentivized to host the information, while the Bitcoin Blockchain verifies the contents integrity.

Challenges

We had 3 major goals to achieve in this new implementation:

  1. Better Metadata handling
  2. Better performance & efficiency
  3. Better functionality

Better metadata handling
This protocol specifies for the first time, a clear method of creating and storing the metadata for colored coins transaction:

Use of Torrent files

Until now, smart assets that were built on the Bitcoin Blockchain, used other Blockchains to hold the metadata or stored it in a centralized DB. Colored Coins new Rule Engine will automatically store the metadata in torrents, where they can be freely accessed and verified.

There are important advantages to this approach:

  • Decentralization
    • Robustness: Even if our servers go down, the data is not lost
    • Ownership: No one owns the data
  • Provable immutability : A SHA-256 hash of the metadata is ( optionally ) stored on the blockchain . This allows our code to verify that the data received from the torrent file is indeed the correct data.
Metadata on every colored transaction

The new Colored Coins protocol implementation allows to add asset metadata on every transaction, not only during issuance, which is very useful when not all the relevant data is present at the moment of issuance.

For example, a movie theater has 500 seats.The theater can issue 500 digital assets for mission-impossible-10-premiere representing a ticket. During the purchase process on the theater’s website, the users select their seats. Each token of the movie’s tickets is sent to the user’s digital assets wallet (Colored Coins wallet) with the metadata of the selected seat already inside. Another example would be adding temporary data for stocks when there is some kind of an event, like restrictions, stock splits etc.

Coherent issuance policy

The new Colored Coins protocol implementation enforces a coherent issuance policy by supporting two types of Assets, locked and unlocked:

  • LOCKED ASSETS

Locked assets are assets who contains a fixed amount defined in the issuance moment. Even the asset issuer cannot issue more units of his own locked asset.

Example: non-dilutable shares

Fixed percentage of a company ownership can be represented with locked assets.
For example, a Venture Capital firm is interested in investing 2.5 million dollars in a startup, provided that it receives 25% control, even in face of future dilution of shares. The company can issue a locked  startup-x-to-the-moon  asset with an amount of 1M units and send 25% of the issued units to the VC firm upon receiving their investment.
The VC can now be completely confident any dilution of their shares is impossible.

  • UNLOCKED ASSETS

Issuers of unlocked assets can  keep issuing  more units of their asset.

Examples:

For example, let’s return to the company from our  previous example . The company can issue 750,000 units of a new  unlocked  asset, call it  startup-x-round-B. This time each unit is redeemable for its proportion in the total amount of the new asset out of the existing 750,000 locked  startup-x-to-the-moon . Initially each unit of the new asset is redeemable for exactly one unit of the old asset, but in case of a new round of funding the new asset can be diluted by issuing more units.

As another example, a coffee shop brand issues each month 1000 units of a free-cup-of-coffee asset, each redeemable for a free cup of coffee. Each month, a 1000 new units of the same asset are issued.

Better performance & efficiency

Processing many assets in one transaction

The new colored coins protocol implementation uses a novel encoding for asset transfer. This encoding allows us to process many assets together in a single transaction (in some cases up to 18 colors, or more).

Low prices & minimal bloat

The new colored coins protocol implementation achieves a high level of data compression using the way asset transfer instructions and transfer and issuance amounts are encoded. This leads to lowering the price in bitcoins needed to support each asset manipulating transaction as well as reducing Blockchain bloat.

Support for zero confirmation transactions

Bitcoin transaction are confirmed every 10 minutes (on average). Waiting for confirmations gives a poor user experience, especially considering current standards of responsiveness expected from web and mobile applications.

The architecture of the new colored coins protocol implementation allows us to support asset issuance and transfer in zero confirmations (and in fact even within the same transaction), because the Asset ID only references the first UTXO in the transaction and makes no reference to a block.

While it is true that each confirmation of a Bitcoin transaction increases our confidence in it, for many real world cases involving small amounts of money (a cup of coffee, a movie ticket, etc..) most users and merchants accept zero confirmation transactions. The fact that the new colored coins protocol implementations lends support to manipulating assets in zero confirmation is a big boon for user experience.

As with standard Bitcoin transactions, certain users may decide to consider an asset as valid for their business purpose only if it has at least some number of confirmations. The colored coins software itself does not enforce that restriction.

Support for thin wallets

In order to allow colored coins wallets to run on mobile devices, the protocol must be able to verify colored transactions without the need to run a full Bitcoin node.

Thin Bitcoin wallets, a.k.a SPV clients are nodes in the Bitcoin network that do not keep all the Blockchain data but instead keep only the block headers and verify that those connect correctly and that the difficulty is high enough so that the chain can be reasonably trusted. Full data (and Merkle branch linking to blocks) are only requested for transactions relevant to the addresses in the wallet, thus using the Merkle tree structure to prove inclusion in a block without needing the full contents of the block. In particular, the thin client does notverify transaction validity but instead deduces that validity from the inclusion in valid blocks of the longest chain.

This general type of SPV clients cannot, in principle, support the colored coins protocol. The reason is that Bitcoin miners are color blind and thus treat color transactions as standard Bitcoin transactions and ignore the entire asset meta structure that can only be parsed and understood by nodes running the colored coins software.

In particular, miners do not verify the colored aspects of transactions. Therefore, any colored coins client must verify colored transactions on its own, and to that effect must keep extra relevant data about the history of transactions.

Thus, SPV support for colored coins is subtle and the differences between color aware SPV clients depend on how much extra data must be kept, and how it is handled by the client in order to process and verify colored transactions.

There are a few possibilities:

  • The worst case scenario is keeping the full history of all the transaction supported by the colored coin protocol
  • Next is the option of keeping all data about the blocks that are relevant to all the assets that you happen to own in your wallet
  • The least expensive option, and the one used by the new colored coin implementation is that of keeping only all data about blocks relevant to colored transactions that your wallet takes part in. The thin client will then backtrack through blocks all the way to asset issuance and keep only that data.
Better functionality issuance policy

The new colored coins protocol implementation includes a Rule Engine that operates on rules specified in the metadata of an asset. Rules may be Open or Locked, when Open any one issuing or transferring the asset may add to the rule-set, when Locked the rule becomes immutable.

We would like to thank the Colored Coins community on its support over the last months and invite everybody to test our code. we welcome any comments on our proposal.

FacebookTwitterGoogle+Share