ChromaWallet (colored coins): issue and trade private currencies/stocks/bonds/..

[jgarzik]

All messages should be signed by the private key of associated bitcoin addresses and/or GPG.

Not sure if it's possible with the concrete public crypto algorithm that bitcoin uses. But messages could be encrypted with the destination public key to ensure he's the only one who can read it. If it's possible I think reusing bitcoin keypairs is the best option.

Bitcoin uses ECDSA for keypairs, and this is not an encryption scheme.  Just a digital signature scheme.

The bitcoin blockdata data and protocol do not use any encryption at all.  The bitcoin client uses AES for wallet encryption, but this is not required by the bitcoin protocol.

[1715539923]

1715539923

[1715539923]

1715539923

[jtimon]

Bitcoin uses ECDSA for keypairs, and this is not an encryption scheme.  Just a digital signature scheme.

That was my fear, I knew not all the algorithms make it all (some signatures, some encryption and some both if I remember it correctly).
I studied all these things but, honestly, I forgot the internals of the cryptographic algorithms very fast. I saw some mathematical proofs that made me believe and was glad that didn't had to memorize them. Crypto-analysts must be like math semi-gods or something.
Understanding what they can do from outside is enough for me.
I could have searched for this one, thanks for the clarification.

[killerstorm]

Bitcoin uses ECDSA for keypairs, and this is not an encryption scheme.  Just a digital signature scheme.

In theory it is possible to use same key for ECDSA and for ECDH, and ECDH can be used for encryption:

http://stackoverflow.com/questions/4969570/is-there-a-difference-between-ecdh-and-ecdsa-keys

I'm not sure that particular version of ECDSA used in Bitcoin allows that, though.

[jl2012]

Bitcoin uses ECDSA for keypairs, and this is not an encryption scheme.  Just a digital signature scheme.

In theory it is possible to use same key for ECDSA and for ECDH, and ECDH can be used for encryption:

http://stackoverflow.com/questions/4969570/is-there-a-difference-between-ecdh-and-ecdsa-keys

I'm not sure that particular version of ECDSA used in Bitcoin allows that, though.

I don't think the colored coin trading system requires any message encryption. Those orders and announcements should be public. If encryption is required, people can simply use GPG

[jtimon]

Those orders and announcements should be public. If encryption is required, people can simply use GPG

I just thought that using the same keypair for both things would be cooler (whatever that means in this context), but, yes, we could simply use GPG, no big deal. And as you say many use cases don't require encryption at all.

[killerstorm]

Updates:

I've made an Armory-based implementation. Basically, it's Bitcoin Armory with a drop-down list which allows one to choose color. If you choose color, balance is displayed for that color and you can send coins of that color only.

It kinda works, but isn't well-tested and isn't complete. Particularly, you cannot change scale for colored coins, you cannot pay fees with uncolored coins when you send colored coins, color definition format will likely be changed. There is no exchange functionality.

I don't think it is software for end-users yet, more like a preview for developers and advanced users.

Color definition file format ("ini file"), it is LIKELY to change:

1. "genesis" style mentions tx outputs:

[c26166c7a387b85eca0adbb86811a9d122a5d96605627ad4125f17f6ddcbf89b]
name=test0
style=genesis
number_of_issues=1
i_txhash_1=c26166c7a387b85eca0adbb86811a9d122a5d96605627ad4125f17f6ddcbf89b
i_outidx_1=0


2. "exodus" style mentions address:

[c26166c7a387b85eca0adbb86811a9d122a5d96605627ad4125f17f6ddcbf89b]
name=test0
style=exodus
addrhash=a8e05f6d028daa9e3d6882fa08bf7a4e47396498

Hashes are in format which is used on blockchain.info (block explorer too?), so you can look up some transaction or address there and add its hash into color definition.

Client will pick them if you make file with name which ends with .colordef (e.g. test0.colordef) and put into ~/.armory/colordefs/ ( %appdata%\Armory\colordefs\ on Windows).

If there are no colordefs it loads internal TESTcc color definition which is equivalent to one mentioned above.

There is a Windows build, but I don't want to spread stale versions, so PM me if you want to try.

[killerstorm]

I'm working on a basic specification. It is currently incomplete, but if you want a preview: https://github.com/killerstorm/colored-coin-tools/blob/master/colors.md

My plans:

• implement missing features in Armory colored coin client
• make a better color definition format
• basic specification
• exchange

All interested parties are welcome to join discussion. There is a mailing list now: http://groups.google.com/group/bitcoinx

[matthewh3]

Would it be possible to have a Electrum version of this or does it need the full blockchain?

[Mushroomized]

Would it be possible to have a Electrum version of this or does it need the full blockchain?

I don't see why you would need the full blockchain. And besides, I'm pretty sure electrum uses the whole blockchain, but its just hosted on other servers you connect to.

[matthewh3]

Having to download the full blockchain to verify your coloured coins will hinder its adoption.  Many people are now using thin-clients rather than full blown desktop PC's now.  Having an Electrum version or even a hack of blockchain.info/wallet would be good.

[Jutarul]

Having to download the full blockchain to verify your coloured coins will hinder its adoption.  Many people are now using thin-clients rather than full blown desktop PC's now.  Having an Electrum version or even a hack of blockchain.info/wallet would be good.

