Blockchain security tracking/colored coins/smart contracts - short python script

[bitfair]

It'd be good if the coloured coins could be held in one blockchain.info wallet and dividends paid to any of the coins owners choosing.  Also what keep's the proof of the coloured coins?  If it's just your 'short python script' on my machine then I need a way to back proof up online and to be able to distribute it to each coloured coin owner.  Sorry if that sounds stupid and/or I've missed the point, still trying to figure this all out.

You prove that you own colored coins by holding the private key of the address they held at (same way as you prove that you own any bitcoin, in fact). For my script, the private keys of the addresses you generate with the client for holding colored coins are held in a configuration file. The file is relatively small and in plaintext, and can easily be backed up, sent by e-mail, stored offsite, etc.

Better to show by example, perhaps:
--------
1. An "asset issuer" essentially says something like: "I will use the output number 2 from transaction 630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b to represent 100% of the shares in my company, whoever holds the descendants of this output holds a proportional share of the company."

Output number 2 from that transaction belongs to 1AEn3U5MhedXYRbpxLKmkL4r5Kz1XkdZA, as can be seen by the whole world at http://blockchain.info/tx/630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b, and can also be verified in their own local blockchain.

2. The "asset issuer" can now transfer those bitcoins or portions of those bitcoins to other addresses. The transfer will be stored in the public ledger/blockchain - everyone can verify that output number 2 from transaction 630bcc... was assigned to three new addresses in transaction d8e8dc799be1b552f29f8cbd2df24a1fcb9c2a9f4a43c9b4444b9dc329bbd17d, http://blockchain.info/tx/d8e8dc799be1b552f29f8cbd2df24a1fcb9c2a9f4a43c9b4444b9dc329bbd17d. 60% of the value was transferred to 1KbDEaZ99YJYaT62emhFwabFoqQ6LYdJg9, 30% to 1DAHyXPNJjqLGFNqHhavrukWZ6XkY8Kj21 and 10% to 1Mhx4LMjbmN6KJ9B5BkdZ5zVWQP64F5TJC.

The holders of these three addresses are now the new owners of the company, since they hold coins that descend from the "ancestor" transaction output. The evidence is in the public ledger for all to see.

3. The holders of these three addresses can again make transfers to other addresses, each time the public ledger/bitcoin blockchain will hold a record of the transaction, such that the genealogy can be traced back to the original ancestor that represented 100% of the company.
--------

The script I have written essentially just makes sure that the transactions are "nicely" formed, in such a way that descendants of the ancestor are recorded in a very obvious manner in the bitcoin blockchain, and contains a mechanism to track the descendants.

Did that make it clearer, or just mix it up even more (if so, sorry about that!)?

[bitfair]

Is it possible to force a specific transaction fee to any colored coin transaction?

For example: a transaction fee of 0.00050321

In this case the colored coin application/script should:

• Always use such specific "fixed" transaction fee value in transferring colored coins
• And in return, ignore "doesn't interpret" any transaction that doesn't have such "fixed" transaction fee

This way the application can guard colored coins from accidentally being spent.

That might solve the problem if you could agree all client developers (Satoshi+MultiBit+Armory+Electrum+++) to agree that transactions with a fee of that specific value are pariah, which might be hard.

Until then, I found it easier to simply store the keys for the addresses that hold colored coin separately from the normal wallet.dat. Cumbersome and ugly, some may argue, but I feel it certainly mitigates the problem.

[matthewh3]

It'd be good if the coloured coins could be held in one blockchain.info wallet and dividends paid to any of the coins owners choosing.  Also what keep's the proof of the coloured coins?  If it's just your 'short python script' on my machine then I need a way to back proof up online and to be able to distribute it to each coloured coin owner.  Sorry if that sounds stupid and/or I've missed the point, still trying to figure this all out.

You prove that you own colored coins by holding the private key of the address they held at (same way as you prove that you own any bitcoin, in fact). For my script, the private keys of the addresses you generate with the client for holding colored coins are held in a configuration file. The file is relatively small and in plaintext, and can easily be backed up, sent by e-mail, stored offsite, etc.

Better to show by example, perhaps:
--------
1. An "asset issuer" essentially says something like: "I will use the output number 2 from transaction 630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b to represent 100% of the shares in my company, whoever holds the descendants of this output holds a proportional share of the company."

