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

Many of the greatest developments in computing history (and indeed, human technological history on the whole) are the result of people finding uses for things which were unintended by their inventors.  Good thing that most inventors are not so protective of their inventions that they decline to let others use it for new things.  Those that did, found themselves surpassed quickly.


Then you should delete the entire blockchain from any nodes that you have running right now, because there is arbitrary, non-financial-transaction data being stored in it already.  LOTS of it.  If you decline to consent to store that data, then you have no choice but to shut down your node, unless you have some sort of magic decoder that can sort through the millions of transactions to find stuff secretly encoded into addresses and such, and discard it while keeping the valid stuff.


So what is your problem with Counterparty, which is designed to carry financial transactions (but, in the mode of all such inventions, could be used for other stuff as well)?

Thats right, if you don't want to store it, don't, fairly simple, don;t use bitcoin, don;t download the block chain, your scott free
However my consent means that i believe bitcoin has more functionality than just for transactions, and based on that fact nobody owns it, and there is OP_RETURN feature, i don;t see why that functionality should be eradicated becouse you don;t want to store the data which you already have a free choice on.

I don't think you quite follow my point. You agreed to run a Node and Mine block transactions with a certain protocol - when you run the code it doesn't say in the code #financial transaction or #child pornography - it just specifies rules for handling data.

You can be selective in what you mine and in what your node rebroadcasts - that's consensual. You can alter whether your client accepts certain newly formed blocks or not - also consensual. You can alter your client and the implementation of the protocol your client handles, of course it will not work with all the other Nodes - but you did not give any evidence for why you think the rest of the network 'implicitly disagrees', logically speaking if they do 'implicitly agree' they will democratically alter their clients as well. This is how an open-source protocol is supposed to work right? 

Counterparty transactions are as Phantomphreak mentioned, storing financial data.

Do I need to repost this every post here?

I really cannot understand how a counterparty transaction would not constitute a financial transaction?. 

nor can i understand the point of view that because say, 1 node out of 1000 is not willing to accept this data, by default it should be forbidden.

After the recent nightmare that was mt gox and huge amount of hacks, thefts, closures and losses that came from storing your balance on centralised entities
it seemed that counterparty had came up with a solution that allowed a decentralised, trustless solution to this problem- boostrapping on top of bitcoin blockchain and benefitting from it's proof-of work, and now it seems like some more senior members are on the offensive. Are solutions like this note hugely beneficial to bitcoin ecosystem?

Your consent does not mean I should be forced to store it, which is what you are proposing.
I'm not the one trying to change the protocol here... the current protocol does not support data storage.

Funny to see this line of reasoning from the guy who defended putting religious messages in the blockchain.


The fact is, arbitrary data can be stored in the blockchain by anybody at any time.  It has been and is being used for this purpose already.  Everybody running a Bitcoin node should already know this, and if they aren't, it should be a part of the notice that comes up when they install Bitcoin-QT (if there is one; I don't recall seeing one).  Any Bitcoin transaction could just be a simple movement of funds, or it could be a love note, or it could be a trigger for setting off a bomb.

Eliminating this possibility would kill Bitcoin, period.

Maybe there are some ways of doing this that are more harmful than others.  Maybe you can eliminate the most harmful ones, maybe not (it seems that using unspendable addresses to store data would be the "last resort" which could NEVER be eliminated from Bitcoin, and that this is one of the options that is most harmful).

It seems that the Counterparty devs are being very reasonable here.  My instinct would be to say "screw it" and just continue as planned, and if future changes to Bitcoin require changes to Counterparty, then so be it.

Furthermore, for some to come in here whining "why haven't they reached out to the Bitcoin community?" "Why did they merely flip a switch without consulting anybody?"  I merely present this thread, which has been openly discussing Counterparty and its "built on Bitcoin" design for months now, here on the home forum of Bitcoin, with over 6000 replies.  If that's not "reaching out to the Bitcoin community" then I don't know what is.

great argument.......the reverse can be said - I will just consent to data storage myself. Which puts you in a position to never change the OP-RETURN, surely,
You do not own the blockchain

Again, we only store financial transactions in the blockchain, and we are paying for the space that we're using. Financial transactions in OP_RETURN outputs aren't any more painful for a full-node to store than anything else.

Would you be willing to consider Peter Todd's proposal? If not, how would you make it better?

Hey, by the way, are you Satoshi?

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.

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.

I didn't say there exist non-appropriate 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?

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

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?

• 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:

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?

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.

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.



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.

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.

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