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

[Peter Todd]

Except... it's not built on bitcoin. That's exactly the gripe of myself, jtimon, and others I'm sure. Counterparty does not interoperate with bitcoin scripting. You cannot have bidirectional transactions between the two. Counterparty rules are not validated by bitcoin nodes. Lightweight clients can't rely on most-work as an indicator of validity. Counterparty is built separate from bitcoin. If I take a bible and start scribbling in the margins, do I get to go on a pulpit and claim a biblical foundation for my scribbled theories? No, it has no relevance.

Counterparty does in fact interoperate with Bitcoin scripting in that you can add conditions to a transaction in the form of Bitcoin scripts - the transaction can only go through if the Bitcoin script evaluates true. I know for a fact that this is used in Mastercoin to allow for atomic Mastercoin<->Bitcoin trades in the decentralized marketplace functionality; I'm sure Counterparty works similarly. Further exploring how to exploit this is on my TODO list, as is adding scripting functionality to Mastercoin itself. (though I'm in no particular rush to do so - my TODO list is rather long!)

Counterparty transactions are scribbled in the margins of validated bitcoin transactional data. So what? Bitcoin does gain from this. Counteryparty doesn't gain from this, any more than they would from a fully merged-mined datachain or any other equivalently powerful proof-of-publication sytem. And Counterparty could be doing much better by having miners which validate its transactional data.

I've said this over and over: Counterparty gains security from this. Client-side validation means you can't be harmed by malicious miners; merge-mining means you can be at nearly zero cost to those miners. We only have to look at Coiledcoin to see why this matters.

As for the inefficiency, yes, currently the global state of the Mastercoin and Counterparty consensus is implemented inefficiently, which is why I'm working on examining how to improve on that with compact proofs of coin validity for Bitcoin. I'm pretty confident that at least linear scaling is possible with simple math using non-interactive proofs, better than linear with "moon-math". There are many ways to apply that research to embedded consensus systems.

In the meantime I'm glad Mastercoin and Counterparty are exploring a huge set of other considerations related to the design of "decentralized finance 2.0" systems.

[1714737892]

1714737892

[1714737892]

1714737892

[1714737892]

1714737892

[Peter Todd]

The opposite of over-engineering is under-engineering.  Creating the least viable product.  The most minimal, simple implementation that can do what you want it to do.  Counterparty is this solution for the distributed exchange/Bitcoin 2.0 idea.  It works, today.  It does so by leveraging the existing Bitcoin network and protocol, which allows the developers to devote their time to getting the important parts right.  How much would the Counterparty codebase increase in size if it required its own blockchain?  I'm betting it would be somewhere in the triple to quadruple range.  Counterparty will continue to work for at least the near future.  If a day comes when it is made not to work by outside forces, Counterparty will change in order to work.

Actually that's incorrect: Counterparty and Mastercoin both have a significantly larger codebase by not requiring their own blockchain. Of course when I say "larger codebase" I mean the code required above and beyond the Satoshi codebase itself. Freimarkets is an example of a system that took the opposite approach of reusing the Satoshi codebase and requiring its own blockchain, and by doing so it got to reuse blockchain-related code from the Satoshi codebase that Counterparty and Mastercoin had to implement themselves. Of course, what they implemented is more simple than reimplementing blockchain code from scratch, but their approach is definitely not the "least-work" way of doing so; Freimarkets is.

But if "what you want it to do" is to be secure against attackers, then the minimum viable product has to be an embedded system as opposed to independent or merge-mined and you're stuck writing embedded-consensus blockchain code.

[appanmai]

Pathetic trade volume in BTER and poloniex.

[crypto era]

Hey I finally have BTC to buy XCP. I couldn't find the buy\sell thread. Buying 1000 xcp for 4 bitcoin. Any amount is fine. any method is fine. PM me.

EDIT: I found the buy thread.

[dpb]

why couldn't you use bitcoins directly given that you're already on
the same chain?

