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

[nakaone]

guys calm down, everyone in the bitcoin universe know which role the core developers play and until now they did quite a good job - I think the developers of xcp are already in close contact to the core developers, let us see where this is going

[halfcab123]

guys calm down, everyone in the bitcoin universe know which role the core developers play and until now they did quite a good job - I think the developers of xcp are already in close contact to the core developers, let us see where this is going

They're talking about getting rid of multi sig.  I need a xanax.

[porqupine]

So this is what a currency free from the banks is supposed to be? A money supply determined by an even smaller autocracy? At least the Bank's do not Threaten their Clients.

[bitwhizz]

So this is what a currency free from the banks is supposed to be? A money supply determined by an even smaller autocracy? At least the Bank's do not Threaten their Clients.

Yep, its disgraceful

[jgarzik]

From the perspective of counterparty and the overall bitcoin community,

• The criticism is not against counterparty, but just One Flaw in the system
• There was zero consultation on the design with the wider community before the "on" switch was flipped
• This flaw --network-critical database used for raw data storage-- was well known before Counterparty began life. You could have avoided this problem with communication.
• Existing designs are known to be less abusive to the network, and do not store data in that key database

It is perfectly possible to run counterparty without this flaw.

[jgarzik]

Now, I am just a disinterested observer here (with investments in Bitcoin and all major 2.0 cryptos) so I don't speak for anybody but myself here; but it seems to me that Counterparty has Bitcoin over a barrel somewhat, especially with respect to the unspent outputs, which would be quite difficult to selectively block on the Bitcoin end.  It would quickly turn into a cat and mouse game.  Bitcoin could implement code to detect and block XCP transactions, but XCP changes a few parameters and re-launches a week later to get around it, which causes Bitcoin to respond, which causes a new change in XCP, etc. ad nauseum.  I don't think that anybody wants that.

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.

Isn't Peter Todd working on Mastercoin? Why would he propose that?

Think about it.  Mastercoin is a competitor to Counterparty.  Mastercoin is already aware of, and working on solving this storage-in-multisig problem.

Peter Todd's proposal simultaneously (a) benefits Mastercoin, (b) disadvantages Counterparty, and (c) presents a proposal that portions of the developer and mining community already find agreeable.


Edit: retracted, based on Peter's recent posting.

[IamNotSure]

From the perspective of counterparty and the overall bitcoin community,

• The criticism is not against counterparty, but just One Flaw in the system
• There was zero consultation on the design with the wider community before the "on" switch was flipped
• This flaw --network-critical database used for raw data storage-- was well known before Counterparty began life. You could have avoided this problem with communication.
• Existing designs are known to be less abusive to the network, and do not store data in that key database

It is perfectly possible to run counterparty without this flaw.

Thanks for the explanation.

I'm reading all these posts with a lot of interest but sometimes explaining things with simple terms is really useful for the vulgum pecus.

[bitexch]

From the perspective of counterparty and the overall bitcoin community,

• The criticism is not against counterparty, but just One Flaw in the system
• There was zero consultation on the design with the wider community before the "on" switch was flipped
• This flaw --network-critical database used for raw data storage-- was well known before Counterparty began life. You could have avoided this problem with communication.
• Existing designs are known to be less abusive to the network, and do not store data in that key database

It is perfectly possible to run counterparty without this flaw.

You are using the protocol as a bargaining tool, because you don't like what a project did. Do you see the problem with that?

All you are doing is making a decision for miners.

[halfcab123]

So can we hear anything from PP or XN on this ?

[PhantomPhreak]

From the perspective of counterparty and the overall bitcoin community,

• The criticism is not against counterparty, but just One Flaw in the system
• There was zero consultation on the design with the wider community before the "on" switch was flipped
• This flaw --network-critical database used for raw data storage-- was well known before Counterparty began life. You could have avoided this problem with communication.
• Existing designs are known to be less abusive to the network, and do not store data in that key database

It is perfectly possible to run counterparty without this flaw.

It is perfectly possible to run Counterparty without storing data in the blockchain directly, yes. But there is no flaw in the possibility of doing so, and all the explanations that have been given for why it is 'abusive' or a 'problem' use circular logic. It's even misleading to call it 'raw data': it's not GIFs or tweets or anything like that---it's transaction data, just transaction data that Bitcoin itself doesn't parse.

We are adding (a great deal of) functionality to Bitcoin, and paying whatever fees miners ask for it. All of the outputs we are generating are spendable and prunable. We are doing our best to help Bitcoin (and users of Bitcoin), which has enormous potential beyond its current abilities.

[halfcab123]

From the perspective of counterparty and the overall bitcoin community,

