I don't get Jeff's point here. Even assuming that this is the case, any product of this would have to become public knowledge in the form of source code at some point, to be actually used. At that point, Mastercoin (as an open source project) would have lost their advantage here.
Also, this assertion is questionable as we are working with Peter as well. I don't want to speak for him (and he can correct me if I am wrong here), but he has communicated to us that in the end, his desires lie in moving the technology itself forward over allegiances to any specific implementations of it (for Counterparty OR Mastercoin).
+1
If anything I hope I've given the impression that I think all these "Blockchain 2.0" projects probably have terrible flaws in them right now. But flaws can be fixed, either by upgrades or starting over; what I care about is that something worthwhile is bound to emerge in the end. In the meantime I can bring value to these projects - that is earn my pay - by being independent and objective enough to give good advice and do good research. Which incidentally I think the
Bitcoin developers are currently failing at themselves because they're too focused on their narrow use-case for Bitcoin as cheap transactions - take this advice to just resort to insecure centralization and/or easily attacked DHT's:
12:47 < gavinandresen> jgarzik: RE: mastercoin/OP_RETURN: what's the current thinking on Best Way To Do It? Seems if I was to do it I'd just embed 20-byte RIPEMD160 hashes in OP_RETURN, and fetch the real data from a DHT or website (or any-of-several websites). Blockchain as reference ledger, not as data storage.
Or for that matter the discussion around my post on
Decentralized digital asset exchange with honest pricing and market depth.
Edit: To be clear, all this discussion about moving things like Counterparty to different independently or merge-mined blockchains as a "solution" to the "problem" of adding data to the blockchain is either mistaken or downright deceptive. Fact is these systems all get much better security by being embedded rather than independent. Decentralized consensus system security is a game of strength in numbers, and you want to be making use of the largest system you can afford. Merge-mining looks like a nice way to achieve that, but in reality just leaves you vulnerable to zero-marginal-cost attacks until you get the support of a large % of the total hashing power. A real world example of this is how Luke-Jr used Eligius to attack the merge-mined alt Coiledcoin. That leaves us with embedded consensus systems, and fortunately with Bitcoin only explicit blacklists have any hope of censoring their transactions rather than just making them a bit more expensive. (perhaps the even stronger requirement for explicit whitelists if my timelock crypto scheme can be made practical)