Output number 2 from that transaction belongs to 1AEn3U5MhedXYRbpxLKmkL4r5Kz1XkdZA, as can be seen by the whole world at http://blockchain.info/tx/630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b, and can also be verified in their own local blockchain.

2. The "asset issuer" can now transfer those bitcoins or portions of those bitcoins to other addresses. The transfer will be stored in the public ledger/blockchain - everyone can verify that output number 2 from transaction 630bcc... was assigned to three new addresses in transaction d8e8dc799be1b552f29f8cbd2df24a1fcb9c2a9f4a43c9b4444b9dc329bbd17d, http://blockchain.info/tx/d8e8dc799be1b552f29f8cbd2df24a1fcb9c2a9f4a43c9b4444b9dc329bbd17d. 60% of the value was transferred to 1KbDEaZ99YJYaT62emhFwabFoqQ6LYdJg9, 30% to 1DAHyXPNJjqLGFNqHhavrukWZ6XkY8Kj21 and 10% to 1Mhx4LMjbmN6KJ9B5BkdZ5zVWQP64F5TJC.

The holders of these three addresses are now the new owners of the company, since they hold coins that descend from the "ancestor" transaction output. The evidence is in the public ledger for all to see.

3. The holders of these three addresses can again make transfers to other addresses, each time the public ledger/bitcoin blockchain will hold a record of the transaction, such that the genealogy can be traced back to the original ancestor that represented 100% of the company.
--------

The script I have written essentially just makes sure that the transactions are "nicely" formed, in such a way that descendants of the ancestor are recorded in a very obvious manner in the bitcoin blockchain, and contains a mechanism to track the descendants.

Did that make it clearer, or just mix it up even more (if so, sorry about that!)?

Yeah it shed a bit of light.  So do you recomend every shareholder I send the coloured coin first uses your new client to receive there coloured coins before sending them elsewhere for safe keeping.  So they can get a copy of the ledger in the blockchain.  I know I can just state - 630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b - is the genesis coloured coin but I imagine its your client that makes visible these coins are coloured.  Otherwise how do people trace there coloured coins back to - 630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b -
So in short people just need to save just tx - 630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b - and their private-key to prove ownership.  I suspect your new client does all the blockchain checking from tx - 630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b ??

[Energizer]

Is it possible to force a specific transaction fee to any colored coin transaction?

For example: a transaction fee of 0.00050321

In this case the colored coin application/script should:

• Always use such specific "fixed" transaction fee value in transferring colored coins
• And in return, ignore "doesn't interpret" any transaction that doesn't have such "fixed" transaction fee

This way the application can guard colored coins from accidentally being spent.

That might solve the problem if you could agree all client developers (Satoshi+MultiBit+Armory+Electrum+++) to agree that transactions with a fee of that specific value are pariah, which might be hard.

Until then, I found it easier to simply store the keys for the addresses that hold colored coin separately from the normal wallet.dat. Cumbersome and ugly, some may argue, but I feel it certainly mitigates the problem.

I just think about it as a second layer of securing the colored coins. Actually I came to this point not only to guard colored coins but to make use of the transaction fee value as a messaging protocol command.

[Energizer]

As far as I understand your design doesn't have a mechanism for exchanging "shares/colored coins <-> BTC". I am still new to the term "colored coins", I came across it when I was trying to find any decentralized solution for exchanging Assets <-> BTC. Your design seems idle for issuing/tracking colored coins ownership. I am thinking to start using your implementation soon for my asset "Bitnodes". Please correct me if am wrong; there is one problem/feature that is missing in all colored coins implementations that I've researched, which is "a mechanism for exchange". I wouldn't argue that such exchange mechanism is beyond the concept of colored coins. What I mean by an exchange mechanism, is to have a mechanism to create ask/bid orders, and to be able to perform the exchange automatically in a decentralized manner by only relaying on the block chain and the colored coins software.

[bitfair]

Yeah it shed a bit of light.  So do you recomend every shareholder I send the coloured coin first uses your new client to receive there coloured coins before sending them elsewhere for safe keeping.  So they can get a copy of the ledger in the blockchain.  I know I can just state - 630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b - is the genesis coloured coin but I imagine its your client that makes visible these coins are coloured.  Otherwise how do people trace there coloured coins back to - 630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b -
So in short people just need to save just tx - 630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b - and their private-key to prove ownership.  I suspect your new client does all the blockchain checking from tx - 630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b ??

