Topic: Alternate Implementation of Colored Bitcoins (Read 2927 times)

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.

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".

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

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.




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.

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.


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. 

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.

one point which seems to lead to confusion in this discussion is the term "account"

The bitcoin protocol proper doesn't detail anything regarding accounts. Accounts are an "overlay" interpretation added by specific clients. The whole notion that you have a sum of bitcoins "in" an address is a conceptual interpretation. The protocol as such only details the forming of valid transactions. And transactions do link a set of inputs to a set of outputs. The only thing BitcoinX changes here is that it replaces the set by a partial ordering.

Your proposed protocol to the contrary is based on the notion of an account having content; on top of that you introduce a separate accounting for colour contents. If I understood your proposal correct, the accounting for bitcoin "content" and colour "content" is even completely disjoint -- since the moving of a amount of colour "content" requires the presence of marker bits in the amount moved by a transaction. Thus it would be possible to void an account of all bitcoin "content" while retaining all of the colour "content".

Note that I do not intend to judge your proposal. And you are absolutely right: with the BitcoinX protocol it is easy to destroy a colour by accidentally using a coloured transaction output in an non-colour aware transaction.

BitcoinX seems to be geared towards proving the coloured-ness of a given transaction output, whereas your proposed protocol intends to construct a full accounting of all colours in an account, which is defined as the summed-up contents of an address.

So here is the example from BitcoinX:

This is what has to happen to transfer colored coins from one address to another, using the BitcoinX approach.  The protocol has to be able to identify Red, Green, and Blue.  But implied is that the protocol has to know that 8 of these Bitcoin are not colored at all, that 8 of these Bitcoin are not any other color that is possible. Failing to identify a color properly would produce different interpretations of the transaction.  All uncolored Bitcoin are last (regardless of when they were added to the account). From the BitcoinX spec, such as it is: "Inputs and outputs are sorted by color, with uncolored coins at the end."


If you can perform the process as described above (quoted directly from the BitcoinX specification for colored coins) without knowing not just Red, Green, and Blue, but all other colored coins as well, then I would love for you to explain how that would work.

I meant what I said and I said what I meant. Every transaction references specific inputs. Transactions do not map inputs to outputs. And an elephant's faithful, one hundred percent.
Your colors aren't "being transferred" anywhere unless you send them.

You said "You should learn about how Bitcoin transactions are formed. Every transaction references specific inputs."

Maybe I just miss understood what you meant by "specific inputs".




For a Colored Coin to properly exist with other colored coins using the ordered colors, all colors must know about one another.  That is just a fact.  You can't order colors if you don't know what they are.  And if you don't know what they are, you don't know where your colors are being transferred when an account with multiple colors transfers value.

Please show me where I said that it did.

You only need to track the colored coins that you own, without "knowing all colors."

Bitcoin doesn't track specific inputs to specific outputs.  If it did, you would not need to order colored coins.

And you want to have uncolored Bitcoin to pay transaction fees. But you don't have to.

You should learn about how Bitcoin transactions are formed. Every transaction references specific inputs.

True, but why would you want to determine that?

A Bitcoin Address sends X coins to Adr1 and Y coins to Adr2.  Suppose the Bitcoin Address held 1 Colored coin.  Well you are golden.  But how do you know there was only 1?  What if there were other inputs?  Which of those are colored?  If there are other colored coins, you have to know the order were they added to the Bitcoin Address.  That order determines if your Colored coin goes to X, or goes to Y (or in what proportion).

I will agree that there are cases where you don't need to know all the colored coins.  But once you have an input that may or may not be a colored coin, well the only way to determine that it isn't colored in any way is to know all the colored coins.

I don't follow your logic. It is possible to track only a single color if you so choose.

How so?  Here is what makes me think this:

I don't see how you can order colored coins at a Bitcoin Address without knowledge of all Colored transactions.  And you can't know about all colored transactions without knowing all colors (or at least being able to discover all colors, which is really the same thing).

You're wrong on at least the first point there.

Bitcoinx has a number of faults, including the following:

