Subject: Re: [bitcoin-dev] Three hardfork-related BIPs

From: Peter Todd <[email-masked]>
Date: Sat, 28 Jan 2017 18:29:32 +0000

On 28 January 2017 02:36:16 GMT-08:00, Natanael via bitcoin-dev <[email-masked]> wrote:
>Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" <
>[email-masked]>:
>
>Satoshi envisioned a system where full nodes could publish proofs of
>invalid
>blocks that would be automatically verified by SPV nodes and used to
>ensure
>even they maintained the equivalent of full node security so long as
>they
>were
>not isolated. But as a matter of fact, this vision has proven
>impossible,
>and
>there is to date no viable theory on how it might be fixed. As a
>result, the
>only way for nodes to have full-node-security is to actually be a true
>full
>node, and therefore the plan of only having full nodes in datacenters
>is
>simply not realistic without transforming Bitcoin into a centralised
>system.
>
>
>Beside Zero-knowledge proofs, which is capable of proving much so more
>than
>just validity, there are multi types of fraud proofs that only rely on
>the
>format of the blocks. Such as publishing the block header + the two
>colliding transactions included in it (in the case of double spending),
>or
>if the syntax or logic is broken then you just publish that single
>transaction.

That's a perfect example of why fraud proofs aren't as secure as expected: the miner who created such a block wouldn't even give you the data necessary to prove the fraud in the first place.

What you actually need are validity challenges, where someone makes a challenge claiming that part of the block is invalid. A failure to meet the challenge with proof that the rules are followed is considered defacto evidence of fraud.

But validity challenges don't scale well and pose DoS attacks issues; it's far from clear that they can be implemented in a useful way. Even if validity challenges work, they also don't solve censorship: a world of nodes in large datacenters is a world where it's very easy to force the few Bitcoin nodes remaining to follow AML/KYC rules for instance, a risk we wouldn't be able to mitigate with a PoW change.