Correct: what your shareholders need to know is that 630bcca... is the ancestor/root/genesis, and after that the script figures out all the shareholders by traversing the list of "well-formed" transactions from there onwards.

IF someone was adventurous enough (i.e. moreso than Indiana Jones or Ranulph Fiennes) to want to use this script at the moment, then I would recommend every shareholder to generate an "asset holding" address with this script. Thereafter, the asset issuer would make transfers to that address. Every shareholder would also have to be told the transaction ID of the genesis transaction (and the output number), which each one would then have to add to their client.

Those concerned about security could also write their private key down on a piece of paper (it is stored in plaintext in the configuration file) and remove it from the configuration file. However, when making transfers, they would have to re-enter the private key in the config file...

[killerstorm]

there is one problem/feature that is missing in all colored coins implementations that I've researched, which is "a mechanism for exchange". I wouldn't argue that such exchange mechanism is beyond the concept of colored coins. What I mean by an exchange mechanism, is to have a mechanism to create ask/bid orders, and to be able to perform the exchange automatically in a decentralized manner by only relaying on the block chain and the colored coins software.

I definitely plan to implement an exchange mechanism in client software I'm working on. However I think ask/bid orders should be broadcast on a separate network, doing it via blockchain would be kind of a waste of resources.

(However it isn't totally out of questions, there are alt-chain designs which are more scalable than bitcoin and they will be able to handle bid/ask traffic in blockchain.)

[killerstorm]

through the coal to find the diamonds, so if anyone can point to a whitepaper, a spec, a particularly enlightening post, preferably showing examples of transactions and how the color should be interpreted in the input/output for various approaches, then I would be very grateful. A deconstructed example of for instance 2 colored+2 uncolored inputs should be pretty comprehensive - anyone seen such a thing?

This thread has links to everything: rules, examples, code, interactive demo: https://bitcointalk.org/index.php?topic=114571.0

However this version of code might be easier to read: https://github.com/killerstorm/colored-coin-tools/blob/master/color.js

Only compute_colors() function is necessary, the rest is just validation/sanity check.

[Energizer]

there is one problem/feature that is missing in all colored coins implementations that I've researched, which is "a mechanism for exchange". I wouldn't argue that such exchange mechanism is beyond the concept of colored coins. What I mean by an exchange mechanism, is to have a mechanism to create ask/bid orders, and to be able to perform the exchange automatically in a decentralized manner by only relaying on the block chain and the colored coins software.

I definitely plan to implement an exchange mechanism in client software I'm working on. However I think ask/bid orders should be broadcast on a separate network, doing it via blockchain would be kind of a waste of resources.

(However it isn't totally out of questions, there are alt-chain designs which are more scalable than bitcoin and they will be able to handle bid/ask traffic in blockchain.)

I am looking forward for your exchange mechanism solution. Where can I follow that?

What do you think about using transaction fees values as messaging protocol events for a colored coins application? Do you know of any implementation that applies that?

[bitfair]

As far as I understand your design doesn't have a mechanism for exchanging "shares/colored coins <-> BTC". I am still new to the term "colored coins", I came across it when I was trying to find any decentralized solution for exchanging Assets <-> BTC. Your design seems idle for issuing/tracking colored coins ownership. I am thinking to start using your implementation soon for my asset "Bitnodes". Please correct me if am wrong; there is one problem/feature that is missing in all colored coins implementations that I've researched, which is "a mechanism for exchange". I wouldn't argue that such exchange mechanism is beyond the concept of colored coins. What I mean by an exchange mechanism, is to have a mechanism to create ask/bid orders, and to be able to perform the exchange automatically in a decentralized manner by only relaying on the block chain and the colored coins software.

Indeed, there is no built-in design for exchanging, the design simply does the easy part - issuing/tracking ownership of colored coins. (It can also pay dividends to the owners, but that is not really conceptually different.)

The question of decentralized exchange is a somewhat separate (but related) issue. I had some thoughts on it while I was trying to sleep last night, I might try a simple prototype of that too when I'm relatively satisfied that this script does what I want it to.

What I had in mind was not necessarily decentralized, but more of a protocol that would be agnostic to the transport layer. But imagine that you have a client and a server (in a p2p design, each node could be both). The protocol would be relatively simple:
1) CLIENT connects to SERVER
2) CLIENT requests order book from SERVER
Then either:
3a) CLIENT wants to enter a new order in the book: e.g. BID: ASSET1@400BTC, and signs it with address(es) that controls at least 400BTC, sends to SERVER
4a) SERVER verifies signature, enters into order book
5a) SERVER broadcasts order to all CLIENTS
or:
3b) CLIENT wants to hit an order from the book: constructs a transaction with the inputs taken from own wallet and inputs specified in the order, signs his inputs and sends to SERVER
4b) SERVER broadcasts to incomplete transaction to all CLIENTS
5b) The CLIENT that originally made the offer signs the last inputs, and broadcasts the complete transaction on the bitcoin network.


