Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.181 as permitted sender)
	client-ip=209.85.223.181; envelope-from=pieter.wuille@gmail.com;
	helo=mail-ie0-f181.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAE-z3OU0Y=ifGdaMKkSEJr38Rhq6pNfDeSUxF=ROiJ_0j3wh9Q@mail.gmail.com>
References: <CANEZrP04O7EqB=TqyTiC7O1K2A9R0nKJ_ssANHKg=Byum8-LtA@mail.gmail.com>
	<CA+s+GJDbYjwhpsV15a+7kCO_vTstEewVrwvqbnB=a5zOSwFC6Q@mail.gmail.com>
	<CAAS2fgStmEpiUV4Yh-qqu6sZ+VZ5SiQPwp+QA=3X5zR52ia3OA@mail.gmail.com>
	<CA+s+GJBxEC2MifJQY5-vn2zSOHo-UOm8B1vYHHOfuxq26=VscQ@mail.gmail.com>
	<CAADm4BDDJkS_xdjUn=2Yzs4B0RXTvpzpd5Z_kDRorzrn1HWSng@mail.gmail.com>
	<CANEZrP1rPZYkTLmx5GOdj67oQAgFjeaF-LCKAXpg5XsEhXYFuQ@mail.gmail.com>
	<CAADm4BB8y=k_f7CG3tyX6ruWF0w3+hU2Szv7ajLp1x7KhS56GA@mail.gmail.com>
	<CAPg+sBg88Q1Ddwsvuk3-17wO=0DF7L1wtxx4mWUoiV1=cWKhEQ@mail.gmail.com>
	<CADu7o8PD4Wkgx_X_aOHXHe8UA-OE9v5YZ4boMrX7LDVu6agfpQ@mail.gmail.com>
	<CAPg+sBiRFJT6zC=7oMMzJuU-06oxgZ4Q-1kD+pCitw1JmAFs7Q@mail.gmail.com>
	<CAE-z3OU0Y=ifGdaMKkSEJr38Rhq6pNfDeSUxF=ROiJ_0j3wh9Q@mail.gmail.com>
Date: Thu, 10 Apr 2014 22:29:40 +0200
Message-ID: <CAPg+sBhNw9nL_dE3-GZA2Pwz-DKSE_igYgVjNdFL-vZdgW4SNw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Paul Rabahy <prabahy@gmail.com>
Subject: Re: [Bitcoin-development] Chain pruning
Precedence: list

On Thu, Apr 10, 2014 at 10:12 PM, Tier Nolan <tier.nolan@gmail.com> wrote:
> On Thu, Apr 10, 2014 at 7:32 PM, Pieter Wuille <pieter.wuille@gmail.com>
> wrote:
>>
>> If you trust hashrate for determining which UTXO set is valid, a 51%
>> attack becomes worse in that you can be made to believe a version of
>> history which is in fact invalid.
>
>
> If there are invalidation proofs, then this isn't strictly true.

I'm aware of fraud proofs, and they're a very cool idea. They allow
you to leverage some "herd immunity" in the system (assuming you'll be
told about invalid data you received without actually validating it).
However, they are certainly not the same thing as zero trust security
a fully validating node offers.

For example, a sybil attack that hides the actual best chain + fraud
proofs from you, plus being fed a chain that commits to an invalid
UTXO set.

There are many ideas that make attacks harder, and they're probably
good ideas to deploy, but there is little that achieves the security
of a full node. (well, perhaps a zero-knowledge proof of having run
the validation code against the claimed chain tip to produce the known
UTXO set...).
-- 
Pieter