At this stage the issue is not adoption but proof of concept. Once the approach is rock solid, the next issue can be convenience.

[killerstorm]

Would it be possible to have a Electrum version of this or does it need the full blockchain?

It is possible.

Actually some people are currently working on color-aware bitcoinJS server. It can give us something like color-aware block explorer (which would show colors for transaction outputs) and a thin client.

It is possible to make thin client without server-side coloring support, but it's impractical now.

[Mushroomized]

One quick note, (Not sure if this has been thought of yet, or if I am missing the point on a larger scale)

For colored bitcoins...

Lets say I own the address 1DD6eE8d19j5gUJTzEPMvFsvDLsRaedhME , and make a bot so that every coin you send to it is bounced back to you. The coins are now referenced as once being a part of this address

Couldn't I just use the block chain to check if coins I owned have been passed through that address, making them "colored"? Of course you could simplify this with some work on the client to check...

Am I missing something :/

[killerstorm]

I'm not sure what's the question here: yes, we use blockchain to check whether coins come from a certain "coloring" address or a genesis transaction, this is how it works.

But note that we likely need this "background check" for all coins which come to us, so this might be a performance problem.

Armory client does full blockchain scan at start to identify all colored coins, after that scan it is fast (O(1) w.r.t. blockchain size).

Other approaches are possible.

[Red Emerald]

One quick note, (Not sure if this has been thought of yet, or if I am missing the point on a larger scale)

For colored bitcoins...

Lets say I own the address 1DD6eE8d19j5gUJTzEPMvFsvDLsRaedhME , and make a bot so that every coin you send to it is bounced back to you. The coins are now referenced as once being a part of this address

Couldn't I just use the block chain to check if coins I owned have been passed through that address, making them "colored"? Of course you could simplify this with some work on the client to check...

Am I missing something :/

You are missing something.

It isn't being referenced by an address that makes something colored.  It's being referenced by a specific transaction.

In Bitcoin, you trace can trace a transaction all the way back to it's generation as block reward.  Colored bitcoins use this same principle, but rather than tracing the transaction to it's original block, they trace it back to its coloring transaction.

The fact that one of your addresses owns colored bitcoins has no effect on the color of coins you send unless you send the actual colored coins somewhere.

Your hypothetical bot would taint the coins (taint like on blockchain.info), but this is not the same as coloring.  Taint is tracking links between addresses and coloring is tracking the specific coins.

[Mushroomized]

One quick note, (Not sure if this has been thought of yet, or if I am missing the point on a larger scale)

For colored bitcoins...

Lets say I own the address 1DD6eE8d19j5gUJTzEPMvFsvDLsRaedhME , and make a bot so that every coin you send to it is bounced back to you. The coins are now referenced as once being a part of this address

Couldn't I just use the block chain to check if coins I owned have been passed through that address, making them "colored"? Of course you could simplify this with some work on the client to check...

Am I missing something :/

You are missing something.

It isn't being referenced by an address that makes something colored.  It's being referenced by a specific transaction.

In Bitcoin, you trace can trace a transaction all the way back to it's generation as block reward.  Colored bitcoins use this same principle, but rather than tracing the transaction to it's original block, they trace it back to its coloring transaction.

The fact that one of your addresses owns colored bitcoins has no effect on the color of coins you send unless you send the actual colored coins somewhere.

Your hypothetical bot would taint the coins (taint like on blockchain.info), but this is not the same as coloring.  Taint is tracking links between addresses and coloring is tracking the specific coins.

Thank you two for the explanation, I understand now

[yoniassia]

Having to download the full blockchain to verify your coloured coins will hinder its adoption.  Many people are now using thin-clients rather than full blown desktop PC's now.  Having an Electrum version or even a hack of blockchain.info/wallet would be good.

Will be more than happy to donate for someone to adapt Electrum client to colored bitcoin, it is a great addition .

[Mushroomized]

Having to download the full blockchain to verify your coloured coins will hinder its adoption.  Many people are now using thin-clients rather than full blown desktop PC's now.  Having an Electrum version or even a hack of blockchain.info/wallet would be good.

Will be more than happy to donate for someone to adapt Electrum client to colored bitcoin, it is a great addition .

Electrum would still work, it uses the full blockchain, just connecting to it remotely correct? (that's why people run electrum servers?)

[killerstorm]

Electrum would still work, it uses the full blockchain, just connecting to it remotely correct? (that's why people run electrum servers?)

Yes, but I guess server needs to be extended too, because right now it offers very limited access to blockchain data.

[dacoinminster]

I just found this thread, and I am so ridiculously excited. For years I have been telling everyone that this sort of additional structure built on top of bitcoins is going to be what makes bitcoin really take off.

KillerStorm: Please PLEASE take a look at the whitepaper I wrote on this topic a few months ago: https://sites.google.com/site/2ndbtcwpaper/2ndBitcoinWhitepaper.pdf

I'm not saying you should implement what I describe there, but in that paper I describe solutions to several of the problems you are facing, such as how to handle distributed buying and selling of colored coins without modifying the bitcoin protocol.

Thanks for doing this; you can bet I'll be watching closely now that I know someone is actually writing code for this. I would be coding it myself if I could find the time.