All nodes will also need to monitor the blockchain, so that if any of the inputs are spent that are part of an unfilled order, that order is immediately removed from the books.

There's not really that much needed to make it work. I'm sure a lot of people have had the same (probably much more clever) idea(s). Decentralized or centralized, following such a protocol would at least not leave you with a single point of failure - asset ownership would be public and undisputable at all times, the blockchain would contain a complete price history, and you essentially wouldn't have to trust any third party. The worst thing that could happen is that the counterparty does not sign the transaction when you want to hit an order from the book, but in that case you keep your BTC anyway.

Anyway - sorry, offtopic

PS: Making the transaction fees "information-bearing" doesn't sound very good to me. Imagine if you can afford the transaction, but you can't afford to make the transaction with the message you want?

[bitfair]

through the coal to find the diamonds, so if anyone can point to a whitepaper, a spec, a particularly enlightening post, preferably showing examples of transactions and how the color should be interpreted in the input/output for various approaches, then I would be very grateful. A deconstructed example of for instance 2 colored+2 uncolored inputs should be pretty comprehensive - anyone seen such a thing?

This thread has links to everything: rules, examples, code, interactive demo: https://bitcointalk.org/index.php?topic=114571.0

However this version of code might be easier to read: https://github.com/killerstorm/colored-coin-tools/blob/master/color.js

Only compute_colors() function is necessary, the rest is just validation/sanity check.

Thanks, I'll certainly take a close look at this! The order-based method of coloring certainly makes a lot of sense.

[Energizer]

PS: Making the transaction fees "information-bearing" doesn't sound very good to me. Imagine if you can afford the transaction, but you can't afford to make the transaction with the message you want?

What do you mean by "affording a transaction but can't afford the transaction message you want" can you give an example?

If you just make use of the last 2 digits in the transaction fee: 0.000000## this can give 100 different variation = 100 different events/messages

I don't think that you would need more than 100 different messages, knowing that currently your design is based on a single message: colored coins moving from one address to another. Imagine if you can have 100 different events/messages going in/out of a BTC address. In this case you wouldn't even need to move the colored coins! the colored coin term wouldn't even apply here. Cause by then you would be applying a virtual messaging protocol on top of the block chain, where nodes = BTC addresses, messages/events = transaction fees, message/event payload = the value being transfered. Only then the variations that such design can give would allow a decentralized exchange mechanism to take place: You want to sell 10 shares @ 0.1? send a transaction to the BTC address you want to receive payment to with the value you want to accept per share and a transaction fee with last digits = to the "ask order" message/event. The same senario can be used in buying the shares. Does that make any sense?

[Energizer]

What would be more interesting is instead of sending the message in the transaction fee, is to send the message as a small BTC amount to the issuer's BTC address as a second recipient in sendmany(). This way all messages related to that particular asset can be tracked through the issuer's BTC address. The issuer can then benefit from the messaging mechanism instead of wasting BTC in the transaction fee.

[yoniassia]

As far as I understand your design doesn't have a mechanism for exchanging "shares/colored coins <-> BTC". I am still new to the term "colored coins", I came across it when I was trying to find any decentralized solution for exchanging Assets <-> BTC. Your design seems idle for issuing/tracking colored coins ownership. I am thinking to start using your implementation soon for my asset "Bitnodes". Please correct me if am wrong; there is one problem/feature that is missing in all colored coins implementations that I've researched, which is "a mechanism for exchange". I wouldn't argue that such exchange mechanism is beyond the concept of colored coins. What I mean by an exchange mechanism, is to have a mechanism to create ask/bid orders, and to be able to perform the exchange automatically in a decentralized manner by only relaying on the block chain and the colored coins software.