• The criticism is not against counterparty, but just One Flaw in the system
• There was zero consultation on the design with the wider community before the "on" switch was flipped
• This flaw --network-critical database used for raw data storage-- was well known before Counterparty began life. You could have avoided this problem with communication.
• Existing designs are known to be less abusive to the network, and do not store data in that key database

It is perfectly possible to run counterparty without this flaw.

It is perfectly possible to run Counterparty without storing data in the blockchain directly, yes. But there is no flaw in the possibility of doing so, and all the explanations that have been given for why it is 'abusive' or a 'problem' use circular logic. It's even misleading to call it 'raw data': it's not GIFs or tweets or anything like that---it's transaction data, just transaction data that Bitcoin itself doesn't parse.

We are adding (a great deal of) functionality to Bitcoin, and paying whatever fees miners ask for it. All of the outputs we are generating are spendable and prunable. We are doing our best to help Bitcoin (and users of Bitcoin), which has enormous potential beyond its current abilities.

+1.00000000

[BitcoinTangibleTrust]

Isn't Peter Todd working on Mastercoin? Why would he propose that?

Think about it.  Mastercoin is a competitor to Counterparty.  Mastercoin is already aware of, and working on solving this storage-in-multisig problem.

Peter Todd's proposal simultaneously (a) benefits Mastercoin, (b) disadvantages Counterparty, and (c) presents a proposal that portions of the developer and mining community already find agreeable.

Isn't Peter Todd also employed by Counterparty? https://www.counterparty.co/sergio-lerner-peter-todd/

Maybe the devs at Counterparty should learn Peter's proposal and we explore how we might participate to benefit alongside Mastercoin?

[bitwhizz]

From the perspective of counterparty and the overall bitcoin community,

• The criticism is not against counterparty, but just One Flaw in the system
• There was zero consultation on the design with the wider community before the "on" switch was flipped
• This flaw --network-critical database used for raw data storage-- was well known before Counterparty began life. You could have avoided this problem with communication.
• Existing designs are known to be less abusive to the network, and do not store data in that key database

It is perfectly possible to run counterparty without this flaw.

It is perfectly possible to run Counterparty without storing data in the blockchain directly, yes. But there is no flaw in the possibility of doing so, and all the explanations that have been given for why it is 'abusive' or a 'problem' use circular logic. It's even misleading to call it 'raw data': it's not GIFs or tweets or anything like that---it's transaction data, just transaction data that Bitcoin itself doesn't parse.

We are adding (a great deal of) functionality to Bitcoin, and paying whatever fees miners ask for it. All of the outputs we are generating are spendable and prunable. We are doing our best to help Bitcoin (and users of Bitcoin), which has enormous potential beyond its current abilities.

I would like to see a thorough, direct and well thought answer to this. No circular logic, dodging or half answers. Please check the hyperbole and rhetoric at the door and answer to the core of this issue.

[halfcab123]

From the perspective of counterparty and the overall bitcoin community,

• The criticism is not against counterparty, but just One Flaw in the system
• There was zero consultation on the design with the wider community before the "on" switch was flipped
• This flaw --network-critical database used for raw data storage-- was well known before Counterparty began life. You could have avoided this problem with communication.
• Existing designs are known to be less abusive to the network, and do not store data in that key database

It is perfectly possible to run counterparty without this flaw.

It is perfectly possible to run Counterparty without storing data in the blockchain directly, yes. But there is no flaw in the possibility of doing so, and all the explanations that have been given for why it is 'abusive' or a 'problem' use circular logic. It's even misleading to call it 'raw data': it's not GIFs or tweets or anything like that---it's transaction data, just transaction data that Bitcoin itself doesn't parse.

We are adding (a great deal of) functionality to Bitcoin, and paying whatever fees miners ask for it. All of the outputs we are generating are spendable and prunable. We are doing our best to help Bitcoin (and users of Bitcoin), which has enormous potential beyond its current abilities.

I would like to see a thorough, direct and well thought answer to this. No circular logic, dodging or half answers. Please check the hyperbole and rhetoric at the door and answer to the core of this issue.

+( sideways 8 )

[BitcoinTangibleTrust]

Think about it.  Mastercoin is a competitor to Counterparty.  Mastercoin is already aware of, and working on solving this storage-in-multisig problem.

Peter Todd's proposal simultaneously (a) benefits Mastercoin, (b) disadvantages Counterparty, and (c) presents a proposal that portions of the developer and mining community already find agreeable.

