Colored coins is just a system for tracking ownership of tokens, what these tokens mean is a different matter.

For example, a company can declare that the tokens they have issued represent ownership of stock of that company, and owners of these tokens will receive dividends.

Or somebody might issue tokens which represent ownership of physical gold.

There are many others potential uses... In any case, it is more like a toolkit for ownership tracking, rather than a particular brand of currency.

(Of course, it is also possible to issue tokens which aren't backed by promise of any kind, but just exist like Bitcoin and Mastercoin do.)

I believe that escrow-backed currencies are ill-conceived idea, and we aren't going to implement anything like this on top of colored coins.

Well, you assume that Mastercoin will be perfect.

But what if a copycat will offer features which Mastercoin doesn't have?

Yes, in theory, Mastercoin could copy whatever improvements copycat has. But in practice, it just doesn't work this way.

It is very hard to change a distributed protocol: if you change it in a way which isn't backwards-compatible, you have to do a hard fork, that is, all client software needs to be upgraded.

This is hard to do for a number of reasons:

• you need to modify many different pieces of software
• some of them are no longer maintained
• you need to make sure that all users read the announcement that they need to update their software by a certain date

I believe that because of the way Mastercoin is designed (Mastercoin transactions are not validated by miners; model relies on a global state), pretty much every change is a hard fork. So improving Mastercoin is hard and disruptive.

Add to this that some changes can be controversial... Suppose, you change how escrow-backed currencies work. But people already use them, and they won't like the fact that changes can potentially weaken currencies they own.

Also, don't forget that Mastercoin Foundation will run out of money at some point, but a copycat will get funding from investors.

So, to summarize, copycat can start over and do things the right way using funding it got, while changing Mastercoin is too complex and expensive at that point.

OK, anyway, why would ordinary people choose copycat? It is possible to move all transactions into a side-chain and thus avoid all Bitcoin tx fees. So it will have lower tx fees.

It looks like merged mining is game-theoretically sound if we use a simple model, but more complex payoff model shows the difference between authentic PoW and merged mining.

We start with an assumption that there exist a financial market which allows one to profit when a price of a certain currency drops. It can be done through short-selling, or through derivatives like futures and options.

Attacker considers an attack where his actions will create a panic, which results in a price drop. Then he will win a financial bet and get his profit.

Suppose Bitcoin mining equipment cannot be leased in sufficient quantities, this means attacker needs to buy equipment to perform an attack.

He will sell this equipment after an attack, and thus he needs to take into account that if attack was successful, price of this equipment will drop: if Bitcoin mining is competitive, profit margins are small. Drop in price will make mining unprofitable, which means that many miners will try to sell their mining equipment, which will drastically decrease its price.

So attacker's profit is reduced by drop in value of equipment, and it can be negative, which strongly discourages attacks of this sort.

(BTW this also shows that miners shouldn't rent their equipment: if more than 50% is available for rent, they might end up with worthless equipment.)

Now let's consider what is different in case with merged mining:

If Bitcoin mining is by itself profitable, then short-sell-attack described above won't produce a significant drop in value of equipment. And so if we assume that this drop is negligible, attacker will perform a decision to attack when profit from short-selling a currency exceeds profit from mining it.

So, basically, it makes sense to attack as soon that this condition is met, which means that rational miners will likely destroy merged-mined currencies for profit once we'll have financial markets which allow short-selling of such currencies (with a sufficient liquidity).

Situation is different if merged-mining PoW is used together with PoS of some sort: attacker would require a significant stake for a successful attack, and this makes short-selling attacks less lucrative.

No.

Peter Todd (retep) mentioned that merged mining is flawed in this comment




I believe it's actually even worse than that: merged mining is game-theoretically unsound. There is a fundamental difference between a proof of work which is spent on a particular purpose and reused proof-of-work.

Anyway, it looks like you and retep can't be right at the same time, which means one of you is wrong. Now fight

Actually, SPV is pretty sketchy in case with normal merged mining too.

Suppose 10% of Bitcoin hashrate goes into merged mining of Foocoin. A bigger Bitcoin mining pool (having more than 10% of hashpower) wants either to discredit Foocoin or to profit from getting fake transactions confirmed by SPV clients.

So it simply creates a chain of blocks with fake transactions. SPV clients will see it as the best chain, and they will be easily fooled to accept these fake transactions.

The cost of this attack is the opportunity cost: if attacker mined Foocoin properly, he would have got fees and generated coins. It is very easy to estimate this cost and make a decision about attack. Currently, in most cases this opportunity cost in basically negligible.

Thus SPV for a merged mined chain is safe only relatively if more than 50% of Bitcoin hashrate is backing it.

I'm saying relatively safe because even attacker who has only 30% of hashpower can be lucky to create a continuous chain of blocks. Usually this kind of attack is unfeasible in case with Bitcoin because cost/opportunity cost is too high. But in case with merged mining attack might have negligible cost, so attacker can try to perform it for months, which increases chances of success. (Of course, he could be doing a double-spend attack instead, so he should choose whatever has higher impact.)

As I mentioned above, the core of side-chain algorithm is ignoring everything which doesn't look good.


SPV simply cannot work for side-chains, but consensus among full nodes is strong.

The question about merged mining vs side-chains arose in context of discussion about Mastercoin (parasitic consensus system), and as a parasitic consensus system Mastercoin doesn't work with SPV anyway.

By the way, while Namecoin transactions can be SPV'd, domain resolution requires scanning last N blocks where N is something like 36000. So loss of SPV won't be a big problem for Namecoin either...

Yes:

https://dianna-project.org/wiki/Merged_Mining#DIANNA_Implementation

Now let's compared these side-chains to "parasitic consensus systems" which were described in Peter Todd's (incomplete) article:


I think it's obvious that side-chain have same properties as parasitic consensus systems, except they have smaller footprint and need external storage.

This means that, for example, Mastercoin won't lose anything if it will be re-implemented in form of side chain, it would just need its own block storage and incentive system.

Currently merged mining mechanism is often recommended as a consensus mechanism for alt-currencies and whatnot: merged mining enables reuse of Bitcoin proof-of-work, which is nice.

However, it isn't the only way to re-use Bitcoin consensus. The alternative is to create a block chain which is fully dependent on Bitcoin.

It is usually called timestamping, see here: https://bitcointalk.org/index.php?topic=113337.0

Let's call a block chain based on timestamping a side-chain. (I don't know whether it's consistent with previous use, but at least side-chains were mentioned in a topic about timestamping.)

Side-chain is NOT an alternative chain as it doesn't use block chain algorithm, that is, rules for finding the best chain are different.

However, they share a lot of similarities with merged mining: they can use identical machinery on the Bitcoin side, as it's only necessary to reference a hash of side-chain block in the Bitcoin block, and it is what merged mining is about on the Bitcoin side.

The difference is in the rules used to validate blocks and to build the best chain:

• side-chain ignores blocks not references by Bitcoin blocks which are part of best-chain (and this means that Bitcoin reorg triggers side-chain reorg)
• side-chain ignore blocks which do not extend the longest chain
• otherwise, it is just a longest chain of blocks which are referenced from Bitcoin blocks which are part of the best chain

Let's summarize the difference between merged-mined chains and side-chains:

Merged-mined chains re-use Bitcoin proof-of-work, but their best chain is fully independent from Bitcoin best chain. Thus it is possible that merged-mined chain will have a reorganization when there is no Bitcoin chain reorganization; and vice-versa: Bitcoin reorganization has no effect on a merged-mined chain. Thus we can say that merged-mined chains constitute an independent consensus system which merely re-uses Bitcoin proof-of-work, but doesn't depend on Bitcoin chain.

On the other hand, side-chain consensus is fully dependent on Bitcoin consensus: side-chain reorganization is impossible without Bitcoin reorganization. (But Bitcoin reorgs can easily trigger side-chain reorgs.) This means that side-chain consensus is almost as strong as Bitcoin consensus.

I hope now you see why I brought up this topic: if only a fraction of Bitcoin miners uses merged-mining, side-chain s are more secure against double-spends and "51% attacks" than merged-mined chains!

Thus, side-chains are, in a way, superior. Then why merged-mining is the recommended method?

Well, of course, side-chain design has its own trade-offs, and probably the biggest one is longer confirmation times.

Let's compare two situations:

1. 10% of Bitcoin hashpower works on a certain side-chain: side-chain is as strong as Bitcoin, but delay until first confirmation is 10x bigger. (On the other hand, getting 6 confirmations on the side chain will require only 2.7 more time than getting 6 confirmations on Bitcoin chain.)
2. 10% of Bitcoin hashpower works on a certain merged-mined chain: confirmations are fast, but a Bitcoin mining pool having more than 10% of hashpower can brutally destroy it basically for free.

I've improved(?) this a bit: https://github.com/bitcoinx/colored-coin-tools/wiki/colored_coins_intro

No.

Suppose you have just installed NGCCC. In its initial state, it only knows about bitcoins, and isn't able to recognize any colors.

But you, as a user, is interested in some asset. So you instruct it: "NGCCC, I want you to track certain colored colored coins using parametrized color kernel OBC. Their genesis is X:Y. Please call them Foo".

NGCCC will add a record like "OBC:X:Y = Foo" into its configuration file so it will be able to remember about this association between name and color.

And now it is able to recognize these Foo-coins.

Issuing transaction is just a normal transaction. It simply acts as a starting point: next transaction will spend its output, and so on.


Blockchain has information about transfers of colored coins.

Everything else can be stored elsewhere.


We use a layered model.

Lowest layer is the colored coin model, it is about color kernel and colorvalues. Contracts simply do not exist on that level.

Contracts can appear on higher levels, but so far we haven't fully implement this higher level. But the thing is, it can be implemented in many different ways, and it isn't of utter importance.

I believe it's better to keep it manual for now.

E.g. suppose John Smith wants to issue 1000 bonds with face value of 1 USD each. To do this he will write a message like


Then John Smith will sign this message using GPG and will post it in on forum. If there are people who trust him, they'll check if GPG signature is valid.

If they are willing to trade these bonds, they will add color mentioned in the message into their colored coin client.

Of course, we can create a special format for these contracts, make some kind of database where they can be published and so on.

But right now it isn't necessary: people can just use whatever they are comfortable with.

Colored coin software is just a tool which tracks coins.

Well, previously I was working on a different client, called ArmoryX. Since many people already follow this thread, I decided to continue posting updates in it. I guess I should rename it....

What data?

If you're talking about metadata like name, contract, etc., then it can be anywhere. E.g. somebody might post on forum that he is selling shares of his company foo, and you canl add this asset definition to your client, like


Now it can show you your foo balance (how many shares you have), you can buy and sell them. Of course, client doesn't care what "foo" means.

If you're talking about ownership data, it is encoded in Bitcoin transactions. These transactions look exactly like normal Bitcoin transaction and do not have color tags or anything. But client can trace them back to the genesis transaction my going through the transaction graph, and that's how it knows that it represents ownership.

FWIW I had pretty much the same idea about a half year ago.

https://bitcointalk.org/index.php?topic=138000.msg1471978#msg1471978

Although I thought about using words rather than phonemes: four words are enough.

E.g. somebody can register a name like "cranky corporate classic company".

It was a good proof-of-concept, but implementation is incredibly amateurish.

A bunch of undergrad CS students could produce a better one. (I'm not joking.)

We are also looking for JS developers to work on WebcoinX.

Here's a list of tasks: https://trello.com/b/n4qoNDDI/webcoinx (the most important ones are on 'Future' deck).

Interested developers should send me PM and describe:

• their experience (particular, familiarity with things like binary serialization, Bitcoin protocol, OO design)
• availability (how many hours per week can you allocate on this, how soon)
• expected compensation (we have 30 BTC bounty pool for the next iteration of WebcoinX, but it is open for discussion)

Currently the focus is on the thing called ngcccbase: we're going to start with a command-line client (we'll make network daemon and GUI versions of it later, using the same core).

It is currently barely able to show balance, but all the infrastructure is there. It need many improvements before it is usable.

Repo: https://github.com/bitcoinx/ngcccbase

List of available tasks: https://github.com/bitcoinx/ngcccbase/issues

The process:

• anybody can grab a task
• the requirement is to report progress often. the plan is to make a working version in matter of weeks, so even few days of delay can have detrimental effect
• fork ngcccbase repo, write your commits, create a pull request
• in pull request, please mention how many hours you spent on it (you're supposed to track them, but guesstimation is OK)
• bounties will be rewarded proportionally to hours spent, as long as they are reasonable
• total compensation pool is 30 BTC, but we need to do a lot of development, and it isn't possible to tell what one hour of work will be worth.
• if you do not like uncertainty you can offer to implement a specific task for a fixed bounty. drop me a note in this case

I will repeat in simple words: "that distribution level" has no advantages. It is NOT a good thing.

You CANNOT implement a thin client by getting a transaction history for a certain address.

Mastercoin transaction have implicit dependencies, and that means that once you'll get to advanced features, the only way to check transaction validity is to check all Mastercoin transactions. And, obviously, if you scan all Mastercoin transactions, it cannot be called a thin client. Potentially there will be millions, or even billions of such transactions.

On the other hand, thick clients which download all transactions and go through them keeping a local DB do not benefit from what you call "distributed architecture": Bitcoin protocol is already distributed, so you can just download all relevant blocks directly from the Bitcoin network.

You could say that you can make a faster thick client by using Obelisk, but it is a really bad trade-off: you gain a little in speed (if Mastercoin will be a big thing, then almost all Bitcoin transactions will be Mastercoin transactions, so there is no substantial difference between downloading whole blockchain and downloading only Mastercoin transactions), but you no longer have Bitcoin's foolproof security.

Trading off security for tiny gain in performance, how does this make sense?

Perhaps this makes sense in the short term, that is, while Mastercoin transaction count is very low you can indeed make a thin client this way, and perhaps it has some value. But I think you shouldn't boat of "distributed architecture", as it doesn't really have advantages in the long term.

Please note that I don't have a horse in this race, I just want to clarify some things.

You'll need special, Mastercoin-specific servers to enable validation on thin clients. Obelisk servers are simply are not suitable for this because they do not implement Mastercoin protocol.

Currency can be configured to automatically dissolve if escrow fund is too low, from the 1.1 spec (this wasn't present in 1.0):


So... If mastercoins drop in price against gold, your GoldCoins will be automatically converted into mastercoins. Isn't that helpful?

Furthermore, suppose mastercoin drops in value. This triggers automatic conversion of GoldCoins into mastercoin. Now we have (potentially) a lot of people, who preferred gold exposure to Mastercoin exposure, and who know that mastercoin drops in value... Obviously, they'll want to buy gold with their mastercoins ASAP. Which means that a lot of mastercoins will be dumped on exchanges, causing further drop of mastercoin price, possibly causing collapse of other escrow-backed currencies.

So this has a positive feedback effect, where relatively small fluctuations can trigger an avalanche.

This seems to be an inherent property of systems like this: you cannot achieve true stability within a closed system; you can, however, make a trade-off, that is, you have to pay for reduction of volatility, and the price might be increased probability of catastrophic collapse.

---

By the way, escrow fund mechanism makes it harder for a honest company to do this market making.

Suppose escrow fund is not used. Then a company can back coins it issues with 100% physical platinum. Company's exposure is neutral, so it doesn't need to do anything sophisticated to keep currency alive. It can simply sell platinum and buy back coins. It is inherently stable.

Now suppose that company buys mastercoins instead of platinum. Now company's position isn't neutral: is is long mastercoin and short platinum. It will be very hard to hedge this exposure.

Honestly, I don't see why a honest company would want to start an escrow-backed currency.