Once a there is an ability to color coins, there is a built in mechanism of exchanging any colored BTC to any colored BTC (regular BTC can simply considered white BTC). For example, lets assume I start a color called BTX , coloring is simply accepting some initial genesis input as those colored coins, I can now exchange with you 1 BTX for 2 BTC, we need to trust each other and agree on a price offcourse, there are mechanism in bitcoin to act as escrow for this transaction, but those are 3rd parties.
So at anytime you can look at the blockchain and see all BTX/BTC transactions, since colors are public, and you can show last price and historical prices, you can simply agree on the last price, or last price + x.
When you mentioned bid/ask, that is simply a matching engine, that might require another 3rd party, but is not necessary for the basic use of an exchange, as a bid/ask book is actually centralized for of exchange.
Take for example currency trading, there is no ask/bid centralized anywhere, yet it is the most sophisticated and liquid market in the world, possibly because of its OTC and decentralized model.

[Energizer]

As far as I understand your design doesn't have a mechanism for exchanging "shares/colored coins <-> BTC". I am still new to the term "colored coins", I came across it when I was trying to find any decentralized solution for exchanging Assets <-> BTC. Your design seems idle for issuing/tracking colored coins ownership. I am thinking to start using your implementation soon for my asset "Bitnodes". Please correct me if am wrong; there is one problem/feature that is missing in all colored coins implementations that I've researched, which is "a mechanism for exchange". I wouldn't argue that such exchange mechanism is beyond the concept of colored coins. What I mean by an exchange mechanism, is to have a mechanism to create ask/bid orders, and to be able to perform the exchange automatically in a decentralized manner by only relaying on the block chain and the colored coins software.

Once a there is an ability to color coins, there is a built in mechanism of exchanging any colored BTC to any colored BTC (regular BTC can simply considered white BTC). For example, lets assume I start a color called BTX , coloring is simply accepting some initial genesis input as those colored coins, I can now exchange with you 1 BTX for 2 BTC, we need to trust each other and agree on a price offcourse, there are mechanism in bitcoin to act as escrow for this transaction, but those are 3rd parties.
So at anytime you can look at the blockchain and see all BTX/BTC transactions, since colors are public, and you can show last price and historical prices, you can simply agree on the last price, or last price + x.
When you mentioned bid/ask, that is simply a matching engine, that might require another 3rd party, but is not necessary for the basic use of an exchange, as a bid/ask book is actually centralized for of exchange.
Take for example currency trading, there is no ask/bid centralized anywhere, yet it is the most sophisticated and liquid market in the world, possibly because of its OTC and decentralized model.

The method of exchange you've explained is the only possible way in the current design and that is exactly what I am trying to stay away from. We still need a decentralized exchange mechanism, why?

• Cause trust should be imbedded within the mechanism itself instead of person to person exchange
• Also we need a decentralized mechanism to broadcast ask/bid orders instead of relaying on a "centralized" third party client/server mechanism
• Remember that the main reason we end up being here is strongly related to "TRUST", we need a simple user friendly application that we can trust more than any other centralized solution

[yoniassia]

There's a bounty available:
https://bitcointalk.org/index.php?topic=106373.msg1269388#msg1269388

I'm hoping the main group of people pushing for the development of this technology will
post a link to this bounty to inspire others to donate as well.

This is really great stuff and I'm very excited to see where it will go.

Taking your 2, and adding another 20 BTC donation
and adding link to a public document that started the documentation :
https://docs.google.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit

Anyone who wants editing rights, simply send me your email in a private message

[bitfair]

through the coal to find the diamonds, so if anyone can point to a whitepaper, a spec, a particularly enlightening post, preferably showing examples of transactions and how the color should be interpreted in the input/output for various approaches, then I would be very grateful. A deconstructed example of for instance 2 colored+2 uncolored inputs should be pretty comprehensive - anyone seen such a thing?

This thread has links to everything: rules, examples, code, interactive demo: https://bitcointalk.org/index.php?topic=114571.0

However this version of code might be easier to read: https://github.com/killerstorm/colored-coin-tools/blob/master/color.js

Only compute_colors() function is necessary, the rest is just validation/sanity check.

killerstorm,

I imagine you could be watching, so let me ask a question about an aspect your algorithm/code/example in color.js that I am having some difficulty with regarding transactions with several inputs of the same color: during "traversing the tree of ownership" to determine owners of the colored coins, at some point you may see a transaction where two inputs have the same color, but you are only aware that one of the inputs are colored (while following the input that lead first lead you to hit the node).

