From: Pieter Wuille <pieter.wuille@gmail•com>
To: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>,
Paul Rabahy <prabahy@gmail•com>
Subject: Re: [Bitcoin-development] Chain pruning
Date: Thu, 10 Apr 2014 22:29:40 +0200 [thread overview]
Message-ID: <CAPg+sBhNw9nL_dE3-GZA2Pwz-DKSE_igYgVjNdFL-vZdgW4SNw@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OU0Y=ifGdaMKkSEJr38Rhq6pNfDeSUxF=ROiJ_0j3wh9Q@mail.gmail.com>
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
next prev parent reply other threads:[~2014-04-10 20:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-10 11:37 Mike Hearn
2014-04-10 11:57 ` Wladimir
2014-04-10 12:10 ` Gregory Maxwell
2014-04-10 14:19 ` Wladimir
2014-04-10 16:23 ` Brian Hoffman
2014-04-10 16:28 ` Mike Hearn
2014-04-10 16:47 ` Brian Hoffman
2014-04-10 16:54 ` Ricardo Filipe
2014-04-10 16:56 ` Brian Hoffman
2014-04-10 16:59 ` Pieter Wuille
2014-04-10 17:06 ` Brian Hoffman
2014-04-10 18:19 ` Paul Rabahy
2014-04-10 18:32 ` Pieter Wuille
2014-04-10 20:12 ` Tier Nolan
2014-04-10 20:29 ` Pieter Wuille [this message]
2014-04-10 19:36 ` Mark Friedenbach
2014-04-10 21:34 ` Jesus Cea
2014-04-10 22:15 ` Mark Friedenbach
2014-04-10 22:24 ` Jesus Cea
2014-04-10 22:33 ` Gregory Maxwell
2014-04-10 16:52 ` Ricardo Filipe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPg+sBhNw9nL_dE3-GZA2Pwz-DKSE_igYgVjNdFL-vZdgW4SNw@mail.gmail.com \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=prabahy@gmail$(echo .)com \
--cc=tier.nolan@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox