Colored coins

From Open Transactions
Jump to navigation Jump to search

Definitions

The term “colored coins” can mean two different things:

  • A technique for carefully constructing blockchain transactions in a way that preserves information apart from the base monetary value of the underlying units
  • The extra information preserved in the blockchain by employing the colored coin technique

For the sake of clarity we will differentiate the technique from the information by using the term “virtual tokens” to refer to the extra information that is preserved using the colored coins technique.

Virtual Tokens

Virtual tokens possess all the capabilities of currency, plus one additional capability (smart property) which is helpful for non-currency usage.

Capabilities

Users of virtual tokens can:

  • Transfer them between individuals
  • Combine multiple tokens into a single token with a greater value
  • Divide the value of a single token into multiple tokens
  • Use them in blockchain-scripted contracts
  • Store them on the blockchain with multisig scripts
  • Unambiguously prove that any particular virtual token is a valid member of a set created by the issuer, without requiring the issuer to *create and manage a token registry.

Limitations

There are certain tasks which virtual tokens inherently cannot perform unaided:

Enforcement
Virtual tokens represent ownership information, but they can’t enforce real-world obligations. For example, a particular issuance of virtual tokens might represent tickets for entry to a concert. The virtual token can prove the bearer should be allowed to enter the concert, but it can’t force the bouncer to step aside and let him pass. Colored coin techniques can’t prevent the user from manipulating the underlying bitcoins in a way that destroys the extra information, because operations on virtual tokens are governed by Bitcoin transaction rules, and colored coin requirements are more strict but not enforced by the network. Using virtual tokens in a transaction that does not obey the colored coin rules destroys their extra meaning, leaving behind only their base monetary value. This is equivalent to taking one’s paper concert ticket and setting it on fire.
Metadata
The quantity and ownership of virtual tokens can be stored in the blockchain, but the semantic information that indicates what a token means is not (and cannot be) similarly stored. For example, the blockchain will track how many concert tickets have been issued and which address owns them, but not the fact that they represent authorised entry into a particular concert at a specific time and place. The storage of and operations on metadata require a specific kind of external system, such as Open-Transactions.
Blockchain Limitations
The speed of colored coin transactions, and the capabilities of scripted contracts that use virtual tokens are the same as those of the underlying blockchain.

Coloring techniques

There are two techniques that may be used to create virtual tokens: transaction-based coloring and address-based coloring.

Transaction-based coloring

Transaction-based coloring was pioneered by ChromaWallet and works by identifying a specific Bitcoin transaction at a particular time as the “genesis transaction” and tracking all units which descend from the genesis transaction. Transaction-based coloring can produce the full range of virtual token types, and has the security property that even a loss of the original private keys to the genesis address cannot result in the issuing of counterfeit virtual tokens. This security property means the number of virtual tokens matching a color definition is fixed at the time of creation and cannot be altered in the future—which can be an advantage or a disadvantage, depending on the application.

Address-based coloring

Address-based coloring was created by Coinprism and tracks bitcoins which are descended from any transaction that passes through a defined address. This means the issuer can easily create new units in the future, but so could a thief who manages to steal the private key for that address.

Virtual Tokens

The different use cases for virtual tokens can be divided into three general categories, which form the different types of virtual tokens.

Tickets

Tickets are transferable bearer tokens which are designed to be eventually redeemed for some kind of real world value.

Examples of tickets include:

  • Event entry passes
  • Store coupons and special offers
  • Frequent flyer miles and other redeemable rewards

Both address-based and transaction-based coloring can be used to create tickets.

Certificates

Certificates are transferable and redeemable in the same manner as tickets, and they additionally entitle the bearer to some kind of revenue paid through the blockchain.

Certificates can be used for bearer securities, such as securitized loans, mortgages, bonds, and dividend-paying stocks.

Both address-based and transaction-based coloring can be used to create certificates.

Smart Property

