And, by the way, it's worth noting that we were aware of MasterCoin when we were designing colored coins. (Quite possible it was an inspiration, but I'm not sure.)

I've considered both proposals about a year ago, and found that colored coins are much simpler, and thus it is easier to make a robust, mature implementations.

Then we deliberately designed colored coins in such a way that it would be possible to make efficient, thin clients which won't need to scan whole chain.

Situation is still worse than with Bitcoin SPV thin clients (which need very little data to operate), but there is some room for optimization and trade-off...

Otherwise, making it similar to Bitcoin SPV would require support on protocol layer. I.e. an alt-coin with explicit colored coin support.

Colored coins allow one to create tokens which represent ownership of something, like shares, bonds, currencies, derivatives etc. Basically, whatever you want to have tradeable.

Then there is a way to trade them in a secure fashion, which opens up a possibility of decentralized, peer-to-peer trade.

There will be probably some features which are useful for stocks and bonds: paying dividends, motions, etc.

One can implement futures and prediction markets using colored coins, but there are no features specifically for that, it is up to issuer to guarantee proper settlement.

There are also some advanced features which can be used to implement currencies with demurrage, built-in taxation, etc, but it is largely theoretic now.

And that's pretty much it. MasterCoin features which require non-local interactions (i.e. transaction affects state of objects not linked to it) are not possible within colored coin model. This includes things special savings addresses, bets, and stabilized user currencies.

(Note that you might be able to implement features like that via advanced features of Bitcoin (multi-signature scripts, contracts) unrelated to colored coins. )

So, to summarize, with colored coins we deliberately avoid features which require non-local interactions. This makes things simpler.

Colored coin transactions are Bitcoin transaction, and they behave in exactly the same way. You wait confirmations in the same way as you do with normal Bitcoin payments. They are not sensitive to ordering. Double-spending is prevented by Bitcoin nodes.

This means that in comparison to MasterCoin, colored coins are:

• simpler and more reliable: colored coin kernel function is just ~15 lines of code, we only need to code review it to make sure that it works properly
• has well-understood properties which are based on Bitcoin properties: no need to wait a lot of confirmations to guarantee that transfer happened
• client needs to scan transaction history of one specific color to be able to receive it. This allows secure thin clients similar to SPV Bitcoin clients (although potentially such clients need to download much more data than Bitcoin thin clients). In contrast, to be able to work with MasterCoin you need to scan the whole Bitcoin blockchain, so thin clients will have to trust some server
• colored coins do not liter Bitcoin blockchain with unspendable UTXOs: all UTXOs which are used to represent colored coins are spendable and can (and should!) be eventually reclaimed

However, lack of non-local interactions means that we need more facilities outside of blockchain, i.e. decentralized trading requires separate communication and policies. (On the bright side, we do not liter the blockchain with offers and such, only with complete transactions.)

I also expect that off-chain trading will be used together with colored coins: i.e. trading will happen within a centralized service of some sort (potentially, Open Transactions) and colored coin transaction will be used only to settle the balance periodically.

It can be more-or-less secure as it is possible to use Bitcoin features such as multi-signature scripts and contracts together with colored coins.

Oh, and you cannot invest into colored coins in general: it is open source software, not a currency. You might be able to invest into a company which develops colored coin software, though.

HTH

Yes, this is why it is said that it is a protocol layer above Bitcoin: Bitcoin is used as a transport layer.


1. It is not possible to implement Simplified Payment Verification: you need to process whole blockchain to process transactions correctly. Thus thin clients have to trust server to report correct balance. Thin clients cannot check whether payments were, indeed, correct.

2. Double-spending is "easier", thus you need more confirmations. When it is reasonable to accept Bitcoin tx after 1-2 confirmations, you need 3-4 for same degree of certainty with Mastercoin.

These special transactions Mastercoin uses get into blockchain too, and so all nodes can agree on their order.

If you try to spend more than you have, the second transaction will be considered invalid, as if it didn't exist.

So to do the Mastercoin thing you have to scan blockchain sequentially and update state whenever you see special transactions.

By the way, people, this ArmoryX thing is outdated: basically, Bitcoin Armory just isn't a good platform.

We are working on "next-generation colored coin client" which will work without Armory. It will be available in about a month:

https://github.com/bitcoinx/colored-coin-tools/wiki/The-next-gen-colored-coin-client

