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

[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

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.

thanks for clearing that up 

[1714961056]

1714961056

[1714961056]

1714961056

[1714961056]

1714961056

[1714961056]

1714961056

[1714961056]

1714961056

[Peter Todd]

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.

You realize I also work for Counterparty. You also know I CC'd them on my email where I proposed getting rid of bare CHECKMULTISIG to the bitcoin-security mailing list with regard to the sigop vulnerability I responsibly disclosed. (which I note that Gavin and others disclosed publicly on IRC a few hours later rather than responsibly fixing it) I notified Counterparty specifically to make sure they got the heads up that this may be an issue for them so they could upgrade their protocol. This is easily done - they might find my recent post on Embedded consensus system upgrade procedures useful. More generally re: blocking they might be interested in my research, such as Censorship-resistance via timelock crypto for embedded consensus systems and Mastercoin's way of embedding data in what looks to be valid pubkeys, among other things. FWIW my usual way of communicating to the Mastercoin developers has been to write up a public document so that everyone gets access to the results of my work; my agreement with everyone I work for is that for all IP both parties have the right to use the IP however they see fit, including public release.

My position with regard to competitors in the decentralized finance space is as follows:

I'll also point out that while Mastercoin is my main commitment, I have pre-existing obligations with Litecoin to implement a soft-fork upgrade they need, as well as improve the scalability of Litecoin - and by extension Bitcoin - with blockchain pruning. I'm also continuing my consulting work with Colored Coins, and recently agreed to work with Counterparty to do a security audit of their code and protocol. Of course, some people would question why Mastercoin's Chief Scientist is working with "the competition", but remember our real competition isn't each other, it's enormously larger field of centralized finance. I strongly believe that we have far more to gain by working with each other and growing the tiny field of decentralized finance in general then we have to gain by pointless in-fighting.

http://mastercointalk.org/index.php?topic=155.msg466#msg466

[zbx]

This is the point right here. *Of course* Bitcoin was never intended to store and transmit Counterparty tx data. Counterparty hadn't been invented yet! That's what makes all great technology so amazing: when people take it and use it for things you never even dreamed of.

[jgarzik]

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.

[Peter Todd]

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

+1

If anything I hope I've given the impression that I think all these "Blockchain 2.0" projects probably have terrible flaws in them right now. But flaws can be fixed, either by upgrades or starting over; what I care about is that something worthwhile is bound to emerge in the end. In the meantime I can bring value to these projects - that is earn my pay - by being independent and objective enough to give good advice and do good research. Which incidentally I think the Bitcoin developers are currently failing at themselves because they're too focused on their narrow use-case for Bitcoin as cheap transactions - take this advice to just resort to insecure centralization and/or easily attacked DHT's:

12:47 < gavinandresen> jgarzik: RE: mastercoin/OP_RETURN: what's the current thinking on Best Way To Do It?  Seems if I was to do it I'd just embed 20-byte RIPEMD160 hashes in OP_RETURN, and fetch the real data from a DHT or website (or any-of-several websites).  Blockchain as reference ledger, not as data storage.

Or for that matter the discussion around my post on Decentralized digital asset exchange with honest pricing and market depth.

Edit: To be clear, all this discussion about moving things like Counterparty to different independently or merge-mined blockchains as a "solution" to the "problem" of adding data to the blockchain is either mistaken or downright deceptive. Fact is these systems all get much better security by being embedded rather than independent. Decentralized consensus system security is a game of strength in numbers, and you want to be making use of the largest system you can afford. Merge-mining looks like a nice way to achieve that, but in reality just leaves you vulnerable to zero-marginal-cost attacks until you get the support of a large % of the total hashing power. A real world example of this is how Luke-Jr used Eligius to attack the merge-mined alt Coiledcoin. That leaves us with embedded consensus systems, and fortunately with Bitcoin only explicit blacklists have any hope of censoring their transactions rather than just making them a bit more expensive. (perhaps the even stronger requirement for explicit whitelists if my timelock crypto scheme can be made practical)

[bitexch]

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.

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.

[halfcab123]

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.

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.

I guess technically no one has to choose to upgrade right ?

[jgarzik]

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,

False. There is no protocol change being proposed.

[halfcab123]

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,

False. There is no protocol change being proposed.

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

[bitwhizz]

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,

False. There is no protocol change being proposed.

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.

 

[porqupine]

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,

False. There is no protocol change being proposed.

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

Either it's a proposal or a not very subtle threat, No?

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.

   

[halfcab123]

Something fishy going on here. ...

[jgarzik]

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.

[halfcab123]

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.

Phantom ? Thoughts ? Xnova?

[halfcab123]

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.

Phantom ? Thoughts ? Xnova?

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

[l4p7]

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

[PhantomPhreak]

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.

Phantom ? Thoughts ? Xnova?

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

There are subtle differences between changes to the Bitcoin protocol and the default rules of Bitcoind for relaying transactions.

bitexch's point still stands, however, as he was (as I understand it) using the word 'protocol' in a general sense.

These are all technical issues, and the questions are at the level of implementation details, not problems with Counterparty itself.

[Peter Todd]

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.

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

[Luke-Jr]

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