Colors

Parametrized color kernels

Of course, it would be useful to introduce some scheme which would allow anyone to create as many colors as he needs. To do this, we will define parametrized color kernels: concrete color kernel for a concrete color will be obtained when one provides all necessary parameters.

Typically, a genesis transaction output serves as a parameter: that is, colored coins will be "injected" into a blockchain via a particular transaction output, and from that point they can be further transferred and distributed. Usually we call this act 'issuance', and a party which performs it is an issuer. (It is similar to issuance of securities.)

Order-based coloring

One example of a parametrized color kernel is order-based coloring. To find colorvalue of an output, we first need to identify a set of inputs which match it. To do this, we represent each input and output as a segment on a line.

Input i is represented by a segment [a(i), b(i)] which starts where previous input's segment ends: a(i) = b(i-1) and its length equals its value: b(i) - a(i) = value(i). For the first input, a(0) = 0, i.e. it starts at origin.

In a same way, output j is represented by a segment [c(j), d(j)], which starts where previous output's segment ends.

Now we can defined that input i matches output j if their segments overlap.

If all inputs which match output j have non-null colorvalues, then output j has colorvalue which equals its value in satoshi. Otherwise, it has null colorvalue.

Order-based coloring is simple and straightforward, but it has certain disadvantages. First, we need transaction outputs with small amounts of satoshis in them to represent small colorvalues, but such outputs are currently discouraged by Bitcoin nodes as they can be used to create large amounts of unspent transaction outputs ("dust") which can strain nodes' resources.

Second problem is that it isn't possible to identify outputs which potentially have non-null colorvalues by considering a transaction in isolation, and for this reason thin clients which use backward scan to find colorvalues have to do this scan for uncolored outputs (ones having null colorstate), which can be very computationally expensive.

EPOBC

Color descriptors

Color descriptor is a string which identifies a color and is enough to completely describe its kernel. Usually color descriptor mentions which parameterized color kernel is being used and parameters necessary for this kernel.

We use format similar to URI:

<parameterized color kernel identifier>:<list of parameters specific to that kernel>

For example:

obc:b3b2c25ea6366d8506ea338f8e93624af897f284a511864eafe472d283819b41:0:147478

is a color descriptor which consists of following components:

• obc: identifies parameterized color kernel, 'order-based coloring'
• b3b2c25ea6366d8506ea338f8e93624af897f284a511864eafe472d283819b41: hash of the genesis transaction
• 0: output index in genesis transaction
• 147478: block height at which genesis transaction appears (TODO)