P2SH multisig can replace bare multisig, by moving the data stored in outputs to the inputs.
This also avoids bloating the UTXO database, the key database that is queried multiple times per second by all full nodes on the network.
Solutions have existed for years. UTXO database is not the place for data storage. It impacts everyone, network-wide. It impacts the real-time performance of the network.
Dear Jeff, Luke-Jr and Peter. Thank you for taking time to communicate and engage with us here. We've discovered quite a bit and we're happy to have you bitcoin core devs sharing your interest on our thread.
In the interest of a way forward, will you let me propose 3 steps based on your note above that will include some give and take to make sure we can all work together?
Step 1: Give us the 80bytes for OP_RETURN. Let Counterparty and other metaprotocols like Mastercoin take the pressure OFF the UTXO database for EVERYONE as its in all our best interests and improves UTXO database performance immediately. Our interest is to improve Bitcoin performance and to avoid spamming the network. Together, let us monitor OP_RETURN behaviors with you as it is in our interest to do so. If SPAM gets out of hand, we can always disable or reduce the size to 40bytes.
Step 2: We will give you OP_RETURN in 6 months so it can be taken into obsolescence. Together, why don't we set a community deadline date for OP_RETURN to be removed from protocol so that Counterparty and Mastercoin both move to P2SH or other solutions. Given that this stuff is hard, we will be able to have the breathing room necessary to implement a blockchain friendly solution. Again, the blockchain performance is still protected here. We also assume that you'll continue to restrict bare multisig transactions, but that won't impact Counterparty or Mastercoin as we'll be using P2SH or better.
Step 3: We will take Peter Todd's continued guidance as our liason with the bitcoin core devs. He has showed immense value bringing up solutions to keeping us together/secure on the same blockchain. We will work with him to exchange further questions and issues wiith the broader bitcoin coredev/security community so that we don't lose touch with each other's interests. As you've mentioned here, you like his proposals and we would benefit to use them.
Is there any reason why this is against your interests and not something we can work on together?
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!).