Post
Topic
Board Announcements (Altcoins)
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
by
jl777
on 30/03/2014, 23:12:37 UTC
No, it's not, it's a silly point.

Bitcoin includes transactions because it validates the data inside them.

Bitcoin clearly does not validate Counterparty data.  I am free to include Counterparty data in my own transactions at any time.  I am free to spend Counterparty coins to myself at any time, etc.  Bitcoin doesn't care.

The level of validation performed by the bitcoin network is the same, whether full counterparty data or a simple hash is in the blockchain.

Long answer: re-read my paper on about proof-of-publication and how Bitcoin mining really works.

Short answer: you're assuming the data exists to validate at all client-side. Unfortunately that's not something you can assume. If you're just putting hashes of Counterparty data in the blockchain what is a client supposed to do if they can't find the corresponding data? If they assume it doesn't exist then you can be sybil attacked by someone who later reveals the data and changes the consensus out from under you. On the other hand, if you assume it must exist, and wait until you find that data, a trivial attack is to put fake hashes of alleged counterparty data in the blockchain.

Now you can try using something like the zookeyv concept I wrote about in #bitcoin-wizards last summer - I remember you saved a copy of that discussion - but then you run into a simple economics problem: if you can attack an individual system in one go, the cost required for security is going to be very high compared to the cost per transaction. Thus it's best if you spread that cost across multiple systems/uses, and force any attacker to attack them all at once. Anyway, this is all pedantic: Counterparty gains enormously in security by using the Bitcoin blockchain, and there's fuck all that Bitcoin can do about it if the Counterparty devs encode their transactions correctly.

In fact, here's a really good test to see if you understand this stuff: Suppose P2SH^2 was implemented and everything other than pay-to-pubkey-hash transactions was disabled. How can embedded consensus systems take advantage of P2SH^2 to survive without resorting to the brute-forcing parts of the hash to encode the data and without resorting to using any data embedded in any part of the transaction other than the scriptPubKey? If you can guess why, you'll be a lot closer to understanding what proof-of-publication actually is; I'll give 50mBTC to the first person with a correct answer.(edit: unless your name is Gregory Maxwell! already told him) I'll give you some further hints: the solution in this scenario ends up creating huge amounts of unspendable outputs in the UTXO set, it is blocked by Gregory Maxwell's "P2SH^2 v2.0" idea where hashes can self-prove their hashes without proving a pre-image explicitly, and finally is actually cheaper for the embedded consensus system modulo the IsDust() rule.
Not commenting on the P2SH stuff, but generally speaking a single atomic operation is far more reliable than one that is split up into two parts, eg. hash and actual data.

XCP will be dealing with potentially big money transactions and it needs to be as reliable as possible. This means not splitting the transaction into parts.

I do not understand how anybody can claim that storing pointers is just as good, the math does not back that claim at all. Assuming that the bitcoin blockchain is the most reliable place to store data, by definition any other place is less reliable. This means there is a chance that the data wont be available. Therefore, it is worse to just store hash in the bitcoin blockchain.

I dont claim to be anywhere as knowledgeable as long time bitcoin core devs, but when they start saying stuff like "1+1 = 1", then it leads me to believe that they are not discussing math, but something else.

James