Topic: ChromaWallet (colored coins): issue and trade private currencies/stocks/bonds/.. - page 23. (Read 97112 times)

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.

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.

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

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.

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.

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.

That is why smartcoin (formerly pybond) includes client for a brand new P2P "financial network" and a DHT "financial hashmap"    See https://github.com/jgarzik/smartcoin

As I said I have a plan for HTTP-based protocol for this. It's incredibly simple and at start it can be completely centralized.

All networking can be hacked together like in a day or so, hard part is to glue all things together.

So suppose there is a python script which runs a web server which acts as order book server... And client can connect to any such server.

This this server can be integrated into client software itself...

I'm mostly thinking about how to get this thing kicked out now. I'm pretty sure that there will be hundreds of order book services in something like ten years, but that doesn't help much in the present. To get this off the ground ASAP, some semi-centralized solution could be best way, and iterate then from there on.

If nobody else is not going to do it, maybe I am, give me a couple of months 

I think Jeff is working on it, he probably already implemented something.

I'm working on HTTP-based protocol which would scale from centralized to p2p.

There is no need to store money in those centralized services: they just need to provide order book and host some information... No trust required.

Also nothing prevents people for running these order book services, so we'll likely see hundreds of them, so how is this not decentralized?

While I agree that the centralized approach is the best way to start, I don't see any problem in start drafting a p2p design: it's completely feasible.

Nope. I think this line of thinking is a big problem in general in bitcoin community - you don't need to decentralize everything "perfectly". Perfection is the enemy of good enough. Or non-released perfect product is useless.

For starters, I think that for this decentralized exchange to take off, we need a) very simple protocol, built on top of bitcoin block chain, which handles the very basics and b) centralized service, run on tor network, which offers the feature so that they can be easily used. People would use the centralized service, but they would have the opportunity to withdraw their shares from the centralized services to the decentralized protocol level.

Advantages: good business model for the centralized service (fees etc), while still no trust required in the long-term for the centralized service (people can store their shares also in the block chain if they wish).

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.

Does anyone know a p2p communication system where messages are protected this way?

I am not sure if this has been mentioned by someone else. To make the decentralized exchange works, we need a standard peer-to-peer protocol to broadcast all the required information: IPO invitations, definition of assets, ask/bid orders, and cancellation of such orders. It's just like how transactions and blocks broadcasting on the bitcoin network. All messages should be signed by the private key of associated bitcoin addresses and/or GPG. For example, IPO and asset definition should be signed by GPG of issuer, and ask/bid orders should be signed by addresses holding enough bitcoin or colored bitcoin for completing the trade.

The peer-to-peer client should be able to check the validity of ask/bid orders. It should also generate raw transaction based on colored coin trading rules, allow transmission of partially singed transaction among the trading parties, and broadcast the completed transaction to the bitcoin network. It should also work as a bot, which will automatically sign transactions based on user instruction.

The efficiency of such system is a big concern. Some user may post a valid ask/bid order but never complete the transaction. Some user may try to double spend their bitcoins or colored bitcoins. Therefore, we need a peer-to-peer rating system to keep a track record of the traders, based on the bicoin addresses or GPG key used.

 

All this complementary information can be out of the chain.
Remember you can use the issuing key to sign any information you like. As said many times, you could link the key to another certification like eDNI or another private one with digital signature.


Yes, they would represent both things now. But it would be rather stupid to issue assets on top of already colored coins since you won't be able to separate the ownership of the assets anymore. Maybe there's a fancy use case I'm missing, but I would just recommend people not to do this and wouldn't care much about the issue.

I will read that whole thread anyway. I was already subscribed, but thanks.

Why not use Booster.io instead?

https://booster.io/

Okay, my interest is really in this problem:

https://bitcointalksearch.org/topic/m.1266743

Even if you don't find committed savings interesting. I think that multisig txns involving colored coins would turn out to have other uses.

There is no straightforward way to do that, but perhaps CP-ABE might be relevant: https://bitcointalksearch.org/topic/distributed-bond-markets-and-pay-to-policy-outputs-92421

I have no idea whether it's realistic and whether it does what you need.


You do not need to identify color of a coin in script in this case as contract will simply reference a coin A already owns, and we already know its color when contract is created.

E.g. A puts his coin into multisig escrow so that he cannot spend it. Then parties will prepare two transactions: one will send coin back to A if option expires. Another will send coin to B if B provides a payment which goes to A.

You'll need to identify color of a coin in a script if you do a reverse option: an option to buy uncolored bitcoins with colored ones. Since colored coin in question likely doesn't exist at time contract is made, we need to verify its color in script.

This probably can be done using an oracle or 3rd party arbitrator whose signature will prove that coin is indeed colored.

Or maybe it can be done with voodoo magic Mike mentioned...

I have a question about multisig scripting and colored coins.

Is it possible to write scripts that are conditional on color?

i.e. A sells B an option to buy a blue colored coin for one uncolored btc. (say that the option expires in 1000 blocks via nLockTime)

I'm not interested in the details at the moment I just want to know if it is possible.