Alternate Implementation of Colored Bitcoins

[AlanX]

another interesting difference in your proposal is the handling of double spends. With your approach, it would be possible to get an invalid colour accounting be permanently accepted into the bitcoin blockchain. Thus your protocol needs to define additional rules to resolve such a situation, and these rules need to be enforced by the client accepting an amount of colour.

I don't think there is any way with my proposal that you can get an invalid color accounting accepted into the blockchain.  My proposal would simply interpret an invalid transaction as being a bitcoin transaction outside of the colored coin world, at least if the balance of colored coins was not there to support the transaction attempted.

Contrast this to BitcoinX, where the double-spend detection is done by the miners.

This point shouldn't be taken lightly, since computations with an exponential fan-out tend to become dangerously expensive.

BitcoinX is in exactly the same boat, where the transactions are interpreted in ways that Bitcoin doesn't care or know about.

Bottom line:  If there is an unambiguous way to compute the colored transactions from the origin of colored coins, through all the transactions that pass them about, then you are done.  The BitcoinX protocol as documented (I will not pretend I know everything they are doing) requires each transaction to sort the colors at an address to know what outputs are what colors.  And since you don't know what is in an account unless you can interpret the inputs, that means you have to know what colors were involved with the transaction that provided the inputs to your transaction.  That means you have to know all the colors, or at least what colors are involved. 

My proposal just requires know the source address, the signatures, and the transactions that stem from the source address of the color you are interested in.  The balances of each color within each transaction is completely independent of each other, and from Bitcoin itself. 

[Ichthyo]

another interesting difference in your proposal is the handling of double spends. With your approach, it would be possible to get an invalid colour accounting be permanently accepted into the bitcoin blockchain. Thus your protocol needs to define additional rules to resolve such a situation, and these rules need to be enforced by the client accepting an amount of colour.

My proposal would simply interpret an invalid transaction as being a bitcoin transaction outside of the colored coin world, at least if the balance of colored coins was not there to support the transaction attempted.

Exactly that's the issue.

This means, your proposal decouples the bitcoin value "in" an account from the colour value in that account. This is a direct consequence of your choice to tie the colours to the "contents" of the account, instead of relying on the TX outputs, as BitcoinX does.


Consequently, you have to do a double accounting. One is for Bitcoin value (which is basically verified by the miners), and then you need to do your own, private accounting for the colour "contents". It would be possible for an account to have Bitcoin value Zero (since all valid TX outputs were spent), but still hold a colour value (since none of these outgoing transactions used a clour marker). Of course you can come up with additional rules to define when colour value in an account gets destroyed.


And for double spend detection, you have to do this accounting for all touched addresses in the TX chain back to the origin. Thus you have to visit and verify all TX on all addresses touched in the chain.

Contrast this to BitcoinX, where the double-spend detection is done by the miners, since BitcoinX simply relies on the validity of an TX output (you can not double spend BitcoinX colours). Thus BitcoinX only needs to verify the colouredness, which doesn't require to visit all the TX on each address, but only those in the TX chain leading to the colour origin. But BitcoinX has to follow all these chains.


And, as said, this happens in a context which is computationally expensive, to a degree that it can exhaust any computational resources available.

BitcoinX has the same fundamental problem, but your proposed protocol is not less expensive as BitcoinX, but I'd guess that its typically more expensive, since you have to investigate the history of each touched address.

Bitcoin itself is not affected by this problem, since the effort is split up and spent once per block.

BitcoinX is in exactly the same boat, where the transactions are interpreted in ways that Bitcoin doesn't care or know about.

We should state it more precisely

• BitcoinX marks existing TX outputs as coloured through an additional convention
• your protocol uses an hidden channel to attach additional metadata to TX in the bitcoin network

I fully agree with you that BitcoinX has the problem that you need to know all involved colours in order to prove the colouredness of a TX.
Which could become a serious issue once coloured coins are widely used and interchanged outside of a clearly delineated usage circle.

[GaltForever]

AlanX I sent you a PM. I believe you have laid the bed rock of a beautiful solution to a great problem.

[AlanX]

another interesting difference in your proposal is the handling of double spends. With your approach, it would be possible to get an invalid colour accounting be permanently accepted into the bitcoin blockchain. Thus your protocol needs to define additional rules to resolve such a situation, and these rules need to be enforced by the client accepting an amount of colour.

Contrast this to BitcoinX, where the double-spend detection is done by the miners.

This point shouldn't be taken lightly, since computations with an exponential fan-out tend to become dangerously expensive.

Hey, sorry I didn't notice your post way back in July.

Quite a bit of time has gone by, and I would like to point out that what you are saying isn't true.  My approach also uses the miners to prevent double spends.  As long as there exists a non ambiguous accounting of what outputs represent how much colored coins, the colored value at an address can be determined.  You can't double spend unless the accounting rules are ambiguous.

Also with my approach, the key is the script. To be lazy we can call it a bitcoin address, but it doesn't have to be.  It can be a double signed or triple signed transaction.  As long as the rules are unambiguous, you can use the Bitcoin protocol to protect against counterfeiting and double spends.

And the biggest advantage is that all colored coins are completely independent of each other.  Neither the issuer nor the users ever need to care about colored coins they are not using.  One never has to "sort the coins".

[Ichthyo]

another interesting difference in your proposal is the handling of double spends. With your approach, it would be possible to get an invalid colour accounting be permanently accepted into the bitcoin blockchain. Thus your protocol needs to define additional rules to resolve such a situation, and these rules need to be enforced by the client accepting an amount of colour.

.... I would like to point out that what you are saying isn't true.  My approach also uses the miners to prevent double spends.  As long as there exists a non ambiguous accounting of what outputs represent how much colored coins, the colored value at an address can be determined.  You can't double spend unless the accounting rules are ambiguous.

Sorry for nitpicking, but you can't say "this is not true" without a proper argument.

Your original proposal quite clearly established an additional layer of accounting on top of the bitcoin network. Thus you need to perform that additional accounting to determine if your coloured coin's balance is correct, or if there was a double spent.

Thus you have not the slightest reason to claim that your protocol uses the miners to prevent such a colour double spend. Since in your proposal, it is perfectly valid to have an bitcoin transaction accepted by the standard bitcoin network, while it represents a fraudulent double spend of a coloured coin according to your additional accounting rules.

The situation in BitcoinX is different. There you can loose a colour by a carelessly constructed transaction. But you can't double spend a colour amount, since it is identical to an bitcoin Tx output. Which is protected by the miners.

This is a difference you simply can't deny, and you shouldn't try to create a spin based on such argumentation. We should try to be honest in technical argumentation.

Please note, I decline from judging either your proposal or bitcoinX. Both have their specific strengths and weaknesses. Using an independent virtual layer on top can be a benefit or can be a drawback. Linking the colours direct to Tx outputs can also be a drawback or a benefit.