During a traversal, how can you be sure that you have the (same-)color information for all the inputs? I was thinking "well, just process in order of appearance", but if the transaction with two inputs of the same color occurs in the same block as the transaction that adds color to one of the inputs, we again have a problem.

Any ideas?

PS: It would be fun if you have any test-cases that are available in the blockchain that could be checked, to verify that our interpretations on how color is transferred from inputs to outputs coincide...

[killerstorm]

I imagine you could be watching, so let me ask a question about an aspect your algorithm/code/example in color.js that I am having some difficulty with regarding transactions with several inputs of the same color: during "traversing the tree of ownership" to determine owners of the colored coins, at some point you may see a transaction where two inputs have the same color, but you are only aware that one of the inputs are colored (while following the input that lead first lead you to hit the node).

Well, yes, that's a problem.

Here's one of possible solutions outlined: https://bitcointalk.org/index.php?topic=117630.msg1269200#msg1269200

During a traversal, how can you be sure that you have the (same-)color information for all the inputs?

You shouldn't color them when you're traversing, instead you can collect topo-sorted list and them color them one by one.

PS: It would be fun if you have any test-cases that are available in the blockchain that could be checked, to verify that our interpretations on how color is transferred from inputs to outputs coincide...

Yep that would be cool, but I don't have any non-trivial examples in blockchain.

[matthewh3]

There's a bounty available:
https://bitcointalk.org/index.php?topic=106373.msg1269388#msg1269388

I'm hoping the main group of people pushing for the development of this technology will
post a link to this bounty to inspire others to donate as well.

This is really great stuff and I'm very excited to see where it will go.

Taking your 2, and adding another 20 BTC donation
and adding link to a public document that started the documentation :
https://docs.google.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit

Anyone who wants editing rights, simply send me your email in a private message

Maybe one of you should start a bounty wallet on this site - https://booster.io/ - so its easier for other people to add small bits too.

Edit:

Please be cautious when using it, but feel free to criticise, modify and contribute. And if you like it, support it: 1GsnaaAWYMb7yPwBQ19bSLLMTtsfSyjqg3.

[matthewh3]

There are now many threads about "colored coins", "smart contracts" and otherwise tracking specific coins through the blockchain.

I have created a simple command-line Python program to handle tracking of "colored coins", "smart contracts" or "blockchain securities" in the blockchain.

There are other approaches, and the one I have taken is very simple, but it is a working solution (primitively duct-taped and glued together). I also have not read gone into the details of the other approaches, so it is probably safe to say that the method I have created is completely incompatible with the other methods (which are probably much smarter too).

But it is a live and implemented solution, which gives it an advantage over others. It is short, easy to modify and fun to play with. It might be useful for some adventurous security issuers who are looking for a solution now that GLBSE is shutting down.

Full source: http://pastebin.com/NnNug0nL

Update Oct 15:

The source code has been updated, the new version includes functions to pay dividends to holders of the colored coins.

Also, it has been tested more thoroughly, and I have created a 12-step usage example that shows the current capabilities of the script.

Usage example:

Code:

1. First run config setup:
$ python bitpaint.py
Configuration file bitpaint.conf not found. Creating one...
bitcoind rpc host (default: 127.0.0.1): 
bitcoind rpc port (default: 8332): 
bitcoind rpc username (default: <blank>): ********
bitcoind rpc password (default: <blank>): ********

2. Create address:
$ python bitpaint.py -n
Address added: 1AEn3U5MhedXYRbpxLKmkL4r5Kz1XkdZA

3. Transfer the colored coins to the address (sent 0.01 BTC to the address above using Satoshi client). Make a note of (1) the Transaction ID: 630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b, (2) the output that was sent to the address above: 1.

4. "Paint" the output of the transaction, call the painted coins "BITFAIR-SHARES":
$ python bitpaint.py -p BITFAIR-SHARES:630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b:1

5. Show the ownership info of the painted coins "BITFAIR-SHARES", the output is the owner address, the amount the address owns, and the transaction output which assigned ownership to that address, then a line with a total at the bottom:
$ python bitpaint.py -o BITFAIR-SHARES
*** BITFAIR-SHARES ***
1AEn3U5MhedXYRbpxLKmkL4r5Kz1XkdZA 0.01 630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b:1
** Total BITFAIR-SHARES: 0.010000 **

