It seems like the argumentation in this thread is becoming circular. Would very much like to see a response to these two posts:
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)
As I see it, the best solution is to keep the OP_RETURN size at 40 bytes, for simplicity and compatibility, but to allow multiple OP_RETURN outputs per transaction. There's no reason that 40 bytes of misc. data per transaction is better for Bitcoin than 80, or 120 bytes.
[snip]
Actually what should be done that would - in theory - please both sides of the issue would be to do a patch that makes embedding data in OP_RETURN transactions as expensive as doing so by creating unspendable outputs. Basically what the OP_RETURN payload is just made unlimited (up to the max size of a transaction) but you bump the min fee by the same amount that would have been simply burned in the unspendable output. I'd further recommend that the cost be set slightly less than that amount, to always incentivize using prunable blockchain space rather than unprunable UTXO space. (a legit concern in the current design, although my TXO commitments scheme probably reduces the problem greatly)
I'll do up a pull-req for this.