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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1SdrDm-0005fN-9N
for bitcoin-development@lists.sourceforge.net;
Sun, 10 Jun 2012 23:06:58 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.175 as permitted sender)
client-ip=209.85.217.175; envelope-from=mh.in.england@gmail.com;
helo=mail-lb0-f175.google.com;
Received: from mail-lb0-f175.google.com ([209.85.217.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SdrDl-0002zu-EJ
for bitcoin-development@lists.sourceforge.net;
Sun, 10 Jun 2012 23:06:58 +0000
Received: by lbol5 with SMTP id l5so2796666lbo.34
for <bitcoin-development@lists.sourceforge.net>;
Sun, 10 Jun 2012 16:06:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.105.51 with SMTP id gj19mr15320212lab.38.1339369610853;
Sun, 10 Jun 2012 16:06:50 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.114.10.5 with HTTP; Sun, 10 Jun 2012 16:06:50 -0700 (PDT)
Date: Mon, 11 Jun 2012 01:06:50 +0200
X-Google-Sender-Auth: GGEa9VXTCvdjqOoYgC4WINdfWgk
Message-ID: <CANEZrP3kOysjENpkHom5MHg0usq1jkQdEFAM3vuR1KgFAnJHhg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.0 (-)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SdrDl-0002zu-EJ
Subject: [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: Sun, 10 Jun 2012 23:06:58 -0000
Apologies if this has been discussed elsewhere. I don't recall us ever
reaching a solid conclusion on it.
A node that has pruned its block chain cannot serve the chain to new
nodes. So there are three options for bootstrapping a newly installed
node:
1) Have some kind of special archival nodes that never prune
(advertised via the services field?). Encourage people to run them,
somehow.
2) Ship a post-pruning block chain and tx index with the client
downloads, so the client starts up already bootstrapped.
3) Some combination of both. It's safe to assume some people will keep
unpruned chains around no matter what. But for many users (2) is
easiest and archival nodes would be put under less load if they were
used only by users who wish to fully bootstrap from only the code.
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.
|