• The protocol that requires knowledge of all the colored coins. Without this knowledge, you cannot order the colored coins as it requires. This requires some sort of directory of all colored coins
• Worse, I am not sure how you prove inputs are not actually Colored Inputs unless you check them against all colored addresses (a hugely complicated process!)
• Computing the destination of a colored coin requires computing the sums of all colored coins held at this address.  This computation is recursive, i.e. must be done on all sources of coins as well as the address itself
• The protocol seeks to directly color Bitcoins themselves rather than than color the address.  Bitcoin is a ledger of accounts, so why fight the protocol?  You do not need to color the Bitcoin's themselves, but rather you only need to compute the balance of a colored coin at that address.
• Because the Protocol ties up Bitcoin, the cost of this system must also include the value of the Bitcoin, which may fluctuate wildly;  Especially if Bitcoin continues to grow in value, the Bitcoin may dwarf the value of the underlying colored coin
• Failure to follow the Protocol can result in the destruction of colored coins
• Computing the value of uncolored Bitcoin at an address
  

My proposed alternate protocol addresses these issues.  The Alternate Protocol:

• Does not require knowledge of any other colored coin to compute the balance of colored coins at a Bitcoin Address
• Because knowledge of other colored coins is not required, the balances of colored coin are more private
• Computing a Colored Coin balance at a particular address is far easier
• This protocol doesn't require any kind of change to Bitcoin Clients, even if being aware of the colored protocol by Bitcoin Clients would be very much desired.

• Only requires Bitcoin to transfer balances of colored coins from one address to another;  As long as Bitcoins are transferred out of the address without a valid Bitcoin signature, you can easily repurpose your Bitcoin once a transfer is complete
• No colored coin can be lost;  The worst risks are that colored coins can become "glued together", or one may accidentally transfer a colored coin by inadvertently sending a transaction with a valid signature to another address. (ignoring all the standard risks of not securing your Bitcoin Addresses or losing your private keys.)

so basically your proposal uses the values of Bitcoin transfers, to encode an additional meaning into the least significant digits of the transferred sums. This additional meaning, according to your protocol, denotes the transfer of an colored entity.

It is true that a lot of arbitrary protocols can be implemented on top of the Bitcoin network. SatoshiDice is a good example.

It would be interesting to hear the rationale of preferring your protocol over, e.g. the BitcoinX protocol, which relies directly on the chain of transaction outputs. For example, what would be the computational effort to verify that sum of colored coins you receive has actually not been double spent?

So just to be clear, let's walk through an example of colored coin.

Suppose someone decides they are going to build colored coins around a company's stock.  Company "ABC Inc." decides the following:

• 1 mBTC (.001 BTC) of colored coin represents 1 share of stock in ABC Inc.
• The "Genesis Address" is 1K1RmHkns5QAp9HxPFxU9QSjWVJxudD4EN
• X.XXXXXXX1 is a transfer signiature
• X.XXXX1087 and X.XXXX9783 and X.XXXX8122 are a group transfer signature
  

So ABC Inc. publishes their Genesis Address and their transfer signatures.

Bob decides he wants to buy 10 shares of ABC Inc. directly from ABC Inc. at 2 BTC a share.  So Bob sends 20.01000001 BTC to ABC Inc.  ABC Inc. then sends .01000001 to Bob's Bitcoin Address (1FqM8zRqGF9yjdGBSx9PxarqBMCxW2yMBk) from the Genesis Address (i.e. 1K1RmHkns5QAp9HxPFxU9QSjWVJxudD4EN).

ABC Inc gets 20 BTC, and 10 shares of ABC stock are now at Bob's address (plus the .01000001 BTC).

Bob decides to sell his 10 shares of ABC Inc stock for 30 BTC to Sue by sending the stock to Sue's address (1HytTwtgnCYHSprrsQHn55yYY25TnpQGh5).  Sue sends Bob 30.01000001 BTC.  Then Bob sends Sue .01000001 BTC from 1FqM8zRqGF9yjdGBSx9PxarqBMCxW2yMBk.

ABC can see the transfer of shares from their Genesis address to Bob's Address, and from Bob's Address to Sue's address.  It looks like this:

• 1K1RmHkns5QAp9HxPFxU9QSjWVJxudD4EN -> 1FqM8zRqGF9yjdGBSx9PxarqBMCxW2yMBk of .01000001  (10 shares)
• 1FqM8zRqGF9yjdGBSx9PxarqBMCxW2yMBk -> 1HytTwtgnCYHSprrsQHn55yYY25TnpQGh5 of .01000001 (10 shares)