Currently there is a very basic tech demo in Python: https://github.com/bitcoinx/ccoin-agent-py

Also we are working on WebcoinX web client: http://bitcoinx.github.io/webcoinx/

No, it doesn't take into account that value of DMS.SELLING drops after each divident.

Realistically, DMS.SELLING ROI might be around 10% over its lifetime... Definitely not more than 20%.

You might get higher ROI if you reinvest dividends back into DMS.SELLING, but, obviously, this makes risk higher.

Well, the idea is that if tasks are available for grabs, other people can grab them.

Particularly, as I mentioned I'm interested in colored coin part because I'm already working on a library works with colored coins.

Here's one in Python: https://github.com/bitcoinx/ccoin-agent-py (incomplete), but I think it's worth doing another one in C++ for this project.

Thanks, this is great!

It would be cool if you also display relative price difference for each security in this index.

For example, currently it is down: -4.61%, but to see what happened I need to go to btct.co, and as it uses different time reference, it isn't easy to see how change is explained.

The way I see it, people will first get interested in a particular asset, and only then would want to add it to their wallet.

So we'll start from two simple ways to add asset definitions:

1. Via URL. E.g. if company Foo sells its stock, they will simply give you a link like https://foo.com/asset.definition, you client will fetch and install it.

2. From a asset definition directory: This basically mimics exchanges like btct which list certain assets after verification. We'll have something like 'Color Rating Agencies' which will select assets of their choice and put their signature on it. Then you just point your client to CRA's directory URL and can select assets from there.

What we have now is basically like that, except that you have one pre-defined directory, and there is no selection.

I think later we can think of more mechanisms, but now there is no needed for it.

Well, yes... You'll need it to run on servers you can trust. Otherwise server can make it look like you received a payment when you didn't.

Going further, I really don't see why you would want to bloat Bitcoin blockchain with data... Basically, you just need to timestamp messages, and there is much less wasteful way to do it.

E.g. you can put all these data-transactions into a Merkle tree and timestamp only root of that Merkle tree. Or you can use a merged-mined alt-chain.

Let's summarize You use Bitcoin for two things: secure timestamp via proof-of-work, and storage of data. Storage of data is expensive.

Thus you can drastically reduce costs if you store data elsewhere.

Actually it is possible...

Suppose there is a trading system which facilitates trading of three distinct kinds of asset: money, e-gold and e-gold-gen. (E-gold-gen is a weird e-gold derivative.)

There are separate order books for e-gold and for e-gold-gen, however, there is one peculiarity in this system: it can match e-gold  bids with e-gold-gen asks, and e-gold asks with e-gold-gen bids under some conditions.

As long as e-gold price is around target price, no cross-matching is done, i.e. e-gold bids are only matches with e-gold asks.

Now suppose e-gold price is below the target price. When person tries to sell e-gold below target price, his ask is matched with e-gold-gen bid.

If X is e-gold ask price and Y is e-gold-gen bid price, then one unit of e-gold creates X/Y units of e-gold-gen.

I.e. we reduce supply of e-gold and increase supply of e-gold-gen. As people sell more and more e-gold it eats through e-gold-gen orderbook, and more and more e-gold-gen is created. (Lower the price of e-gold-gen, more of it is created per unit of e-gold.)

Obviously, this works as long as there is a demand for e-gold-gen. If this is an economic abstraction, there are always people who want to buy at very low price, so it always works.

In reality, at some point people will stop buying e-gold-gen no matter what's the price, so whole system will collapse at that point.

