From: Jeff Garzik <jgarzik@exmulti•com>
To: Jordan Mack <jordanmack@parhelic•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Protocol extensions
Date: Sat, 17 Dec 2011 20:07:55 -0500 [thread overview]
Message-ID: <CA+8xBpc5ke2W7kc8NQr6nWrvNmB-AmBTC2uTTW3H+KqJLUpBcg@mail.gmail.com> (raw)
In-Reply-To: <4EED378A.8090303@parhelic.com>
On Sat, Dec 17, 2011 at 7:44 PM, Jordan Mack <jordanmack@parhelic•com> wrote:
> While using DHT for storage of the block chain is an intriguing concept,
> I do not see how it is feasible. As Gavin noted, DHT is a system that is
> difficult to impossible to guarantee against data loss or manipulation.
>
> Even if we found a way to store the block chain in DHT, how would
> transactions be verified? As Gavin noted, you could ask the network, but
> cannot necessarily trust the peers you are connected to. Verification of
> the full block chain allows the client to trust no one.
Well, the block chain data itself is internally self-validating. As
long as you know the latest block's hash -- a big "if" -- there is no
problem downloading all other block chain data from DHT or any other
untrusted source.
In a malicious case, you would notice latest-hash differs from
non-malicious and wind up downloading multiple chains, when walking
hashes backwards through a DHT/lookup table. So, a bit more work but
nothing fundamentally less secure _on a trust basis_.
Of course, I was focusing on data validation, which ignores other
factors such as DoS'ing the DHT.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
next prev parent reply other threads:[~2011-12-18 2:08 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-17 7:41 Eric Lombrozo
2011-12-17 13:13 ` Michael Grønager
2011-12-17 13:37 ` Christian Decker
[not found] ` <CABsx9T0puk3CWH1cfNHMSVEoCPaLJJWNJ+H5ObCERZrzMbrTyA@mail.gmail.com>
2011-12-17 19:06 ` Gavin Andresen
2011-12-17 21:49 ` theymos
2011-12-18 0:44 ` Jordan Mack
2011-12-18 1:07 ` Jeff Garzik [this message]
2011-12-18 1:27 ` Jordan Mack
2011-12-18 14:16 ` Andy Parkins
2011-12-18 17:09 ` theymos
2011-12-18 18:06 ` Alan Reiner
2011-12-18 18:47 ` Amir Taaki
2011-12-18 19:37 ` Jorge Timón
2011-12-17 19:28 ` Gregory Maxwell
2011-12-17 20:34 ` Christian Decker
2011-12-18 21:19 ` Stefan Thomas
2011-12-19 21:43 ` Jordan Mack
2011-12-20 9:10 ` Wladimir
2011-12-20 10:44 ` Nicolas Fischer
2011-12-21 0:47 ` Kyle Henderson
2011-12-21 8:50 ` Michael Grønager
2011-12-21 11:42 ` Eric Lombrozo
2011-12-21 12:41 ` Michael Grønager
2011-12-21 16:10 ` Christian Decker
2011-12-22 9:18 ` Michael Grønager
2011-12-22 10:12 ` Andy Parkins
2011-12-22 10:27 ` Michael Grønager
2011-12-22 11:52 ` Andy Parkins
2011-12-22 12:14 ` Joel Joonatan Kaartinen
2011-12-22 12:26 ` Christian Decker
2011-12-22 12:42 ` Michael Grønager
2011-12-22 14:46 ` Andy Parkins
2011-12-25 2:55 ` Zell Faze
2011-12-21 17:17 ` Jordan Mack
2011-12-22 9:19 ` Michael Grønager
2011-12-21 6:19 Eric Lombrozo
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=CA+8xBpc5ke2W7kc8NQr6nWrvNmB-AmBTC2uTTW3H+KqJLUpBcg@mail.gmail.com \
--to=jgarzik@exmulti$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jordanmack@parhelic$(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