Bitcoin Forum

I am not sure if anyone else has made the following proposal for implementing Colored Coins.  But just in case nobody has.

A more readable version can be found http://brownzings.blogspot.com/2013/06/an-alternate-more-simple-implementation.html

A Simple Implementation of Colored Bitcoins

Colored Bitcoins allow the trading of stuff using Bitcoins that are not Bitcoins.  As long as those that buy these "colored" coins (likely for prices higher than Bitcoin itself) then the ownership those "colored" coins represent can be secured with the Bitcoin network.

Let's say for example, a company wishes to issue Bitcoin based stock.  Say that .001 of these colored Bitcoins are to represent 1 share of stock in Company X.  As long as the Bitcoin is "colored" in some way, then anyone that owns .001 of these "colored" bitcoins also owns one share of Company X.

Virtual stock exchanges could then trade these stocks, and effortlessly pass these stocks from one client to another, simply by trading these colored coins.  As an added benefit, Company X can find all the Bitcoins representing their stock in the Blockchain.  They can then pay their dividends to those Colored Bitcoins  based on the number of colored coins attributed to each of these Bitcoin addresses.

Loans are also possible, in the same fashion.  And issuers of loans can distribute the risk of a loan by selling off parts of the loan to other people.  Then the payments on the loan could be distributed to all the parties holding the colored coins.  Note that the loans can easily be denominated in Dollars, and payments can be made with "Dollar" colored Bitcoin.  Or in Gold, or Yen, or Euros.  As long as there is supply of such colored coins from some source.

This is the goal.  Now for an implementation that might not be unique to me, but that I have not seen out there in the wild.

A Simple Colored Bitcoin Implementation

There are some efforts out there to implement colored coins.  You can read some of this at BitcoinX.

First of all, there is a Really Simple way to implement Colored Coins.

• Identify a "Genesis" Address.  All Colored Bitcoins are first issued from this address.
• Only transfers from the Genesis Address that have a 1 in the lowest order Satoshi are transfers of the colored coin.
• If a Bitcoin Address contains colored coins, only transfers with a 1 in the lower order Satoshi are transfers of colored coins
• The "1" Satoshi is considered the "colored signature", and is not colored itself.
• Any transfer fee is never colored.

So sending someone .01000001 BTC would send that person .01 Colored Coins. Sending someone .01 BTC would be sending them uncolored coins.

Problems with the Simple Colored Bitcoin Implementation

Multiple colored coins in a single address would "glue" themselves together.  Sending .01000001 BTC of color A to an address X, and .01000001 of Color B to the same address X would result in an address X holding a coin of color AB. Sending .01000001 from  address X would send both the A color and the B color coin to the target address.

Now having a unique bitcoin address for each colored coin you might like to keep does  not seem to me to be too awful of a restriction.  Still, there are some very easy ways to avoid "gluing" BTC together, which we will discuss.

Using Issuer Specific Signatures

The only entity that cares about what that signature is is the issuer, which they can  document for the user, and they can use to run up from their Genesis Account to all the recipients to find the addresses holding their coins.

So an issuer does not have to use .00000001 as their signature.  For example, an  issuer might require transfers of their colored coins to end with .XXXX1012 instead.

For example,

• Issuer A requires .xxxx1101
• Issuer B requires .xxxx0294
• Issuer C requires .xxxx0372

Now if have all three coins in the same Bitcoin Address, I can send them by sending:

• To send .2 of A coins, send .20001101
• To send .4 of B coins, send .40000294
• To send .3 of C coins, send .30000372
• To send 3 uncolored coins, send 3.0

But this does Not Color Bitcoins;  You are Coloring Bitcoin Addresses!

Absolutely.  We are tracking the amount of Colored Coins at a Bitcoin Address using Bitcoin as a protocol.  A Bitcoin address can have a Zero Bitcoin balance, but contain any number of Colored Coins!

So suppose such a Bitcoin Address holds 3  color A Bitcoins, but actually is empty of bitcoin completely.  I can still send the colored coins, by first transferring BTC into the account, then sending the colored coins as required.

• Send to the account 3.00051101 with a .0005 transfer fee
• Send from the account 3.00001101 with a .005 transfer fee

Remember, the transfer fees will never be colored coins!

Going one step further to avoid gluing colored coins

Allowing multiple codes to transfer your coins would further reduce the risk that different colored coins become "glued" to another colored coin.

• colored coin A could require .00000001 or .00001234 and .00009820
• colored coin B could require .00000001 or .00003453 and .00004532
• colored coin C could require .00000001 or .00009876 and .00003289

Now an account holding all three colored coins, A B and C would be "glued" over .00000001. But one could still transfer A only by sending half the amount ending in .00001234  and half ending in .00009820. (The two transactions would be required to the same address to actually transfer the colored coin).

As long as there are some unique codes for the colored coins, then Colored coins can be "unglued".  I'd suggest that all colored coins respect the .00000001 signature, so that it is easy to transfer the colored coins in one Bitcoin Address to another Bitcoin Address if so desired (for cold storage purposes, organizational purposes, etc.)

If each issuer of colored coins picked 3 random numbers between 2 and 9999, the odds of an one issuer having all the same codes as another would be 1 in a trillion.  

Trading Between many Colored Coins

Public trading of colored coins would require a directory of issuers, Genesis Addresses and their signatures.  However, no changes to the Bitcoin protocol or really even Bitcoin clients would be required.  However changes to the clients would make trading colored coins much safer and less error prone.

Conclusion

This approach seems more simple and more compatible with how the Blockchain works today. Furthermore, it can be implemented without anyone else knowing about how you are coloring your coins.  The only people that need to know about your colored coins are the issuer and the user.  Furthermore, Bitcoin can be used as a simple "carrier" without much fuss, allowing Bitcoin addresses to hold many colored coins, even if they hold no Bitcoin at all.

This is wrong. Contrary to what every wallet ever would tell you, your coins aren't aggregated into a "balance." Every transaction references specific inputs. Your scenario would result in address X holding some color A BTC and some color B BTC, that could be transmitted separately without problems.

Actually.... You don't seem to understand the scheme.  So someone with A and B colored coins at the same Bitcoin Address transfers .01000001 to Bitcoin Address X.  Assuming X had no A or B colored coins to begin with, the computed balance of colored coins in X would be .01 of A and .01 of B.  That is because starting from the A color Genesis address and computing forward the balance of A at X, you would see .01000001 transferred to X and would increment the number of A coins at X by .01.  Starting from the B color Genesis address and computing forward the balance of B at X, you would likewise see .01000001 transferred to X and would increment the number of B coins at X by .01.

As far as the Bitcoin balance is concerned at X, you get an uncolored Bitcoin balance addition of .01000001.  Suppose that X ended up with a total balance of .12345678.  Under this scheme, you could transfer all .12345678 BTC away to some other address, and X would still have a  balance of .01 A and .01 B colored Bitcoins.

At this point, I have no idea what you're saying, but I'm willing to bet money that it's wrong.

I am saying that there are alternative ways to compute a balance at a Bitcoin Address.  And while you need Bitcoin to transfer colored coin balances from one address to another (That whole bit about a "signature" as part of a transaction), you don't necessarily need Bitcoin to maintain a colored coin balance at an address.  

The Blog entry describes a way of computing a balance of Colored Bitcoins at an address that is pretty much independent of how you would compute a Bitcoin balance at that address.

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.

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?

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

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

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

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

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.

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

True, but why would you want to determine that?

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.

Please show me where I said that it did.

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

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.

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.

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.

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.

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.

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. 

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.

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

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

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.