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

[jtimon]

I've to admit that I haven't Mike's decentralized solution in detail yet, but I don't see where the potential problems are.
There was a simple program for "p2p trading" called dark exchange that actually lacked an atomic trade method. I've been assuming that the rest would be simple all along.

What are the potential problems?

Also, what's the problem with bots?

1. How do we define a new color, what constitutes a definition?

Each issuing address represents a color.

2. Do we need to embed some meta-information into blockchain itself or side-channel works fine?

I don't think it's necessary. Outside the chain, you mark your assets like...
Signed with pk1("these 200 satoshis that I move from pk1 at block X, represent 200 units of asset Y").

3. Do we need to 'tag' colored outputs in blockchain itself or is "order-based coloring" (or some other method) enough?

I think it is enough.
I don't like needing underlying satoshis, we could just allow people to issue assets without this limitation provided that they pay the fees in bitcoin. This way, outputs without the corresponding inputs would be allowed, just not counted as real bitcoins. For simplicity (or maybe I'm too lazy to think the complex cases), these newly issued assets would probably be better implemented with some tagging.

5. What if we have more than one "coloring algorithms", how would they interact?

Hard to tell. We should probably discuss it for as long as necessary to avoid having competing schemes (not competing software).
There's probably a best solution or an infinite set of perfectly equivalent best solutions.
No advantage for having multiple "colored coins languages" comes to mind.

[jgarzik]

Also, what's the problem with bots?

Bots play all sorts of games with flashing various bids and asks, then cancelling them.  Trying to trigger other bots or traders to make a trade, or change the bid/ask spread etc.  On mainline exchanges (NASDAQ, etc.) bots have been reported to intentionally flood the channel to lock out other players.  In bitcoin-land, DDoS is a sadly familiar tactic.  Lastly, you need to make sure a bunch of bots doing HFT don't suddenly dump gigabytes of data into the blockchain.

There is nothing fundamentally wrong with bots.  Well behaved bots that are moderate-to-low traffic are just fine.

[yoniassia]

Also, what's the problem with bots?

Bots play all sorts of games with flashing various bids and asks, then cancelling them.  Trying to trigger other bots or traders to make a trade, or change the bid/ask spread etc.  On mainline exchanges (NASDAQ, etc.) bots have been reported to intentionally flood the channel to lock out other players.  In bitcoin-land, DDoS is a sadly familiar tactic.  Lastly, you need to make sure a bunch of bots doing HFT don't suddenly dump gigabytes of data into the blockchain.

There is nothing fundamentally wrong with bots.  Well behaved bots that are moderate-to-low traffic are just fine.

Assuming most services for colored bitcoins will be able to see all the transaction prices of that color in the last block, and since all the trades are transparent, it will make any "bad" bots public very fast, and people holding those colors will not transact with them.

[yoniassia]

There's so many threads and related topics to this stuff.

It is really fascinating and a huge step in the right direction IMO.

I want to throw a bounty out there for 2 BTC. Feel free to link to this post.

What is the bounty for? It's for a finalized protocol specification and description
of the entire colored coin and closely related concepts. It can be in the form of a wiki (I personally
prefer a PDF download). In order to claim my bounty, the spec' needs to become the primary
reference.

Those that have run off and started coding already are doing a great service of
verifying the concept in computer programming language, but at the same time are putting
the cart before the horse if they don't take the time to "hash" out the overall protocol
specification IMO.

Thanks to all your efforts.

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

[Red Emerald]

I'm starting to like the idea of this even more. This is definitely the best use of "coin taint" I've seen.

[killerstorm]

I've to admit that I haven't Mike's decentralized solution in detail yet, but I don't see where the potential problems are.

There was a simple program for "p2p trading" called dark exchange that actually lacked an atomic trade method. I've been assuming that the rest would be simple all along.

Certainly it's not a problem to implement a simple version but there are many design options which can significantly affect characteristics.

Also, what's the problem with bots?

High frequency trading requires fast response, i.e. you see an opportunity for arbitrage and you need to execute trade quickly, before market moves. With p2p trading it's hard to make sure that trades would be quick because it depends on your conter-party and on non-quite-reliable networking.

With slow and unreliable trade it's much more likely that bot will lose considerable amount money, so you have higher risks. So at some point certain types of bots become unpractical.

So it is not a problem but rather a potential feature: with faster trading bots will feel more comfortable.

Each issuing address represents a color.

Address can be used as an identifier, but color definition should include information about number of tokens issued (in most cases you do not want uncontrolled issuance), display name, identifier of corresponding contract etc.

I don't think it's necessary. Outside the chain, you mark your assets like...
Signed with pk1("these 200 satoshis that I move from pk1 at block X, represent 200 units of asset Y").

What if previously they represented something else, do they represent both these things now?

You can see a discussion about multi-colored coins here: https://bitcointalk.org/index.php?topic=106449.msg1266454#msg1266454

[cunicula]

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.

[killerstorm]

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

There is no straightforward way to do that, but perhaps CP-ABE might be relevant: https://bitcointalk.org/index.php?topic=92421.0

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

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)

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

[cunicula]

Okay, my interest is really in this problem:

https://bitcointalk.org/index.php?topic=115797.msg1266743#msg1266743

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

[chrisrico]

There's so many threads and related topics to this stuff.

It is really fascinating and a huge step in the right direction IMO.

I want to throw a bounty out there for 2 BTC. Feel free to link to this post.

What is the bounty for? It's for a finalized protocol specification and description
of the entire colored coin and closely related concepts. It can be in the form of a wiki (I personally
prefer a PDF download). In order to claim my bounty, the spec' needs to become the primary
reference.

Those that have run off and started coding already are doing a great service of
verifying the concept in computer programming language, but at the same time are putting
the cart before the horse if they don't take the time to "hash" out the overall protocol
specification IMO.

Thanks to all your efforts.

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

Why not use Booster.io instead?

https://booster.io/

[jtimon]

Each issuing address represents a color.

Address can be used as an identifier, but color definition should include information about number of tokens issued (in most cases you do not want uncontrolled issuance), display name, identifier of corresponding contract etc.

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.

I don't think it's necessary. Outside the chain, you mark your assets like...
Signed with pk1("these 200 satoshis that I move from pk1 at block X, represent 200 units of asset Y").

What if previously they represented something else, do they represent both these things now?

You can see a discussion about multi-colored coins here: https://bitcointalk.org/index.php?topic=106449.msg1266454#msg1266454

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.

[jl2012]

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.

 

[jtimon]

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.

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

[kangasbros]

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.

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

[jtimon]

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.

[killerstorm]

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?

[killerstorm]

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.

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.

[kangasbros]

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?

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 

[killerstorm]

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.

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

[jgarzik]

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.

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