Topic: the theory of colored coins (Read 4273 times)

Here's an example of color_desc: "obc:b3b2c25ea6366d8506ea338f8e93624af897f284a511864eafe472d283819b41:0:147478"

It identifies a particular color, like URL identifies a page on a web site.


I do what I can... Why won't you help instead of complaining?

FYI that "Colored coins - BitcoinX" whitepaper is dead.

Hash of color descriptor?!  Where is the color descriptor?  Is it on the block chain or on some external file somewhere.

C'mon guys!!!  You have to step up your execution!

Here's an example of how it looks like now: Dusis5Fcme7fDa@moi5hNSCMRFpAgALXGGmVwqqeremPHvgfL

Dusis5Fcme7fDa is  a hash of color descriptor, moi5hNSCMRFpAgALXGGmVwqqeremPHvgfL is a normal testnet address.

We'll probably use a different format later, but the idea will be the same.

The coin id, is that a 5 letter symbol in ASCII?

No, this is entirely an user-interface feature: user interface doesn't allow one to send to a "wrong" address.

But on the script level it is same as normal Bitcoin transactions.

So are you saying that this new address form is placed inside the script?

Mastercoin and colored coins work in very different ways.

There are several different approaches here... The basic idea is that two parties enter a contract by signing a transaction of special form (with contract details encoded in OP_RETURN data, for example) together.

They can close it in two ways:

1. both of them agree on settlement payout
2. one of parties forces the settlement, referencing evidence of some sort in the transaction

In the later case, others can check if settlement is right.

There is also a more centralized variant: only some kind of authority can make a transaction with forced settlement.


No, it's just a different format of addresses. Like @.

Quote from: FrictionlessCoin on December 27, 2013, 10:46:49 AM

I did not see this in the specification.

The specification is incomplete.

If you mean the one written by Vitalik Buterin, it is pretty much completely unrelated to how it is actually implemented.

 Why Not Color Coins? problems, limitations, and criticisms of the Bitcoin Color Coins architecture.

 http://altchain.org/?q=content/why-not-color-coins-problems-limitations-and-criticisms-bitcoin-color-coins-architecture

 -bm

Could you expound a bit on how you would do derivatives?   I had some intuition that you could, but I have not worked out the details how you would be able to do this.


Are you saying that there you are embedding in the address creation mechanism a way to uniquely create a colored address?  I did not see this in the specification.

Yes.


We haven't settled on the best one, so we need to consider several alternatives.

However, the point of this theoretic model is that multiple mechanisms can co-exist.

For the start we are most interested in one which simply follows the rule of conservation, as it has many uses. But there are other interesting applications, which will require custom color kernels. (One example is prediction/derivatives market.)


It's always the case... But, in practice, special 'color addresses' prevent potential incompatibility problems: each color has an identifier, hash of that identifier is embedded into the address in such a way that client can check if identifier matches. This means that if your client doesn't support color "green", you won't be able to produce an address for color "green", and thus nobody will send you "green" coins.

Took a shower and realized the answer to my question.

The miners merely validate if the input transactions are more than the output transactions.

When the client sees the transaction that it targeted to its address, it can do what ever it needs to do to process that transaction. 

So the actual semantics of processing the transaction is decentralized.

Did I get that correct?

Further,  why does the whitepaper alternative coloring mechanisms?  Is there a preferred one?   Are we at this time saying that coloring will be preserved only if we use a compatible client?

Well, the point of executing color kernel is to find colorvalues... So each actor which is interested in finding colorvalues need to execute it, unless it can get colorvalues from trusted source. (E.g. via a cryptographic proof of some sort.)


No, I see colored coins as an alternative to protocol changes. Having something on protocol level definitely has benefits, e.g. SPV (thin clients need very little information to verify payment), but it might be problematic:

1. hard fork is required (likely)
2. a problem in additional features might lead to consensus problems
3. changes are not compartmentalized
4. it's hard to add features, upgrade over time, etc. (again, hard fork is required)

But that's the theory... In practice, if you care about things like user currencies, securities and so on, they aren't that hard to implement, so a Bitcoin protocol upgrade (such as Freimarkets) is desirable.


Yes... It is known as 'hard fork'.


Yes... Basically, when you see an incoming UTXO, you want to know its colorvalue, so you run the computation... But there are several different computation strategies, like pre-computing everything, or computing on demand only.

What I don't understand is,  which actor executes the color kernel?   Do you envision the miners executing the color kernel?   Would that need an upgrade of the entire bitcoin network?

Will wallets with the recepient address execute the color kernel?

Doesn't proof of bits also have an implementation?

What are the problems with WebcoinX?  Is it due to not using bitcoind?

There are several incomplete implementations. Currently our flagship implementation, NGCCC, is probably too heavyweight for this kind of stuff.

On the other hand, a web client called WebcoinX might be OK. As it is web based, it is relatively easy to tweak user interface for a particular cause.

However, while it works on testnet, there are many problems which prevent it from working properly on mainnet.

Unfortunately fixing all this crap is fairly hard, and we decided to prioritize development of NGCCC. But if we'll be able to return to WebcoinX, it would take about a month to make a usable version.

Meanwhile, you can try a testnet version of WebcoinX: http://bitcoinx.github.io/webcoinx/

Or this short python script if you want command-line: https://bitcointalksearch.org/topic/blockchain-security-trackingcolored-coinssmart-contracts-short-python-script-117630

It lacks 'decentralized exchange' aspect, but if you just want to send coins around, it might work.

I've written a post about an application I'm thinking about (establishing ownership of digital artworks)
https://bitcointalksearch.org/topic/using-the-blockchain-as-a-method-for-assigning-ownership-of-digital-artworks-317090

reading more about colored coins suggests to me that it is the right tool for the job.
My question is how far along is this project? Does useable software exist?
How do I learn how to use the system?

I've improved(?) this a bit: https://github.com/bitcoinx/colored-coin-tools/wiki/colored_coins_intro

That's a very interesting point.  As you say, one could model transaction validation as an example of a color kernel. However, it has the unusual (unique?) property that 1) this kernel is implemented by bitcoind and enforced by miners and 2) its execution depends only on information that can be derived from the blockchain.

In the general case of colored coins, some form of bootstrapping is required: somebody must assert that a particular coin (or, rather, output), that was not previously associated with a particular color, is now so associated. Moreover, this "somebody" must be identifiable: the value of any coloring is critically dependent on the extent to which others believe they will make good on any promises associated with the claim.  Moreover, in a decentralised world, the kernels would not, in general, be known to all participants in the network: so, by definition, they could not operate *on* the blockchain (e.g. by providing a verification role).

Perhaps this distinction doesn't matter but it could help work through various scenarios... i.e. distinctions between kernels that require bootstrapping/external information and those that don't, distinctions between kernels that depend/provide blockchain verification function and those that don't, etc, etc.