[ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread

[PhantomPhreak]

can someone summarize in a few sentences what the issue(s) is here?

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

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.

Also, 'change the protocol' sounds much scarier than it should.

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

Haha. I'm certainly not selling!

[porqupine]

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

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

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.

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?").

Wait a minute when was it decided that: Every node has consented to store X type data and not Y type data.
Maybe I also did not consent to store transactions for Laundered money, illicit drugs and weapons, human slavery - etc.

You're basically negating protocol neutrality and deciding what the Protocol Should and Should Not be used to store, and More than that you aren't speaking in first person but using the pronoun Us given the impression that you are speaking for all miners or protocol users as a whole.

So what started out as a Democratization of currency - turns out to tightly controlled by an autocratic group who takes for itself the role of speaking for all the users of the protocol - in your own words:

Explain how this is anything but abuse

[BitcoinTangibleTrust]

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?

EDIT: See Phantom's follow-up below as a much better approach.

[l4p7]

can someone summarize in a few sentences what the issue(s) is here?

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

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.

Ok I got it. Execpt that I dont know what bare multisig / CHECKMULTISIG txouts are. Can that be summarized in sipmply terms or is there any text that makes me understand?

[PhantomPhreak]

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

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

First of all, Counterparty transactions are financial transactions.

Second, every full node has consented to download and store the Bitcoin blockchain, no less. That is, transactions that accord to the Bitcoin protocol, which Counterparty transactions obviously do. Satoshi imbedded a political message in the Genesis Block, for Christ's sake... You have a much narrower view of the possible use cases for Bitcoin than do others. (See what Peter Todd wrote above.)

By your reasoning, Bitcoin should never be used for anything new, ever.

[PhantomPhreak]

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

[Luke-Jr]

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.

[PhantomPhreak]

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.

We are all eager to discuss these issues and to resolve our disagreement. Your main argument, however, just doesn't have leg to stand on, IMO.

[BitcoinTangibleTrust]

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

Much better than anything I could come up with. I crossed out what I wrote above. Thanks for outlining a sensible approach.

I'll bow out from here on out.

[Peter Todd]

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.

[Luke-Jr]

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.

We are all eager to discuss these issues and to resolve our disagreement. Your main argument, however, just doesn't have leg to stand on, IMO.

If it didn't have "leg to stand on", you wouldn't need to misrepresent me.

[porqupine]

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.

It would have been quite different if you came here and instead and said: here are the technical reasons why I and some Developers of the Bitcoin protocol feel that Op_return 80 is unwarranted, why we are not partial to Counterparty as a protocol, and supported this with actual discussion of technical facts.
The fact that you hold certain positions within the community is no doubt, and should continue to be on account of the positive role you play in the community, but it certainly should not be used as leverage to empower yourself above others and excuse yourself from any reasonable presentation of facts.

Instead I think that you came to this forum basically using very strong words Victims, Abuse, the pronoun Us to phrase your arguments - these are not strawmen, this is the attitude that you and in part Jgarzik adopted for addressing the members of this forum, users of the Bitcoin protocol, users of the Counterparty protocol, and it's developers.

[jgarzik]

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

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

First of all, Counterparty transactions are financial transactions.

Second, every full node has consented to download and store the Bitcoin blockchain, no less. That is, transactions that accord to the Bitcoin protocol, which Counterparty transactions obviously do. Satoshi imbedded a political message in the Genesis Block, for Christ's sake... You have a much narrower view of the possible use cases for Bitcoin than do others. (See what Peter Todd wrote above.)

CheckMultiSig is quite clearly intended for ECDSA public keys, not arbitrary data.  It should be no surprise that using an operation for something other than its intended purpose has negative, perhaps unintended or unknown consequences.  Counterparty transactions are not "according to the bitcoin protocol", they slip through because it never expected that the feature be used in that way.

"It works by accident" or "it works because it is difficult to prevent" does not imply good design or the right way of doing things.

By your reasoning, Bitcoin should never be used for anything new, ever.

No.  It is quite easy to extend the bitcoin protocol.  It has been done many times.  See the BIP process.  The community agrees and the protocol is updated.

But that was apparently not the path chosen...  counterparty clearly uses a feature (CheckMultiSig) in a fashion for which software was not designed.  It is silly to pretend that full nodes "consented" to an unintended use.

[PhantomPhreak]

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.

We are all eager to discuss these issues and to resolve our disagreement. Your main argument, however, just doesn't have leg to stand on, IMO.

If it didn't have "leg to stand on", you wouldn't need to misrepresent me.

I do not mean to misrepresent you, or your arguments. The other Counterparty devs and I are all committed to finding a solution that we can agree on.

[Fernandez]

Its a little bit sad how the these Bitcoin developers arguing in a way as if they own Bitcoin.

Is Mastercoin having the same argument right now?

[Luke-Jr]

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.

We are all eager to discuss these issues and to resolve our disagreement. Your main argument, however, just doesn't have leg to stand on, IMO.

If it didn't have "leg to stand on", you wouldn't need to misrepresent me.

Ok restate a concise version, if you have time.

• The blockchain must be stored and downloaded by every Bitcoin full node.
• Every Bitcoin full node, upon adopting Bitcoin, agreed implicitly to store a specific kind of data in the blockchain: financial transactions.
• Therefore, there is consent to store these financial transactions in the blockchain.
• On the contrary, there exist nodes among these which have not consented to store other data.
• Therefore, there is not consent to store that other data in the blockchain.

To extend Bitcoin, one should keep these facts in mind.
Non-transactional data should be stored parallel to the blockchain, possibly available for anyone who wants to download/store it (perhaps using an extension to the p2p protocol to relay it), but not inside it (which has never been demonstrated to have any necessity/value anyway).

As a reminder, my only comment here on Counterparty specifically has been:

In your opinion, which category do you feel XCP falls into?

I haven't looked at XCP in detail yet, so I'll have to defer to others who have.

[PhantomPhreak]

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

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

First of all, Counterparty transactions are financial transactions.

Second, every full node has consented to download and store the Bitcoin blockchain, no less. That is, transactions that accord to the Bitcoin protocol, which Counterparty transactions obviously do. Satoshi imbedded a political message in the Genesis Block, for Christ's sake... You have a much narrower view of the possible use cases for Bitcoin than do others. (See what Peter Todd wrote above.)

CheckMultiSig is quite clearly intended for ECDSA public keys, not arbitrary data.  It should be no surprise that using an operation for something other than its intended purpose has negative, perhaps unintended or unknown consequences.  Counterparty transactions are not "according to the bitcoin protocol", they slip through because it never expected that the feature be used in that way.

"It works by accident" or "it works because it is difficult to prevent" does not imply good design or the right way of doing things.

By your reasoning, Bitcoin should never be used for anything new, ever.

No.  It is quite easy to extend the bitcoin protocol.  It has been done many times.  See the BIP process.  The community agrees and the protocol is updated.

But that was apparently not the path chosen...  counterparty clearly uses a feature (CheckMultiSig) in a fashion for which software was not designed.  It is silly to pretend that full nodes "consented" to an unintended use.

Bitcoin does lots of things that it was not originally intended to do. Yes, we'd greatly prefer to use a more elegant solution than what we have now. Counterparty was originally designed to use the OP_RETURN output to store all of its message data, which I feel is very elegant, and leaves a minimal impact on the blockchain. We planned all of our message formats around the 80 byte limit announced by Gavin on the official Bitcoin blog. We only use multi-sig outputs because we have no other choice. We don't want to extend the Bitcoin protocol. We want to do something entirely within it, and as simply and directly as possible, for the benefits to stability, security etc..

Under what circumstances would you consider supporting storing more than 40 bytes of data in the txout space? What do you think of Peter Todd's most recent proposal?

[BldSwtTrs]

So what is the solution if neither OPRETURN and CheckMultiSig are available?

[porqupine]

• Every Bitcoin full node, upon adopting Bitcoin, agreed implicitly to store a specific kind of data in the blockchain: financial transactions.

You're not answering the question - but just restating your conviction.
If I run a TOR exit Node because I think people should be able to access websites blocked by the Chinese government, people can still use it to send child-pornography. The agreement is only to use a certain kind of protocol - that is handling data in a formal way.

If you disagree with this than I would very much like to hear an explanation.
 
What is the implicit agreement every Bitcoin node accepted? Did you conduct a large survey of Bitcoin users to find out what they were 'implicitly' agreeing to? Who decided what kind of financial transactions were the appropriate kinds and what kinds of financial transactions are not?

[Luke-Jr]

• Every Bitcoin full node, upon adopting Bitcoin, agreed implicitly to store a specific kind of data in the blockchain: financial transactions.

You're not answering the question - but just restating your conviction.
If I run a TOR exit Node because I think people should be able to access websites blocked by the Chinese government, people can still use it to send child-pornography. The agreement is only to use a certain kind of protocol - that is handling data in a formal way.

Bitcoin at day 1 was only transactional, at the protocol level (the only exception being the scriptSig for the generation transaction).
All data storage attempts, even the OP_RETURN stuff, are technically abuses the protocol was never intended for.

What is the implicit agreement every Bitcoin node accepted? Did you conduct a large survey of Bitcoin users to find out what they were 'implicitly' agreeing to?

You only need to find one person who did not agree to data storage, for it to be non-consensual.
For the sake of avoiding wasting time on a survey, I will just decline to consent to data storage myself.

Who decided what kind of financial transactions were the appropriate kinds and what kinds of financial transactions are not?

I didn't say there exist non-appropriate financial transactions.