1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1SeBSS-0003c0-Id
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Jun 2012 20:43:28 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.175 as permitted sender)
client-ip=209.85.216.175; envelope-from=gmaxwell@gmail.com;
helo=mail-qc0-f175.google.com;
Received: from mail-qc0-f175.google.com ([209.85.216.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SeBSQ-0005Zj-C4
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Jun 2012 20:43:28 +0000
Received: by qcso7 with SMTP id o7so2014866qcs.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 11 Jun 2012 13:43:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.188.7 with SMTP id cy7mr15971323qab.34.1339447400730; Mon,
11 Jun 2012 13:43:20 -0700 (PDT)
Received: by 10.229.144.205 with HTTP; Mon, 11 Jun 2012 13:43:20 -0700 (PDT)
In-Reply-To: <CANEZrP2TU3W08Pi7Wdw4rPYLHC=wesKtci8vopV8Hbi3eCMHcw@mail.gmail.com>
References: <CANEZrP3kOysjENpkHom5MHg0usq1jkQdEFAM3vuR1KgFAnJHhg@mail.gmail.com>
<CAAS2fgSB6--PzpnTrx_DXrwZ7uzXrTCH3a1aMVFmWPBNO6FuqA@mail.gmail.com>
<CANEZrP2TU3W08Pi7Wdw4rPYLHC=wesKtci8vopV8Hbi3eCMHcw@mail.gmail.com>
Date: Mon, 11 Jun 2012 16:43:20 -0400
Message-ID: <CAAS2fgQ7sspfZ+aBDhCj7Y+Dzmv1ku7u4wO=VUFVcBSuuTzo6Q@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SeBSQ-0005Zj-C4
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bootstrapping full nodes post-pruning
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 11 Jun 2012 20:43:28 -0000
On Mon, Jun 11, 2012 at 4:36 PM, Mike Hearn <mike@plan99.net> wrote:
> Unless BDB has some weird behaviour in it, that shouldn't require any
HAHAHA. Have you consider doing comedy full time?
Actual BDB files are absolutely not deterministic. Nor is the raw
blockchain itself currently, because blocks aren't always added in the
same order (plus they get orphans in them)
But the serious inter-version compatibility problems as well as poor
space efficiency make BDB a poor candidate for read only pruned
indexes.
> Even if a more complex scheme is used whereby commitments are in the
> block chain, somebody still has to verify the binaries match the
> source. If that isn't true, the software could do anything and you'd
> never know.
The binaries distributed by bitcoin.org are all already compiled
deterministically and validated by multiple independent parties. In
the future there will be a downloader tool (e.g. for updates) which
will automatically check for N approvals before accepting an update,
even for technically unsophisticated users.
This will produce a full chain of custody which tracks the actual
binaries people fetch to specific source code which can be audited, so
substitution attacks will at least in theory always be detectable. Of
course, you're left with Ken Thompson's compiler attack but even that
can be substantially closed.
|