Smart properties are transferable like tickets and certificates, and in addition, every particular smart property is both unique and atomic. Only one smart property of a given identifier can be created, and once created it may not be subdivided.

Smart properties can be used to indicate ownership of an unique real-world asset, and can also be used for objective naming of content-addressed mutable data. This naming function is related to, and an extension of, hash-based naming.

A common operation in software engineering is to use cryptographic hash functions to create short identifiers for large pieces of data. This is useful because hash values are easy to communicate since they are short, and also are easy to check since they are deterministic. This means if you know the name of some piece of data, you can independently verify that you have the correct copy of it. But the limitation of hash-based naming is that the named data can never change.

Smart property overcomes this limitation. Because of a Bitcoin feature (OP_RETURN) that allows arbitrary data to be attached to transactions, every time smart property is moved it can be associated with a new hash. This means if data is identified by a smart property identifier instead of using the hash, the identifier of the smart property can objectively and unambiguously identify the most current version of the data.

Transaction-based Coloring

Transaction based coloring defines a set of tokens using a genesis outpoint, and a color kernel.

Genesis outpoint

The genesis outpoint is a named outpoint (transaction hash, output index) in the blockchain. It functions as the head of the tree where the outpoints created by transaction which consumes it, and all descendants of those outpoints, potentially inherit a portion of the genesis transaction's color balance.

Color balance

The color balance of an outpoint is a quantity which represents some blockchain-external unit. The color balance is encoded into the satoshi balance of an outpoint, but they are not equal.

It's normally not practical to encode a 1:1 relationship between the color balance and the satoshi value of an output, because blockchain anti-spam rules makes the creation of very small value outputs impractical.

To account for this, most coloring techniques use a padding system where an extra satoshi amount is added to each output to fulfill minimum output size rules.

The color balance of an outpoint can then be calculated by subtracting the padding from the satoshi amount.

Color Kernel

A color kernel is a set of rules which are applied to a transaction to calculate the color balance of the outputs.

The rules which make up a color kernel may consider any or all of:

  • The color balance of all inputs
  • The relative position of outputs relative to inputs
  • The relative size of outputs
  • The details of the script associated with outputs
  • Information encoded in the transaction header fields, such as nSequence.

After applying a color kernel to a transaction with colored inputs, the color balance of each output is known. Starting from the genesis outpoint, the color kernel can be recursively applied to all descendant transactions in the blockchain until the present position of all colored units can be located.

Because kernel rules are not enforced by the underlying network, it's possible to create colored coin transactions improperly such that the resulting outpoints do not contain a color balance. This is known as "destroying" colored coins.

Color kernels are typically identified with a 3-5 character code.

Common Color kernels

EPOBC (enhanced, padded, order-based coloring)
This kernel was created by Chromawallet and is suitable for creating ticket virtual tokens. As implemented in Chromawallet, it does have a limited ability implement certificate virtual tokens.
SPOBC (smart property order-based coloring)
This kernel was created by Monetas and is a derivation of EPOBC optimized for creating smart property virtual tokens. Unlike EPOBC, SPOBC tokens have a fixed color balance of one and may not be subdivided.
Instead of a color balance, an SPOBC token has a value. This value is set by including up to 40 bytes of data in an OP_RETURN output in the transaction containing the token. To change the value of a SPOBC token, it must be included as an input to a new transaction so that the new value may be set.
DHKEC (diffie-hellman key exchange coloring)
This kernel was created by Monetas and is a derivation of EPOBC optimized for creating certificate virtual tokens. The DHKEC kernel imposes a restriction on allowed script types to those which expose an ECDSA public key in the blockchain. This allows for payments to be sent to addresses derived via ECDH, which helps maintain the non-colored payment segregated from the colored tokens.

Color descriptors

Color descriptors provide a URI-like method for identifying issued virtual tokens. The form of a color descriptor is:

kernel name : colon-seperated parameter list

All currently-defined kernels use the same list of parameters:

genesis outpoint txid : genesis outpoint index : genesis outpoint block height