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

[Peter Todd]

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.

Exactly! I'm glad you realize this.

[1715279048]

1715279048

[1715279048]

1715279048

[1715279048]

1715279048

[1715279048]

1715279048

[Matt Y]

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.

I'm in a similar situation. What I've done is kept all my XCP in a Blockchain.info account to help limit risk. Once Counterwallet is out, I will move my XCP there, then move back any XCP I don't need immediate access to, to Blockchain.info. Alternatively, I will learn how to store XCP locally and move them from Counterwallet to an offline machine.

[TheMightyX]

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

Threat? or profound farewell?

[maaku]

As I said in the text you quoted, a filtered average over previous blocks 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.

Pay attention to the bolded words.

[mal_awer]

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.

I'm in a similar situation. What I've done is kept all my XCP in a Blockchain.info account to help limit risk. Once Counterwallet is out, I will move my XCP there, then move back any XCP I don't need immediate access to, to Blockchain.info. Alternatively, I will learn how to store XCP locally and move them from Counterwallet to an offline machine.

I am in similar situation too. The wait for counterwallet is getting longer and longer

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

I'm in a similar situation. What I've done is kept all my XCP in a Blockchain.info account to help limit risk. Once Counterwallet is out, I will move my XCP there, then move back any XCP I don't need immediate access to, to Blockchain.info. Alternatively, I will learn how to store XCP locally and move them from Counterwallet to an offline machine.

I am in similar situation too. The wait for counterwallet is getting longer and longer

What are our current options?  Can we send our XCP to a normal BTC address and store it there?

[mal_awer]

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.

I'm in a similar situation. What I've done is kept all my XCP in a Blockchain.info account to help limit risk. Once Counterwallet is out, I will move my XCP there, then move back any XCP I don't need immediate access to, to Blockchain.info. Alternatively, I will learn how to store XCP locally and move them from Counterwallet to an offline machine.

I am in similar situation too. The wait for counterwallet is getting longer and longer

What are our current options?  Can we send our XCP to a normal BTC address and store it there?

Yes we can send our XCPs to any BTC address and store them there

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

I'm in a similar situation. What I've done is kept all my XCP in a Blockchain.info account to help limit risk. Once Counterwallet is out, I will move my XCP there, then move back any XCP I don't need immediate access to, to Blockchain.info. Alternatively, I will learn how to store XCP locally and move them from Counterwallet to an offline machine.

I am in similar situation too. The wait for counterwallet is getting longer and longer

What are our current options?  Can we send our XCP to a normal BTC address and store it there?

Yes we can send our XCPs to any BTC address and store them there

I'm sorry to press on this further but I want to be sure I don't send my XCP into oblivion.  If I control a BTC address then I will be able to control the XCP there too?  There isn't anything else I need to do besides control the BTC address where I send the XCP?

[mal_awer]

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.

I'm in a similar situation. What I've done is kept all my XCP in a Blockchain.info account to help limit risk. Once Counterwallet is out, I will move my XCP there, then move back any XCP I don't need immediate access to, to Blockchain.info. Alternatively, I will learn how to store XCP locally and move them from Counterwallet to an offline machine.

I am in similar situation too. The wait for counterwallet is getting longer and longer

What are our current options?  Can we send our XCP to a normal BTC address and store it there?

Yes we can send our XCPs to any BTC address and store them there

I'm sorry to press on this further but I want to be sure I don't send my XCP into oblivion.  If I control a BTC address then I will be able to control the XCP there too?  There isn't anything else I need to do besides control the BTC address where I send the XCP?

Yes, if you control BTC, you control XCP. But if you want to move XCPs out of BTC address, you need to install counterpartyd and follow a lengthy process.

If you are unsure send a fraction of an XCP from exchange to BTC address and test it

[GLaDOS]

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.

We'd have to wait for an actual P2SH^2 implementation.
But from the P2SH^2 discussion, it looks like the data would be relayed/published along with the P2SH^2 even though it will not be not stored.