Thanks Jeff. This is very helpful data. I was not aware of Peter's proposal and I have emailed him and asked him to respond here. It appears that Peter is also employed by Counterparty so he may be able to share some further insights about his proposal and how Counterparty may participate and add to the interests of both the bitcoin developer and bitcoin mining communities. It's in our interest to support proposals that everyone finds agreeable.

I believe the post Jeff is referring to is this one: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

However, anyone please correct me if that's the wrong thread?

EDIT: Peter's follow-up reply is here: https://bitcointalk.org/index.php?topic=395761.msg5824079#msg5824079

[xnova]

So the question becomes: Should we let people store data in multisig transactions or provide a cleaner way to do it?

A less abusive way was already provided.

With OP_RETURN, the data is still in the blockchain, but at least it is not in the UTXO database of unspent outputs like Generation-1 mastercoin/counterparty designs.

If the desire is for these projects to use OP_RETURN, as it seems you are stating here, then why personally introduce a pull request (https://github.com/bitcoin/bitcoin/pull/3737) to reduce its size down to 40 bytes, which makes it that much less useful to the projects that were to be some of its biggest users in the first place? And then, for justification of the change, provide reasons that have nothing to do with how these projects are actually storing data (i.e. we don't use hashes and side-chains for reasons we explained earlier).

The blockchain itself would be most benefited by the use of OP_RETURN here, but it seems to me at least that there is a disconnect in the logic of why the size was halved among some, pointing to theoretical reasons as justification on why that would be a good idea instead of the *actual real world current uses*. While the optimal solution in your mind for Counterparty and others may be to move to their own side chains and store hashes in the Bitcoin blockchain using OP_RETURN, you have to understand that doing so is highly complex, rife with potential security issues, and that the only evidence supporting this is (as far as I know) essentially a theoretical-type thread on the Bitcoin developers mailing list. This would be a bit like me telling the Bitcoin devs that Bitcoin should move to using GHOST (https://eprint.iacr.org/2013/881.pdf) immediately as it's technically the optimal solution over the longer block times today. While the latter could be argued to be the case, it is a proposal that has not been fully vetted in the real world, and would introduce major protocol-level changes that could cause potential security and usability problems.

Jeff, our intentions are be good stewards of the blockchain, while accomplishing our goals of adding valuable financial functionality to Bitcoin in a stable, scalable and secure manner. This whole OP_RETURN thing is like saying you have a great feature that would solve a need, but that no one should actually use it.

[bitwhizz]

I just had an hypothetical  idea in an aplocalyptic situation if XCP needed to relocate, if XCP was to move to a new database, it would need to create a completely new currency, meaning more units of value would need to burned (if using proof of burn), that would be unfair to everyone holding XCP and burned/traded . I think the best thing to do would be a 'proof of swap'  (hope i coin this term), in which the XCP can be swapped for the new currency which doesn;t rely on multi sig on this database, and thats the proof issuance,

[LightedLamp]

https://i.imgur.com/KZAZNzv.jpg

[PhantomPhreak]

I just had an hypothetical  idea in an aplocalyptic situation if XCP needed to relocate, if XCP was to move to a new database, it would need to create a completely new currency, meaning more units of value would need to burned (if using proof of burn), that would be unfair to everyone holding XCP and burned/traded . I think the best thing to do would be a 'proof of swap'  (hope i coin this term), in which the XCP can be swapped for the new currency which doesn;t rely on multi sig on this database, and thats the proof issuance

If we ever absolutely had to move to a different blockchain, the protocol would just freeze, save and then transfer balances over. The currencies of Counterparty, i.e. the balances, are independent of the protocol's transport layer.

[xnova]

Isn't Peter Todd working on Mastercoin? Why would he propose that?

Think about it.  Mastercoin is a competitor to Counterparty.  Mastercoin is already aware of, and working on solving this storage-in-multisig problem.

Peter Todd's proposal simultaneously (a) benefits Mastercoin, (b) disadvantages Counterparty, and (c) presents a proposal that portions of the developer and mining community already find agreeable.

Isn't Peter Todd also employed by Counterparty? https://www.counterparty.co/sergio-lerner-peter-todd/

Maybe the devs at Counterparty should learn Peter's proposal and we explore how we might participate to benefit alongside Mastercoin?

I don't get Jeff's point here. Even assuming that this is the case, any product of this would have to become public knowledge in the form of source code at some point, to be actually used. At that point, Mastercoin (as an open source project) would have lost their advantage here.

Also, this assertion is questionable as we are working with Peter as well. I don't want to speak for him (and he can correct me if I am wrong here), but he has communicated to us that in the end, his desires lie in moving the technology itself forward over allegiances to any specific implementations of it (for Counterparty OR Mastercoin).