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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1Se6is-0003y1-1U
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Jun 2012 15:40:06 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.47 as permitted sender)
client-ip=209.85.216.47; envelope-from=gmaxwell@gmail.com;
helo=mail-qa0-f47.google.com;
Received: from mail-qa0-f47.google.com ([209.85.216.47])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Se6im-0004PP-MH
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Jun 2012 15:40:06 +0000
Received: by qabg1 with SMTP id g1so2143191qab.13
for <bitcoin-development@lists.sourceforge.net>;
Mon, 11 Jun 2012 08:39:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.115.23 with SMTP id g23mr6764442qcq.100.1339429160877;
Mon, 11 Jun 2012 08:39:20 -0700 (PDT)
Received: by 10.229.144.205 with HTTP; Mon, 11 Jun 2012 08:39:20 -0700 (PDT)
In-Reply-To: <CANEZrP3kOysjENpkHom5MHg0usq1jkQdEFAM3vuR1KgFAnJHhg@mail.gmail.com>
References: <CANEZrP3kOysjENpkHom5MHg0usq1jkQdEFAM3vuR1KgFAnJHhg@mail.gmail.com>
Date: Mon, 11 Jun 2012 11:39:20 -0400
Message-ID: <CAAS2fgSB6--PzpnTrx_DXrwZ7uzXrTCH3a1aMVFmWPBNO6FuqA@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: 1Se6im-0004PP-MH
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 15:40:06 -0000
On Sun, Jun 10, 2012 at 7:06 PM, Mike Hearn <mike@plan99.net> wrote:
> I remember some people, Greg in particular, who were not a fan of
> approach (2) at all, though it has the benefit of speeding startup for
> new users as there's no indexing overhead.
I'm not a fan of anything which introduces unauditable single source
material. "Trust us" is a bad place to be because it would greatly
increase the attractiveness of compromising developers.
If we wanted to go the route of shipping pruned chains I'd prefer to
have a deterministic process to produce archival chains and then start
introducing commitments to them in the blockchain or something like
that. Then a client doing a reverse header sync[1] would bump into a
commitment for an archival chain that they have and would simply stop
syncing and use the archival chain for points before that.
This would leave it so that the distribution of the software could
still be audited.
More generally we should start doing something with the service
announcements so that full nodes that don't have enough bandwidth to
support a lot of syncing from new nodes can do so without turning off
listening.
[1] https://en.bitcoin.it/wiki/User:Gmaxwell/Reverse_header-fetching_sync
|
