[bitcoin-dev] Three hardfork-related BIPs

Peter Todd pete at petertodd.org
Sat Jan 28 18:29:32 UTC 2017

On 28 January 2017 02:36:16 GMT-08:00, Natanael via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" <
>bitcoin-dev at lists.linuxfoundation.org>:
>Satoshi envisioned a system where full nodes could publish proofs of
>blocks that would be automatically verified by SPV nodes and used to
>even they maintained the equivalent of full node security so long as
>not isolated. But as a matter of fact, this vision has proven
>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
>node, and therefore the plan of only having full nodes in datacenters
>simply not realistic without transforming Bitcoin into a centralised
>Beside Zero-knowledge proofs, which is capable of proving much so more
>just validity, there are multi types of fraud proofs that only rely on
>format of the blocks. Such as publishing the block header + the two
>colliding transactions included in it (in the case of double spending),
>if the syntax or logic is broken then you just publish that single

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 500 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170128/03b7306f/attachment.sig>

More information about the bitcoin-dev mailing list