If txn fee is paid with colored coins those colored coins are lost. It might make sense if value per satoshi is ~1 satoshi. I agree it isn't a very useful feature, that's why I haven't implemented it.

There is, however, a better way to pay the fee with colored coins, it is based on same mechanism as p2p exchange. Say, you have only GOLDcoins and what to send them to somebody. To pay a fee you need to find somebody who wants to buy GOLDcoins, then you send them a small amount of GOLDcoins and he sends a fee. All in same transaction.

Essentially it is a slightly more elaborate p2p exchange mechanism.

And while we are here, we can probably implement ripple-style circular exchanges through same p2p exchange mechanism, it just needs to be even more elaborate.

I'll start with simplest one, of course, but maybe I can make some room for more advanced features.

It means that server works

Now open another console window and try communicating with this server, e.g. namecoind getnewaddress

Next goals:

• ZC transaction support (yeah, it doesn't quite work now)
• user interface adaptations for colored coins (e.g. displaying correct units)
• standardization of color definition format, automatic download from bitcoinX server
• p2p exchange
• a tool for making color definitions

My general plan is to implement features first, deal with quirks either. I'll try to finish most of this stuff this week.

Updates:

• fees paid with uncolored coins
• auto-trade

Before this fees were paid with colored coins, which is a major problem for coins which are significantly more valuable than BTC/which are represented with few satoshis.
After a patch fees can be paid with uncolored coins only. Perhaps it makes sense to allow paying fees with colored ones too, but there is no option for it in GUI yet.

Second update is auto-trade script. Basically you can use it to sell colored coins automatically: whenever script detects uncolored coins being sent to your address, it will send back colored coins according to exchange rate you set up. It works like Satoshi Dice, colored coins are sent to address which sent uncolored coins.

(This script is just a proof-of-concept, not an end-user material.)

Both features definitely require more testing. Particularly "uncolored fee" turned out to be rather hairy.

It would be cool if somebody would do code review since testing this stuff is kinda hard. I'm actually willing to pay a bounty for somebody to proof-read my code.

Prerequisites are:

• good understanding of Python
• willingness to work with code you aren't familiar with
• code review skills, i.e. finding bugs simply by reading code attentively

Familiarity of Armory code base is not required as I'm ready to explain whatever is needed to understand code.

Base bounty is 1 BTC. It can be considerably higher if you do a great job, say, rewrite it in such a way that it sucks less.

PM me for details.

Well, colored coins kinda solve mining issue: we just use existing blockchain, assuming that it's already secure.

People need to purchase coins to turn them into asset-representing tokens, and also they need to pay txn fees. That's how miners are compensated.

If we'll have a blockchain specifically for asset ownership tracking (e.g. ripplecoin), we'll have "host coins" which are awarded to miners, while asset issuers have their own tokens which are created as needed. You need to pay hostcoins as a transaction fees, so that's how miners get compensated.


You send coins to yourself, then create a "color definitions" which says what they mean, i.e. it can point to a contract.

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

The right answer is "in blockchain", obviously. That's the only way to make it secure and decentralized.

Think about it: if there was a way to store ownership information without blockchain, we would have cryptocurrencies other than Bitcoin.

There might be a way to secure transactions without proof-of-work, e.g. Ben Laurie's "mintettes": http://www.links.org/files/distributed-currency.pdf

But since we already have PoW-secured Bitcoin, it just makes sense to use same PoW to secure asset transactions. Either via merged mining, or via embedding information right into Bitcoin blockchain.

I'm not sure what you guys are talking about, but colored coins + some simple communication medium + some trading software sounds like a viable approach to me.

By simple communication medium I mean anything like IRC/newsgroups/web chat/mailing list/p2p network... I'm going to start with a specialized web chat, though.

If I finish stuff I'm working on this week, next week I'm going to start with p2p exchange for colored coins, and I hope I'll get it working in a week or so.

Problems you talk about seem to be largely theoretic. If authorities shut down IRC server people can go to trade on newsgroup. There might be some disruption, but it can be repaired  in matter of minutes through software reconfiguration, so I doubt it's same thing as getting "GLBSE'd".

If trade happens both on IRC and on newsgroup, then, liek, post your orders onto both, and read both. Problem solved?

It might be a problem only for high-frequency trading, but since any p2p solution is inherently slow and unreliable, they'd have to live with it. Maybe it is not a problem at all because high-frequency traders compete with other such traders, and if it's slow for everybody, that's fine.

If we are talking about capital markets, it's unlikely that fundamentals change more often than once per day or so. So there is NO NEED in high-speed trading. If you trade faster than your peers you can make money on it, like trading right after news were heard. But it just a race, and if trading system is fast, people will compete for milliseconds or even microseconds. Obviously there is no fundamental difference.

Likewise, there is no real problem with multiple separate markets: you can poll many of them to find the best deal. Even if you don't poll some, we can hope that arbitragers will make sure that there is no large discrepancy isn't large. Again since fundamentals change infrequently whatever "commission" arbitragers get is largely unimportant.

Ichthyo: IIRC I mentioned something like this, without any details, though.

In general I think "If you build it, they will come" might work here: it's important to create an open ownership tracking/trading platform.

And then market will find a way how to use it. Insurance ("credit default swaps") seems to be a viable option.

Also we'll likely see other creative ways to deal with it.

BTW (I don't remember whether I mentioned it) it is possible to make secure multi-issuer Ripple-style currencies with help of collateral: large issuers will hold each others' balls via "legally enforceable" collateral agreements, then smaller fish can connect to it and transfer money via that currency.

This scheme can also allow a registered, legal company to support the currency while minimizing money laundering accusations: it won't issue this currency, but it will insure it in case of default. So normally this company never touches the currency and doesn't facilitate the trade, so it's kinda hard to accuse it. But it kinda helps when users know that currency is backed by hard $$$ and a legal company.

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.

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.

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

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.

That's the whole point of using proof-of-work, right?

A miner who wants to maximize fees paid in block he mines would include fee-paying transaction into a block even if it conflicts with non-final memory pool transaction.

Miner can always pretend that he haven't seen that non-final transaction, you can't know for sure that he violated thus rule intentionally.

So this rule appears pointless, it is neither strictly enforced nor economically motivated.

I think this requires specialized software, doing it manually would be slow and painful.

I have plenty of ideas, but writing them down takes considerable time, and I also need to work on Armory client.

I'll try to write more about it soon. This weekend, maybe.

Middleman is not required, he can be used to speed up trading. We don't know yet whether speed will be a problem for typical user.


Yes, this is probably the easiest way to implement it, but it is not the only way.

I'm not sure whether "transaction update" mechanism can help us in this case, it looks like things which can be updated won't allow one to re-target funds. But maybe I'm missing something...

Anyway, this problem can be solved with a help of a not-very-trusted third party: instead of sending his signature to B, A will send it to a third party C. B will do the same.

C will broadcast complete transaction only when he has both signatures and renegotiation time has expired.

C only needs to be trusted to not favor one of parties.

No reputation is ever required for a party which agrees to sign first because there is no way he can hurt anyone.

On the other hand, the only risk for such party is that trade won't be finalized, which simply means longer execution time.

If you simply buy something to own it doesn't matter much how much you wait, so it would be perfectly fine to fire an order and wait until somebody actually finalizes trade.

Execution time really matters only to daytraders/HFT bots, and they can use reputation system among themselves.


Not really, broker won't ever touch your coins, he can only help to speed up the trade by either finding a match or providing his reputation, for a fee.

You will only sign something only when you see that you're getting something in return. So it is fundamentally secure. But how exactly trade is facilitated doesn't matter much.

As far as I understand, he wants to use Bitcoin blockchain as a medium of transmission for signed, timestamped messages. On Bitcoin protocol level only signatures are checked, but not message contents.

These messages are interpreted with a special client software which will then maintain current state: i.e. who owns what.

I see a number of problems with this approach:

• To compute current state you need full Bitcoin blockchain. It isn't compatible with pruning. Thin clients are not possible.
• It makes rather inefficient of Bitcoin blockchain. It is, of course, possible to do implement signed, timestamped messaging with much lower overhead.
• Since protocol has to deal with concurrency, it will likely end up being rather complex, but still prone to all kinds of race conditions and stuff.

So, frankly, I don't see it as anything more than a curious mis-use of blockchain.

It is interesting to compare it with colored coins, though. Colored coin protocol is more integrated with Bitcoin protocol: colored coin transactions are Bitcoin transaction, and they have to follow Bitcoin conservation rules, but they impose additional rules (conservation of colors).

Thin colored coin client requires more information than thin Bitcoin client: besides basic information about transaction it also needs information to check correctness of coloring. But still, it doesn't need to download full blockchain: only path which goes from genesis to current transaction is required.