Date: Sat, 28 Jan 2017 18:29:32 +0000
In-Reply-To: <CAAt2M183=L=9N3HKVgGbsFbug4LWkGfMQzzcDQu9xxMJL+L1oA@mail.gmail.com>
References: <201701270107.01092.luke@dashjr.org> <20170127212810.GA5856@nex>
	<CAAy62_KUSNTjivwJT87K9f1c=k-6gdaLXEBJjcy2KK+uLSTWDA@mail.gmail.com>
	<201701280403.05558.luke@dashjr.org>
	<CAAt2M183=L=9N3HKVgGbsFbug4LWkGfMQzzcDQu9xxMJL+L1oA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/signed; boundary="----WBMA1F7SJOO6FKDF7QIWA1G4Z1SPBW"; 
	protocol="application/pgp-signature"; micalg="pgp-sha512"
To: Natanael <natanael.l@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Natanael via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
	Luke Dashjr <luke@dashjr.org>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
From: Peter Todd <pete@petertodd.org>
Message-ID: <A6A9E83E-6A5A-4583-A4E3-A52DF33DCF4F@petertodd.org>
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
Precedence: list

------WBMA1F7SJOO6FKDF7QIWA1G4Z1SPBW
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
 charset=utf-8



On 28 January 2017 02:36:16 GMT-08:00, Natanael via bitcoin-dev <bitcoin-d=
ev@lists=2Elinuxfoundation=2Eorg> wrote:
>Den 28 jan=2E 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" <
>bitcoin-dev@lists=2Elinuxfoundation=2Eorg>:
>
>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=2E 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=2E 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=2E
>
>
>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=2E 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=2E

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 necessa=
ry to prove the fraud in the first place=2E

What you actually need are validity challenges, where someone makes a chal=
lenge claiming that part of the block is invalid=2E A failure to meet the c=
hallenge with proof that the rules are followed is considered defacto evide=
nce of fraud=2E

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=2E Even if val=
idity challenges work, they also don't solve censorship: a world of nodes i=
n large datacenters is a world where it's very easy to force the few Bitcoi=
n nodes remaining to follow AML/KYC rules for instance, a risk we wouldn't =
be able to mitigate with a PoW change=2E
------WBMA1F7SJOO6FKDF7QIWA1G4Z1SPBW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQE9BAABCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJYjOMM
AAoJEGOZARBE6K+yz4MH/iL2PdngP5Z2aKGi6BbafcnlMqGfGGcNiXQAsth7skmp
vDW7qj2YsCYpDbv9YzvcUAfRBFzr1y/pgPfaH++vtoe6E0JXKPL3uq9897ztK9oS
HQsB0wnY3cz8YndOPYTuGq3RyUV4F80naiPD3uaybSFnwFYdBua/vXiSbMEgRBai
KHopVxuqmYBWo8XPaot3Ezo4zNooyXWD/1EcewrwMU2VCw6XPmYhoDMcaSaZNQGk
c9fvTazrWwQce2zJ81ouMaO6Z3tqxUYnKg2vB/iWZVXVU6fc9ENOCjajfHy/Gdnq
I88tg+uinWH2mh1AkGwDEmPg0l2y4B2aSIPF7o6kwvY=
=2eLt
-----END PGP SIGNATURE-----

------WBMA1F7SJOO6FKDF7QIWA1G4Z1SPBW--