You can, but a trade involving bitcoin requires an extra transaction to send the funds; trades between XCP and an asset or between an asset and another asset can be completed with only two transactions.

Thank you for the clarification. So the functions it provides is to be the only p2p currency that can be traded in 2 transactions instead of 3 with other assets.
2 transactions is too much, it is possible to do the trade with one transaction if your chain explicitly validates the asset issuance rules.

It's impossible to make a trade in less than 2 steps.

• Step one: somebody publishes an offer
• Step two: somebody accepts the offer

A trade with only one step is better known as theft.

[maaku]

Except that the offer doesn't have to be published on-chain until the trade occurs. You could simply publish the bid and the ask at the same time to get single-step (from the chain's perspective) trades, and use some external mechanism such as the p2p network or bitmessage to move orders. This is what Freimarkets does.

[Peter Todd]

Except that the offer doesn't have to be published on-chain until the trade occurs. You could simply publish the bid and the ask at the same time to get single-step (from the chain's perspective) trades, and use some external mechanism such as the p2p network or bitmessage to move orders. This is what Freimarkets does.

Without a proof-of-publication system where you're guaranteed (with high probability) that your offer either gets to a well-defined audience or you find out you're being jammed you're vulnerable to getting ripped: http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg03892.html If Freimarkets doesn't have that guarantee then it's insecure against sybil attacks, and worse, such attacks are profitable.

[kdrop22]