(I.e. if you approach it with supply/demand curves it works, but if you assume that demand is finite it doesn't.)

Now if price of e-gold is above the target, it works in different direction: e-gold bids are matched with e-gold-gen asks, and again you need X/Y units of e-gold-gen to create one unit of gold. If there is a lot of extra demand, it will eat through e-gold-gen asks, price of e-gold-gen will get higher and higher, and one unit of e-gold-gen will create more units of e-gold.

I see a problem: protocol only works for a client which scans whole blockchain.

Secure thin clients (similar to SPV clients like Electrum, MultiBit) are fundamentally impossible.

And running full node client like Bitcoin-Qt will soon be very challenging,

Thanks!

Block explorer now points to our own block explorer, which is up-to-date.

Thanks, I've sent you 0.05 BTC.

I haven't seen a problem with multiplying coins before, gotta investigate it.

Just to clarify: were you sending coins between different addresses of same wallet?

Or made multiple wallets (e.g. by opening in different browsers or in incognito window) and sent between different browsers?

THIS DEMO IS NO LONGER AVAILABLE

The current version is just a demo: it works on Bitcoin testnet and is not secure. But it isn't just a mock-up: it actually uses blockchain, traverses transaction graph to identify colors, etc.

Basically, to make a client which can be used on mainnet out of it we need to add some crypto checks and optimize the way it works with blockchain.

So, here's a link to client: http://bitcoinx.github.io/webcoinx/

Notes on usage:

1. Colored coins are made of Bitcoins, so you need to have some in your wallet before you can issue your own coins.
2. The way it works now, you have to select currency you want in the drop-down menu BEFORE you choose what to do with it (send, trade, receive).
3. If color was created after you loaded the client, you need to reload page (or use 'reload / sync' button) to see it in drop-down.

Also note that p2ptrade section is ugly and not well tested... But, probably, it works.

I'll pay 0.05 BTC per usability report, for the first 10 reports. To claim bounty you need to reply to this with following:

1. How would you rate ease of use, 1 to 10 (10 is best)?
2. Which features did you try? Did they work?
3. Did you encounter any problems?
4. What things would you change and how?
5. Any comments you want to include which do not fit in categories above.
6. Your Bitcoin address.

I plan to redesign user interface, making separate tabs: receive/send/issue/trade. I want to measure the baseline now to see whether there are improvements.

Testing instructions: You need more than one wallet to test sending and trading.

You can create mulitple wallets if you open it in different browsers (e.g. in Chrome and in Firefox), or one in normal window and another in incognito window.

(Wallet is stored in local storage so it is persisted as long as you do not clear storage. Incognito mode destroys local storage after you close window, so wallet won't be persisted.)

The solution is to create more uses for DVC. Right now it has to compete with dozens of cryptocurrencies and offers no advantages whatsoever, so it is silly for investors to buy it.

In my experience it is hard to find highly skilled developers who have some spare time. (For Bitcoin projects... My theory is that everybody is hiring so this completely depleted the pool of available devs.)

Usually developers want a concrete payout model like "do this, get 10 BTC", as it matches per-hour wage they are used to. I.e. they know what a hour of their time is worth, they estimate how long it takes to complete a task, and can thus know whether it is a good deal or not.

If you introduce a risk of non-payment (e.g. if two devs work do same job only one gets paid), you need to compensate for it by higher payoff.

Also you need to take into account developer psychology. It is a very complex topic, but the general idea is that developers are more likely to take small tasks which they are prepared for.

Also they care about awesomeness, good cause, prestige etc.

Say, if something takes 1 hour of time and involves only tech I know, I will take risk, and even accept discounted payment if it is cool and everything.

So I think prediction market might work if you break whole thing into small tasks.

But this is very problematic:

• very few developers know all required tech, and preparation takes a lot of time
• designing the solution takes time
• it is very hard to break the whole thing into smaller pieces, basically to do this you need to design the architecture in all details
• when people care only about completion of a certain task they are more likely to commit bad code, or do not take into account the big picture

We've been trying to develop colored coins using bounty model for 6 months or so, and it wasn't effective. I'm now using a different approach for BitContracts.org: we have a team, of sorts. While individual team members get bounties, the difference is that they work continuously on many tasks, so preparation is less of an issue (you prepare only once), they are interested in long-term success and so on.

I haven't tried it, but what might work is hackathon-style events. It is easier for a programmer psychologically: if it is possible to find, say, 24h to work on this project, programmer can just commit to work on it, and have no worries about distractions and such.

Also hackathon might be perceived as a fun time, risk is bounded, so programmers will be more likely to do this.

Also it would help a lot if people who have more experience or have better vision will be available through the event to give advice. It happens very often that programmer is stuck on what appears to be trivial, and availability of an expert can drastically speed up the development and reduce complexity.

Deprived is a user on this forum, he runs LTC-ATF fund, and appears to be highly competent person, so people trust his opinion. They want his comment on smidge.com.

What's the status of Bitcoin integration/colored coin integration?

ciyam open says it is "Coding - Pending" for both, but I have no idea what it means.

If nobody started coding yet it probably makes sense to give these tasks to me / BitContracts.org team.

Since we already started implementing colored coin library in C++, it should work nicely with this project.