Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 375. (Read 1276826 times)

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!).

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!).

I guess the past few responses to me have made it clear that people on this thread don't want to discuss or solve things, but merely make strawmen and misrepresent the reasonable statements of others.

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?

It's abuse because you're forcing others to download/store your data against their free choice.
Every full node must download the full blockchain (prunable or not!).
Every full node has consented to download and store financial transactions.
NOT every full node has consented to store anything else.
You need 100% consensus for this, not merely some subset (ie, not miners; not developers) or even a majority.

Furthermore, everyone is free to store data that isn't in the blockchain.
There is nothing to be gained by putting it in the blockchain except that you force it on those who don't want it.
Explain how this is anything but abuse...

Not quite.

I proposed that bare CHECKMULTISIG txouts be not relayed primarily to fix a security issue/poor economic design issue. Others want to see them not be relayed for other reasons.

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.

It's abuse because you're forcing others to download/store your data against their free choice.
Every full node must download the full blockchain (prunable or not!).
Every full node has consented to download and store financial transactions.
NOT every full node has consented to store anything else.
You need 100% consensus for this, not merely some subset (ie, not miners; not developers) or even a majority.

Furthermore, everyone is free to store data that isn't in the blockchain.
There is nothing to be gained by putting it in the blockchain except that you force it on those who don't want it.
Explain how this is anything but abuse...

Miners are not supposed to decide protocol changes any more than developers.
Protocol changes, in general, require consensus of the economic majority (or, more practically, "will this person I want to pay accept my forked-blockchain bitcoins?").

So essentially this is a non - issue in the scheme of things ?

Why do you speak of it as decided that data storage in the Blockchain constitutes abuse?

Whether you think there are better implementations than the current one is not the problem, but rather that you are making a protocol change for something that miners are, by design, supposed to decide for themselves, and acting autocratically over Bitcoin.

Not quite.

I proposed that bare CHECKMULTISIG txouts be not relayed primarily to fix a security issue/poor economic design issue. Others want to see them not be relayed for other reasons.

In an attempt to prevent spam transactions there has been a proposal to discontinue relaying bare multisig transactions from reaching miners..... If the proposal is heeded than counterparty will need to change the protocol

So maybe if we just doubled the fees than the TX wouldn't be considered a bare multisig

Phantom ? Thoughts ? Xnova?

No, it is a lack of understanding how bitcoin works.  Peter Todd's proposal suggests not relaying bare multisig transactions, and I wrote the code to do that:  https://github.com/jgarzik/bitcoin/tree/bare-multisig

"Non-standard" means "most nodes probably won't relay your transaction" but nothing more than that.  No protocol change or fork.  Miners are free to continue to put such transactions in blocks, assuming that they receive the transactions somehow.

Didn't someone just say that there was a proposal to remove multisig

No, it is trivial to block 100% of them.  A proposal to do just that appeared on the bitcoin-development mailing list yesterday from Peter Todd.  This proposed change would relay zero transactions with multisig outputs.

Most of the world is moving to P2SH for multisig, leaving the remaining "bare multisig" users mastercoin, counterparty, etc.