Topic: Blockchain security tracking/colored coins/smart contracts - short python script - page 2. (Read 8869 times)

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.

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 ??

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.

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!)?

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.

Yes that was my idea to recommend use of a separate blockchain.info/wallet to asset holders as they do automatic backups to your email, Google drive or dropbox.  I understand other online wallets can't be used as they mix your coins.

Given current bitcoin software, it is strongly advisable to keep separate wallets for smartcoins (colored coins) and regular bitcoins.  Mix the two at your peril; it is too easy to "spend away" an asset as regular bitcoins, with a single wallet.

I've also put a bounty up in this thread and the other thread - https://bitcointalksearch.org/topic/m.1270041

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.

There's a bounty available:
https://bitcointalksearch.org/topic/m.1269388

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.

PS. Thank you for using 'sendmany'  It helps keep blockchain bloat to a minimum.

I'd like to thank the big brains for weighing in here in this thread.

With the script now working "as I originally had in mind", I am now very keen on making improving the script and making it compatible with the approaches discussed by the venerable mr. killerstorm and sir jgarzik. However, there are so many long threads at this point that I don't have time to dig 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?

But first, I would like to invite matthewh3 - as the only "asset issuer" that has weighed in so far - to describe a little more in detail what features he is looking for.

Update: I've been reading up on the discussion ,and it seems that the consensus is something like this: https://bitcointalksearch.org/topic/m.1203918, so I intend to try following those rules (until problems start surfacing).

Update

A new version of the script has been posted, and OP has been updated with a usage example that showcases the current capabilities of the program.

The main new feature is the possibility to pay dividends from your wallet to the holders of colored coins.

Enjoy!

I think a better version of rule 4 should be: If the colored coin transfer does not follow the Colored Coin Rules(tm), the last owner retains the extra value of the colored coin. (i.e. the last owner will still receive dividend etc.) However, that person may no longer transfer the extra value to other owners. The issuer may re-issue a new colored coin to the last owner to replace the burnt one, with or without service fee charged.

This will prevent most "money burning accident".

The most important concept to remember is that colored coins are like rules of the road:  they only work because everybody agrees on what side of the road to drive.  There is no law of physics preventing cars from driving in the opposing lane of traffic.  There is no software rule preventing you from using your colored coins to buy Alpaca socks at a web shop.

The basic process works like this:

1. Publicly declare a list of coins in the existing blockchain as colored.
2. Transfer the colored coins to their new owners.  These new owners may freely transfer them to other owners.
3. If the colored coin transfer follows the Colored Coin Rules(tm), software may search the blockchain, and precisely identify the list of colored coin holders.
4. If the colored coin transfer does not follow the Colored Coin Rules(tm), then that person is essentially "burning the money", by making it impossible to track the colored coin beyond a certain point.

It is up to each colored coin owner to keep track of their own public keys.  All other information is stored in the public blockchain.

As I'm looking at issuing coloured coins based on the ownership of over $4,000 of ASIC's how do I prove ownership of the issued coloured coins permanently taking into account of hardware failures.

There is only one blockchain, the public blockchain.

Let me try to draw an analogy:

Every US dollar has a serial number on it.  The US dollar version of colored coins would be analogous to: "the holder of $20 bill with serial number ABCD1234 owns Chevrolet Corvette VIN 137YA9031WE239523"

Colored coins says "bitcoin ABCD1234", whatever its value, is somehow more special than regular bitcoins.

This requires special software for the bond issuer and the bond holder, both, that recognizes bitcoin ABCD1234 as special.  This is simply an agreement enforced (or not) by running special software.

The bond issuer runs software that searches for the current public key holding ABCD1234, and pays dividends to that public key.  The bond issuer does not know or care who is the owner.

The bond holder runs software that stores ABCD1234 in a special wallet, separate from other bitcoin wallets.  This guarantees that the bond holder does not accidentally spend their "special" coin accidentally -- analogous to accidentally giving a rare coin to a vending machine for soda.

Cool, sounds complex but I'm sure it could be built into the new altered wallet and made simple enough.

Another question while I'm still trying to grasp the concept.  The initial creation of the coloured coins is stored in the blockchain of the wallet that created them.  Is it very important the record of this genesis creation/transaction of the coloured coin is kept?  If so how does this individual colour marked blockchain be distributed?  Or does each wallet just keep its own new colour marked blockchain from receipt of the coloured coins to prove ownership?

Yes.  The issuer may determine what public key currently controls a colored coin.  That is the only information present in the public blockchain data.

It is obvious that voting is possible:  a colored coin holder may use the 'signmessage' feature to sign any arbitrary text using their bitcoin ECDSA keys.

Let us assume that a colored coin has been sent to bitcoin address 1ABCD1234ABCD1234.

1. A public notice of voting is posted , of a vote.  This notice includes a sample ballot, a simple text message format.
2. The owner of 1ABCD1234ABCD1234 downloads the sample ballot, edits it to reflect their vote, and then uses the 'signmessage' RPC to add a cryptographic signature.
3. The owner of 1ABCD1234ABCD1234 emails the signed ballot to [email protected], or maybe, [email protected].
4. The bond issuer, or 3rd party vote tabulation service, looks at the blockchain to verify that the email just received is signed by the holder of public key 1ABCD1234ABCD1234, and that 1ABCD1234ABCD1234 does indeed still control the colored coin.

Yes. Owners of colored coins can sign messages with private keys corresponding to addresses which hold colored coins.

issuer, or perhaps some third party, would then collect these messages and check that they indeed come from owners of coins, i.e. shareholders.

People might post these signed messages on forum to make voting public.