I'm sorry to disappear for 3 days and then dredge this up, but I can see that you and I have a difference of opinion on the time frame here, and on the idea of the value of the "black swan" events in a commodity speculator's portfolio. But even if you continue with these attempts at a trustless representational currency, let me very respectfully ask you to also include the ability for people to create their own (trust-required) exchangeable entities, with a reference to a signed legal document describing the entity in its genesis block. These new "currencies" could be a mortgage, stock in a company, a commodity with real backing, etc. That is, add "native" support for colored coins within your system. Whether or not your trustless representational currencies work, these trust-backed currencies will be very valuable, will utilize most of the same software infrastructure as your trustless and would make MasterCoin still useful if your trust-backed currency system does not work. PM me if you need some impl help maybe I can find some time...
That's a very interesting idea. I suppose we might as well support currencies that work like colored coins. It doesn't really add any complexity to the design, and it seems likely that people would use it.
That would also give people one way to "invest" in the success of coins which work like colored coins - by buying MasterCoins. Previously there was no way to do this.
The built in decentralized exchange between MasterCoins and the other backed currencies would support something like this with almost no modifications.
Now, why didn't I think of that??
Being able to fund your mortgage through something like this would be epic. And I didn't want to say it but it might even be a subset of the functionality you'll have to implement for your trustless coin.
Of course many jurisdictions will have regulatory issues but it is essentially impossible to get the laws changed in advance.
Ok next: you have done some amazing work in cramming this protocol entirely inside bitcoin. I skimmed this but did not analyze. But there seem to be clear issues with this such as data density (space efficiency), complexity (bugs), lack of control over the underlying Bitcoin protocol (as BitcoinX discovered with the "dust" patch), and possibly a perception of SatoshiDice-like spamming from the point of view of Bitcoin-only users. At the same time the critical issue with alt chains is the lack of atomic exchange between BTC and the altcoin.
So, have you considered running a parallel chain for MasterCoin, but one that ALSO uses your research into overlay protocols to stick the minimum possible information into the bitcoin chain? For example, it would be possible to encode in your alt-chain a txn that enters the MasterCoin-chain but is only valid if and when a bitcoin txn enters the bitcoin blockchain.
MasterCoin clients would need access to both chains. This would require no more data than an overlay protocol would use -- its just a different organization. But that organization solves all the problems I described above. And I think that with clever coding someone in the future could allow a "non-btc-validating" MasterCoin client that sees only the MasterCoin chain (and can only issue intra-MasterCoin transactions).