From my point of view:
(please excuse the table, these forums don't provide much functionality)

PoW BTC Pros PoS CP Pros Large amount of hashing power to ensure security Early mover adoption advantage (fairly widespread) Piggyback on media exposure Legitimacy boost (via bitcoin legitimacy) Can switch between BTC and XCP without exchange Large amount of hashing power unnecessary (more security from less energy) Environmentally friendly (forward thinking) Blazing fast transactions As much OP_return space as we need No large blockchain to turn away early adopters Instead of designing the protocol to work within the scope of bitcoins protocol, we have the freedom to develop without limits IN CONTROL OF OUR OWN DESTINY PoW BTC Cons PoS CP Cons Slow Transactions Must buy BTC to use XCP (just one more middleman to go through) Paying tx fees to third party (instead of ourselves) Must sync non-CP related transactions (13GB blockchain at start) At mercy of bitcoin developer whims (Protocol could be rendered invalid without notice) NOT IN CONTROL OF OUR OWN DESTINY Can't switch between BTC and XCP as easily (must use an exchange) I honestly can't think of any other downside (security was the only real downside mentioned and that point is moot with a PoS blockchain isn't it?)

+1
Nice, analysis. Something we should keep in mind if and when the time comes for the move off the bitcoin blockchain.

[maaku]

Peter, I don't think that's fair or accurate. Anyone observing the chain gets proof of publication of matched orders, and a filtered average over the last N blocks gives you a relatively good idea of the current price in a secure way which you can compare with what you're seeing on the wire. Additionally, such a setup does not rule out the possibility of other proof-of-publication systems being used for distributing the orders. It simply recognizes that consensus over matched trades and consensus over open orders are logically distinct, and data from one need not clog up the other.

[GLaDOS]

...
You guys are still all missing a even deeper implication of P2SH^2. I'll give you another hint: Does data need to be stored forever to prove it was published once?

I think you just need to have proof that it's been seen/published before

So P2SH^2 makes it hard to publish data by requiring another hash.
If we can't send data directly via P2SH^2, we could still reveal our data in the actual script later on.
Once the data is seen elsewhere (like in the script to redeem), we can then look at the previously confirmed P2SH^2 txn for the proof.

[iwillimust]

We don't even have an acceptable logo yet though right ?

When it brings us benefits, but also with the pipe he has no marks, or right?
 

It seems that you have tasted the sweetness of
Hope is what successful experience to share
Hope to make friends with you

[zero3112]

How does the output 80 tx reduced to 40 or something effect Counterparty?

[Peter Todd]

Peter, I don't think that's fair or accurate. Anyone observing the chain gets proof of publication of matched orders, and a filtered average over the last N blocks gives you a relatively good idea of the current price in a secure way which you can compare with what you're seeing on the wire. Additionally, such a setup does not rule out the possibility of other proof-of-publication systems being used for distributing the orders. It simply recognizes that consensus over matched trades and consensus over open orders are logically distinct, and data from one need not clog up the other.

As I pointed out on the mailing list observing the chain for matched orders tells you nothing about whether or not those orders were ever published; that is, whether or not they're entirely fake and don't represent actual market depth. It's the same logic that came up in the discussion about announce/commit sacrifices. As for "other systems", remember that I did recently publish Tree Chains specifically to act as a general purpose proof-of-publication system for all uses with highly adjustable security/scalability tradeoffs.

[Peter Todd]

...
You guys are still all missing a even deeper implication of P2SH^2. I'll give you another hint: Does data need to be stored forever to prove it was published once?

I think you just need to have proof that it's been seen/published before

So P2SH^2 makes it hard to publish data by requiring another hash.
If we can't send data directly via P2SH^2, we could still reveal our data in the actual script later on.
Once the data is seen elsewhere (like in the script to redeem), we can then look at the previously confirmed P2SH^2 txn for the proof.

You're close, but still misunderstanding it.

With P2SH^2 when is the data hashed by the script first published? Remember that P2SH^2 is distinct from regular P2SH.

[kkangjji22]

...
You guys are still all missing a even deeper implication of P2SH^2. I'll give you another hint: Does data need to be stored forever to prove it was published once?

I think you just need to have proof that it's been seen/published before

So P2SH^2 makes it hard to publish data by requiring another hash.
If we can't send data directly via P2SH^2, we could still reveal our data in the actual script later on.
Once the data is seen elsewhere (like in the script to redeem), we can then look at the previously confirmed P2SH^2 txn for the proof.

Thank you for telling us
You are a good man
Good luck to you
You will be ded

[zero3112]

Why should I buy 1 BTC of this coin instead of Mastercoin or Ethereum?

You forgot protoshares, and coloredcoins too.

[maaku]

As I pointed out on the mailing list observing the chain for matched orders tells you nothing about whether or not those orders were ever published; that is, whether or not they're entirely fake and don't represent actual market depth.

As I said in the text you quoted, a filtered average over previous block solves this. Unless you are assuming the attacker has majority hashrate, in which case you're screwed anyway.

It's the same logic that came up in the discussion about announce/commit sacrifices. As for "other systems", remember that I did recently publish Tree Chains specifically to act as a general purpose proof-of-publication system for all uses with highly adjustable security/scalability tradeoffs.

Yes, and that would be a decent basis for a proof of publication system for orders. You could even shard based on market pairing so that people only have to validate what they're interested in. But validation of of the trades themselves should be separate, to achieve better scaling properties.

[baddw]

As I pointed out on the mailing list observing the chain for matched orders tells you nothing about whether or not those orders were ever published; that is, whether or not they're entirely fake and don't represent actual market depth.

As I said in the text you quoted, a filtered average over previous block solves this. Unless you are assuming the attacker has majority hashrate, in which case you're screwed anyway.

An attacker who wanted to give a false impression of market depthactivity and/or prices could simply publish completed transactions to himself on the blockchain and have nothing to do with the mining process.  These transactions would never be propagated as unfilled orders on the network, only as completed transactions.  Forcing unfilled orders to propagate through the network, and be published in the blockchain, ensures that these orders are real, as they could be matched and filled by anybody.

[TheMightyX]

nodes still nodulate

Theres a word you don't hear every day 

...and needlessly detrimental to Bitcoin.

Oh dear lord, hear we go again 

[bitcoinrocks]

I have some XCP on blockchain.info from when I burned 1BTC and I have a lot in an exchange.  Would it be wise to consolidate all of it under my own BTC address where I have all of my BTC?  Is that done by withdrawing my XCP from blockchain.info and the exchange to my BTC wallet address?  I don't want to screw this up.