Topic: the theory of colored coins - page 2. (Read 4317 times)

I like this approach. Maybe it will help to relate how colored coins generalize existing concepts in Bitcoin.

Transaction validation is analogous to the colored kernel. Transaction validation is a function of the blockchain history, however it's not an arbitrary function - instead it's only necessary to check the UTXO index, which is much smaller than the blockchain and only contains unspent/active coins. Similarly, the color kernel can be said to depend only on a "color table", which associates a color state to unspent coins.

Dude you have superb knowledge thanks for post this article here.Thumbs up for you.

For what it's worth, I think this article is very clear as-is.  I think it could be improved by including answers/commentary on the following topics:

1) Include a worked example.  This would be particularly useful as it would help show why it is necessary to distinguish between "color" and "color state"

2) Discuss how you anticipate the kernels working in practice.  In the most decentralised example, one can imagine that a particular kernel might only exist in the client of an issuer of a particular color (associated with that kernel) and in the client of any recipients of coins with that color... or at least those recipients who were expecting to receive such a color.   Distribution of the kernels in such a case would make for an interesting discussion. It would also be interesting to highlight that the beauty of this system is that most Bitcoin users could be completely unaware that some coins were colored - only those with a need to know would know.

3) Discuss the economics/incentives surrounding coloring.  Absent a centralised "registry" of colors, most people, most of the time, will not know that a particular output is colored.  Should they be the recipient of a transaction that uses one of these outputs as its input, they may not even realise that they are holding something of value well in excess of its nominal BTC value.   If there was some sort of "registry" of colors, their client could alert them to this... but, in general,   a recipient wouldn't know.    Now this is probably not a problem in reality since why would somebody *send* something of value unless they received something of comparable value in exchange?   But it might be interesting to explore the extent to which a generic client could alert a user that an output was colored, even if the associated kernel was not available.

.

(This is based on an article which I posted on colored coins mailing list back in June. Since colored coins are mentioned here fairly frequently, it would help if settle on a concrete terminology, and so I'm posting it here.)

EDIT: A more rigorous definition which uses slightly different terminology: https://github.com/bitcoinx/colored-coin-tools/wiki/colored_coins_intro

Previously we were associating term "colored coins" with a concrete protocol/algorithm, called "order-based coloring". Sadly, it had certain deficiencies, especially after anti-dust patch made it impossible to send tiny amounts of coins, and for this reason we decided against standardizing on it.

Instead, I decided to generalize the concept; so "colored coins" is a concept now, not a particular technology. So what is it, exactly?

The core idea is this:

• we are going to associate a property or a set of properties with transaction outputs
• this property can be transferred when these transaction outputs are spent in a transaction, i.e. outputs of this transaction can somehow inherit properties of inputs

So the characteristic trait of 'colored coins' concept is that it uses Bitcoin transaction graph and works on 'transaction output' level.

Let's formalize this:

• color associates color states with transaction outputs, e.g. color X associates color state Y with transaction output Z. Perhaps we can write it down as X(Z)=Y
• color can't be an arbitrary function, it must be defined in terms of coloring kernel, which is a function which can be applied to each transaction in isolation
• coloring kernel is a function which gets a particular transaction and color states of all of its inputs as parameters, and yields color state for each transaction output. Basically, coloring kernel "colors" outputs
• we can apply coloring kernel to each transaction in a blockchain, and if it is deterministic, a certain color state will be deterministically associated with each transaction output in the blockchain
• this also applies to transactions in mempool: if transaction isn't orphan, color states of its outputs can be computed, and they won't change in future

"Order-based coloring" is a kind of a coloring kernel: you get specific coloring kernel when you combine genesis of a color with an order-based coloring algorithm. (In other words, a generic coloring function which performs order based coloring is parametrized by genesis transaction output; and when color's genesis transaction output is provided you get the concrete coloring function for this particular color.)

You can find an implementation of this coloring kernel here (Python): https://github.com/bitcoinx/coloredcoinlib/blob/master/colordef.py#L24

Smart Property protocol which was described by Mike Hearn here: https://en.bitcoin.it/wiki/Smart_Property#Theory
fits into this new colored coin model. And so do many other things which are based on it, e.g. bonds which are marked with a special transaction scripts (see here: https://en.bitcoin.it/wiki/Distributed_markets).

However, Mastercoin doesn't fit into colored coins model, for two reasons:

• it associates balances with addresses, not with transaction outputs
• it uses non-local state transitions. It is sensitive to order, i.e. even if you have exactly same transactions, but they are in a different order, you can get a very different state.

Mastercoin can only be described in terms of a more general model, and it can implement features which cannot be implemented within colored coin model. But since it doesn't make use of Bitcoin transaction graph, it is no longer protected with mechanism which prevent double-spends. I.e. we cannot say anything conclusive about Mastercoin transactions which are still in memory pool, state is fixed only if is buried in the blockchain.

OK, well, so why do we care about a formal model for colored coins?

As it turns out, coloring kernel can be separate from other aspects of colored coin implementation (such as blockchain traversal, for example). Thus we can create a colored coin client which is able to work with several different kinds of kernels, and so compatibility problems are less pressing: to add support for a different kind of colored coins we simply need to include implementation of kernel and implementation of send function.

We can also develop coloring kernels for specific purposes: we are no longer limited to a simple rule of conservation. We can implement advanced kernels which can have interesting features like demurrage, taxation, built-in referral program etc. It is also possible to design them specifically for use in derivative and prediction markets.

(In other news, I believe it is possible to create a fully decentralized prediction market. It is fairly hairy and relies on assumptions of economic nature, e.g. rationality of actors. But as far as I can tell, it is actually viable. Consequences will never be the same.)