Just like P2SH, we'd be pushing transactional data from one end to the other only to add even more bloat in the end.  One of the reasons given to deter OP_RETURN was that blockchain bloat would further reduce the economic incentive for full nodes.  It's a bit absurd since there's very little economic incentives for full nodes now.  The fees only go to the miners.

As the blockchain grow and grow, the only incentives for full nodes may actually come from projects on top of Bitcoin such as the current MsC/XCP crowds.

[maaku]

We'd have to wait for an actual P2SH^2 implementation.
But from the P2SH^2 discussion, it looks like the data would be relayed/published along with the P2SH^2 even though it will not be not stored.

No, only the intermediate hash.

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

Exactly! I'm glad you realize this.

Thanks for the tip!  

I'm still working on figuring out your earlier riddle.  The question "Does data need to be stored forever to prove it was published once?" seems like it might be a ninja question.  First off, I'm going to assume that you're not trying to play a trick with the wording.  The above sentence can be diagrammed different ways; what does the "once" apply to?  I'm going to assume that you mean you want to be able to "prove" it forever and not just once.  "Forever" means "at any arbitrary time in the future".  "Once" denotes the original date of publishing.

My answer is "Of course it does!"  Because the hash was created to prove something, and you have to have that "something" there in front of you in order for the hash to be a valid proof (so it has to be stored somewhere permanently, although of course this doesn't have to be the blockchain).  The hash by itself doesn't prove jack.  It's just a series of random letters and numbers that might or might not be connected with anything.  A hash-proof is a two-way street; the hash validates the "something", and the "something" validates the hash.

EDIT: So any time you want to verify, you have to have both the original "something" and the hash, simultaneously.  The "something" can be published first and the hash published later, or the hash can be published first and the "something" published later.  But both must be accessible simultaneously in order to verify the hash.

For P2SH^2, the published hash is simply the hash of another hash.  Plain P2SH assumes that the "something" to be an original value with meaning (although I remain somewhat unclear as to what that actually is in the case of normal P2SH -- I know next to nothing about Bitcoin scripts), while P2SH^2 requires the "something" to be a hash of an original "something", although again it could simply be a random set of letters and numbers, and the original "something" never existed.  I have already shown how P2SH^2 could be attacked for arbitrary data storage, in a way which is not detectable or blacklist-able, albeit at potentially high transaction costs as well as requiring a tiny amount of hashpower.  With more hashpower and/or reusable addresses (i.e. no fear of blacklisting), the attack becomes cheaper in terms of transaction costs.

As I said in the text you quoted, a filtered average over previous blocks 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.

Pay attention to the bolded words.

How do you propose to filter?  Such an attacker could essentially "own" the market (90%+ of transactions) and nobody would be able to tell.  He could conduct the attack with numerous nodes, numerous single-use addresses, numerous IP's, numerous physical locations.  And it would be pretty cheap to do so.

[maaku]

How do you propose to filter?  Such an attacker could essentially "own" the market (90%+ of transactions) and nobody would be able to tell.  He could conduct the attack with numerous nodes, numerous single-use addresses, numerous IP's, numerous physical locations.  And it would be pretty cheap to do so.

He can only "own" the market of his own block. There are a variety of filters that could be used to remove the "noise" of an attacker - signal analysis is a field in itself. For the purpose of explanation, I will give a simple unsophisticated filter: take the median of the last N blocks. That is to say, for each block determine what the average price is of the market you are interested in, and then take the median of those values over the last N blocks. The attacker or cartel of attackers needs >50% of the hashrate in order to reliably affect the median value. Observe that an "attacking" block is one whose inferred pricing deviates substantially from the actual order book known by other miners due to wash trades, and that difference would be observable.

You can also think of this as a machine learning problem: you use unsupervised learning to group blocks into labeled buckets representing the underlying order book, and then choose the bucket which represents the most work over the last N blocks. You then compare that price structure with the orders you are seeing in the order-publication medium (p2p network, bitmessage, whatever) and decide whether you are being cheated or not.

[bitcoinrocks]

How can I send the XCP that I received for my 1BTC burn to another BTC address?  I conducted the burn via blockchain.info.

[BitzMD]

An off topic question here and excuse me if its ridiculous,

How does one transfer xcp from a central exchange to an offline wallet?

just send it to a btc address that you have control of the private key, XCP address = BTC address

XCP is great, but I think before any major innovations come, we need to see what is going on with OP_RETURN.

Once there is clear consensus, everyone will know where XCP is headed.
[/quoted]

if we are banned from every corner, I bet PP should be able to find a way to compress XCP into 32 bytes OP_RETURN in the worst case

Thank you for taking the time to answer my question.

I remembered t was to the tune of what you mentioned but just wanted to make sure.

[Peter Todd]

He can only "own" the market of his own block. There are a variety of filters that could be used to remove the "noise" of an attacker - signal analysis is a field in itself. For the purpose of explanation, I will give a simple unsophisticated filter: take the median of the last N blocks. That is to say, for each block determine what the average price is of the market you are interested in, and then take the median of those values over the last N blocks. The attacker or cartel of attackers needs >50% of the hashrate in order to reliably affect the median value. Observe that an "attacking" block is one whose inferred pricing deviates substantially from the actual order book known by other miners due to wash trades, and that difference would be observable.

We're talking about network-level sybil attackers; this isn't about hashing power.

You can also think of this as a machine learning problem: you use unsupervised learning to group blocks into labeled buckets representing the underlying order book, and then choose the bucket which represents the most work over the last N blocks. You then compare that price structure with the orders you are seeing in the order-publication medium (p2p network, bitmessage, whatever) and decide whether you are being cheated or not.

That's vastly more complex and unreliable than having proof-of-publication available. After all you don't have to use it exclusively, just enough to detect and discourage attackers. Note how if we create a H(prevout) based CHECKSIG mode where the txid is not hashed you can arrange for a completed trade to prevent publishing of the trade itself separately.

[Peter Todd]

We'd have to wait for an actual P2SH^2 implementation.
But from the P2SH^2 discussion, it looks like the data would be relayed/published along with the P2SH^2 even though it will not be not stored.

No, only the intermediate hash.

How do you know that hash is a hash?

[maaku]

We're talking about network-level sybil attackers; this isn't about hashing power.

That is what I'm talking about. How do you know if your view of the network is being constrained? By comparing with the most recent prices on the chain. Of course this is defense in depth as you'd also be using network-attack resistant networks like a bitmessage over tor and a proof-of-publication side chain for distributing orders.

We'd have to wait for an actual P2SH^2 implementation.
But from the P2SH^2 discussion, it looks like the data would be relayed/published along with the P2SH^2 even though it will not be not stored.

No, only the intermediate hash.

How do you know that hash is a hash?

What does that matter? You've proved that the data on the chain is a hash, not arbitrary data. At this point I think we're talking past each other...

[Peter Todd]

baddw & GLaDOS: You guys are really close; can you write up a clear description of how exactly a system like Counterparty could use P2SH^2 to achieve it's aim of proof-of-publication, given that we know storage of data is a separate issue?

It might help to try working through how P2SH^2 could be used for the more simple case of an announce/commit sacrifice first.

[Peter Todd]

That is what I'm talking about. How do you know if your view of the network is being constrained? By comparing with the most recent prices on the chain. Of course this is defense in depth as you'd also be using network-attack resistant networks like a bitmessage over tor and a proof-of-publication side chain for distributing orders.

Bitmessage isn't attack resistant whether or not it is used over Tor... As for your suggestion of a "proof-of-publication side chain", as always, it's a matter of security vs. cost. Just using Bitcoin itself gives you high security at relatively high cost. (though potentially not as high as you'd expect giving the complexity and inconvenience of getting coins to pay for a side-chain)

How do you know that hash is a hash?

What does that matter? You've proved that the data on the chain is a hash, not arbitrary data. At this point I think we're talking past each other...

Again, we're talking about proof-of-publication here, not data storage. As I suggested above, think through how the idea could be applied to announce/commit sacrifices.