6. Create three new addresses (could be done by another user, for example the buyer of the security - the buyers should also run the command in step 4 to initiate the coin tracking), and create a transaction that transfers 0.006 to the first address (represents 60% of "outstanding shares"), 0.003 to the second (represents 30% of "outstanding shares) and 0.001 to the third (represents 10% of "outstanding shares"):
$ python bitpaint.py -n
Address added: 1KbDEaZ99YJYaT62emhFwabFoqQ6LYdJg9
$ python bitpaint.py -n
Address added: 1DAHyXPNJjqLGFNqHhavrukWZ6XkY8Kj21
$ python bitpaint.py -n
Address added: 1Mhx4LMjbmN6KJ9B5BkdZ5zVWQP64F5TJC
$ python bitpaint.py -f 1AEn3U5MhedXYRbpxLKmkL4r5Kz1XkdZA:630bccacd6f4401fde53822af3f011daa47ec1bedd1702bf7d0be4391948f49b:1 -t 1KbDEaZ99YJYaT62emhFwabFoqQ6LYdJg9:0.006,1DAHyXPNJjqLGFNqHhavrukWZ6XkY8Kj21:0.003,1Mhx4LMjbmN6KJ9B5BkdZ5zVWQP64F5TJC:0.001
01000000019bf4481939e40b7dbf0217ddbec17ea4da11f0f32a8253de1f40f4d6accc0b63010000008b483045022100dd23f8d8cc3c92314127badcdd50c22414fe1bdf50215c3edce89f0aa64836bd02200c940f4a5ca59c133f14269c3cc2568e8340ec09d90f65c3264f869e93f28e010141047002cabfc1da529ab13d035a60b11db585be5709ddd7d8ab5649ce5d71a279bcb681007bb929f8adf7d811726cd82da5aa1fa96cd736cca986a79c89186a1e29ffffffff03e0930400000000001976a91485636c3633be3a41ce4893dc84ab31fd2d96ea4f88aca0860100000000001976a914e3211d2305301fe6421dbf85685a2744ca51817e88acc0270900000000001976a914cbea9e8c8392abc07417f95bfcb2f21406c6599088ac00000000

7. The result of the former step is a hex-encoded raw transaction. Because it contains no transaction fees, the standard satoshi client will refuse to send it. However, the resulting hex-encoded raw transaction can be broadcast on the network using http://blockchain.info/pushtx. PS: At the moment, you cannot be sure that the transaction will be included in a block, since it contains no transaction fee (i.e. compensation to the miners). I am currently working on a solution to this.

8. Update list of BITFAIR-SHARES holders, and show it:
$ python bitpaint.py -u BITFAIR-SHARES
$ python bitpaint.py -o BITFAIR-SHARES
*** BITFAIR-SHARES ***
1DAHyXPNJjqLGFNqHhavrukWZ6XkY8Kj21 0.003 d8e8dc799be1b552f29f8cbd2df24a1fcb9c2a9f4a43c9b4444b9dc329bbd17d:0
1Mhx4LMjbmN6KJ9B5BkdZ5zVWQP64F5TJC 0.001 d8e8dc799be1b552f29f8cbd2df24a1fcb9c2a9f4a43c9b4444b9dc329bbd17d:1
1KbDEaZ99YJYaT62emhFwabFoqQ6LYdJg9 0.006 d8e8dc799be1b552f29f8cbd2df24a1fcb9c2a9f4a43c9b4444b9dc329bbd17d:2
** Total BITFAIR-SHARES: 0.010000 **

9. Pay dividends of 0.1 BTC in total from my wallet account named "bitpaint_donations" to the holders of the colored coins ("shareholders of BITFAIR-SHARES") (not sure if this works with an encrypted wallet, should be easy enough to fix for those who have it):
$ python bitpaint.py -d BITFAIR-SHARES:bitpaint_donations:.1

10. List what shares/colored coins are owned by me, their dividends (and address that the shares/dividends belong to, along with the transaction output that assigned the shares to my address):
$ python bitpaint.py -m
BITFAIR-SHARES 0.003 ( div: 0.03 ) 1DAHyXPNJjqLGFNqHhavrukWZ6XkY8Kj21 d8e8dc799be1b552f29f8cbd2df24a1fcb9c2a9f4a43c9b4444b9dc329bbd17d:0
BITFAIR-SHARES 0.001 ( div: 0.01 ) 1Mhx4LMjbmN6KJ9B5BkdZ5zVWQP64F5TJC d8e8dc799be1b552f29f8cbd2df24a1fcb9c2a9f4a43c9b4444b9dc329bbd17d:1
BITFAIR-SHARES 0.006 ( div: 0.06 ) 1KbDEaZ99YJYaT62emhFwabFoqQ6LYdJg9 d8e8dc799be1b552f29f8cbd2df24a1fcb9c2a9f4a43c9b4444b9dc329bbd17d:2

11. Forward dividends from my asset-addresses to one of my wallet addresses:
$ python bitpaint.py -x 1DAHyXPNJjqLGFNqHhavrukWZ6XkY8Kj21 -y 16KUdKHHZ1AUVb4ZH6Q2VY55L3V3gCCSmr
0100000001cf707398596a9f8bf45e22e3f736b819f27ba6d10cb9c12f1ca23a9daf0c6f1d000000008c4930460221009eb892e079fd143fd5b1919c0c07073d1d45a671aabb05d2565721ae3f83aee6022100a60706b226ef968038ef654f8b782103170932201b7e9fc9320ec24027c56e14014104f7e514dad77c0dbf157c1cc88d610a512f9809785fda426ca7ee3c70df59afeee521ccb02f610536e093b954c4718a4b9d2c028aaec62ad2f138d0735a0d918dffffffff01a0252600000000001976a9143a572d6755022d568f7a78d0060234920486cd0f88ac00000000
Paid 0.025 to 16KUdKHHZ1AUVb4ZH6Q2VY55L3V3gCCSmr
$ python bitpaint.py -x 1Mhx4LMjbmN6KJ9B5BkdZ5zVWQP64F5TJC -y 16KUdKHHZ1AUVb4ZH6Q2VY55L3V3gCCSmr
0100000001cf707398596a9f8bf45e22e3f736b819f27ba6d10cb9c12f1ca23a9daf0c6f1d020000008a47304402203ff6f44811c8d772f16535a3482fcb88e0b992cf3f8574b78b32489146212a28022045e2fff119b1124035849f3d54b5f5fa3cf8ebf88463df38df1ee7f4ab4cf358014104dc22a7249282ba829c4351cd9255690aaaa9a9896bd9b95e6075d5a3ec34b305a6eab56f9524f7a4308f418bd4a6eabdaf887a4622874b32cb4f4f55c28e1092ffffffff0120a10700000000001976a9143a572d6755022d568f7a78d0060234920486cd0f88ac00000000
Paid 0.005 to 16KUdKHHZ1AUVb4ZH6Q2VY55L3V3gCCSmr
$ python bitpaint.py -x 1KbDEaZ99YJYaT62emhFwabFoqQ6LYdJg9 -y 16KUdKHHZ1AUVb4ZH6Q2VY55L3V3gCCSmr
0100000001cf707398596a9f8bf45e22e3f736b819f27ba6d10cb9c12f1ca23a9daf0c6f1d030000008c493046022100b440c8997b43067a2a96ece768487e6f219391491d83b384fe7408f106adea5b022100b7d47531358afdeb75cd4e98753309c175ce71e1d722ab851c363c0b9f80d2b50141043d0c63308cb4dcc98b966922a7f78435d44c89b63bf94485f0920c3434a5077c4004adb067ac319f3ee1b551b451a11154e0e1a8ba1c686d15bde93f89963044ffffffff0160ec5300000000001976a9143a572d6755022d568f7a78d0060234920486cd0f88ac00000000
Paid 0.055 to 16KUdKHHZ1AUVb4ZH6Q2VY55L3V3gCCSmr

12. The result of each command in the former step is a hex-encoded raw transaction. It contains a transaction fee of 0.005, to help it get mined into a block. The hex-encoded raw transaction can be broadcast on the network using http://blockchain.info/pushtx. Your client should see the transaction within seconds.

Planned features:
- GUI
- Option to add transaction fee on asset transfers (it is very annoying when transactions never confirm)
- Compatibility with the other approaches

Please be cautious when using it, but feel free to criticise, modify and contribute. And if you like it, support it: 1GsnaaAWYMb7yPwBQ19bSLLMTtsfSyjqg3.

Will your coloured coins work with this 'coloured coin stock market project' - https://bitcointalk.org/index.php?topic=118672.0