Quote from: PhantomPhreak on March 21, 2014, 07:10:34 PM

This is not a good proposal. If nothing else, you're seriously misunderstanding the motivations for the various proposals at the table. We don't need six months to implement anything, and the Bitcoin protocol shouldn't go backwards as you suggest. This also doesn't address the security issue that Peter Todd brought up.

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. Luke-Jr, jgarzik, et al. are merely uncomfortable with the idea of using Bitcoin for things that they had never thought of, so they don't want to encourage people to do anything but store hashes in the blockchain (as if everyone had explicitly agreed to do that!).

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.