This is what I was talking about.

In case with colored coins, each color is independent, and can be fairly simple. It's trivial to "feature freeze" a color (at least in terms of ownership), and then, technically, there might be bugs in wallet implementation, but semantics is 100% clear.

But Mastercoin is monolithic and feature-full. Each feature can potentially interact with each other. Getting a stable Mastercoin implementation with sane upgrade policy is very hard IMHO.

I hope you do not recommend people to trust their money to something which "don't have anything 'stable' - not even close" and is in "rapid prototyping" stage.

So I said that we'll likely get a usable colored coins usage way before usable Mastercoin exchange. But Ron and Taariq pretend that it's non-issue, like, we have a spec on github, hence consensus is guaranteed.

Really? This spec is nothing. It is way too vague. You haven't even tried to formalize interpretation of the spec or anything like that.

For example, it defines that rate-limited address cannot be used for decentralized exchange. This makes sense, of course.

But what if a command to make address rate-limited is sent after an offer on decentralized exchange is made? Will it cancel the offer, or will command be ignored?

If implementation X cancels the offer, while implementation Y ignores a command to make address rate-limited, it is possible to double-spend.

You need to define a formal model of Mastercoin transactions, e.g. a state variables are associated with each address. And then you can describe how each command modifies state variables of addresses which are involved.


Actually, no: Satoshi released a complete version of a client, and Bitcoin developers were always reluctant to change things which can affect consensus. Almost no features were added to the protocol in these 5 years. If anything, many features were disabled.