Any transfers out of the Genesis Address, or Bob's address, or Sue's address that do not end with a .XXXXXXX1 are ignored.  Those are (to this way of thinking) just simple transfers of Bitcoin (or uncolored coin).  All that matters are transfers out of Bitcoin Addresses that 1) have a balance of colored coins, and 2) have the required signature.

Now suppose that Bob chose to buy 10 shares of XYZ inc,  and 10 more shares of ABC inc. stock, and to send it all to his same BTC address.  Now XYZ issued their stock long ago, and made these choices:

• 1 mBTC (.001 BTC) of colored coin represents 1 share of stock in XYZ Inc.
• The "Genesis Address" is 13sJbhmBh73W2aejENvc8cs9nj99DaPUfv
• X.XXXXXXX1 is a transfer signiature
• X.XXXX6287 and X.XXXX6543 and X.XXXX1289 are a group transfer signature
  

So suppose in the Blockchain we find the following sequence:

• 13sJbhmBh73W2aejENvc8cs9nj99DaPUfv -> 1LDq7K5S3pqVFCE32PiNNd5PdXisxfZH7G of .02000001  (20 shares)
• 1LDq7K5S3pqVFCE32PiNNd5PdXisxfZH7G -> 1KuTyFhr4cNYA8hdkmjyYyNYAxYWMoeXsw  of .01500001  (15 shares)
• 1KuTyFhr4cNYA8hdkmjyYyNYAxYWMoeXsw -> 18AfRNJiD23U7hJAjyPiFkLksANNmLpKpk of .01200001  (12 shares)
• 18AfRNJiD23U7hJAjyPiFkLksANNmLpKpk -> 1FqM8zRqGF9yjdGBSx9PxarqBMCxW2yMBk of .01000001  (10 shares)

We can clearly see the set of transfers of colored coin from the Genesis Block for XYZ Inc. (13sJbhmBh73W2aejENvc8cs9nj99DaPUfv) all the way to Bob's address (1FqM8zRqGF9yjdGBSx9PxarqBMCxW2yMBk).  So Bob's address gets a balance of 10 shares of XYZ stock (.010 XYZ Colored Bitcoin).

Now note that there is no path from ABC Inc's genesis block to the Address (18AfRNJiD23U7hJAjyPiFkLksANNmLpKpk) where Bob gets his XYZ Inc. stock.  But both ABC Inc. and XYZ inc stock land in the same address for Bob, i.e. 1FqM8zRqGF9yjdGBSx9PxarqBMCxW2yMBk.

Now Bob decides to sell the XYZ Inc. shares again to Sue for 30 BTC.  But he wants to keep the ABC Inc. shares.  If he sends .01000001 to sue, that will be a valid transfer of the XYZ Inc shares but it will also be a valid transfer of the ABC Inc shares!  The colored coins are "glued together" over the signature .XXXXXXX1.

So instead, Bob requires Sue to pay him 30.00018992, and Bob  sends to Sue .00031087 and .00039783 and .00048122 to her address.  Now when we look at the block chain, we see:

• 1FqM8zRqGF9yjdGBSx9PxarqBMCxW2yMBk -> 1HytTwtgnCYHSprrsQHn55yYY25TnpQGh5 of .00031087  (3 shares)
• 1FqM8zRqGF9yjdGBSx9PxarqBMCxW2yMBk -> 1HytTwtgnCYHSprrsQHn55yYY25TnpQGh5 of .00039783  (3 shares)
• 1FqM8zRqGF9yjdGBSx9PxarqBMCxW2yMBk -> 1HytTwtgnCYHSprrsQHn55yYY25TnpQGh5 of .00048122  (4 shares)

A total of 10 shares (.010 BTC) was transfered from Bob's account (1FqM8zRqGF9yjdGBSx9PxarqBMCxW2yMBk) to Sue's Account (1HytTwtgnCYHSprrsQHn55yYY25TnpQGh5), and all three signatures were used to do it (X.XXXX6287 and X.XXXX6543 and X.XXXX1289).

A multiple signed signature has to find all three signatures originating from a source address with the required number of colored coins all to the same target Bitcoin address.