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
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
|
Return-Path: <eric@voskuil.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7D39EC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 11:20:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 56DAB43001
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 11:20:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001,
RCVD_IN_MSPIKE_WL=0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id EkDR7BERrwcB
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 11:20:11 +0000 (UTC)
X-Greylist: delayed 15:00:09 by SQLgrey-1.8.0
Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com
[209.85.214.174])
by smtp2.osuosl.org (Postfix) with ESMTPS id 4153942FFD
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Mar 2021 11:20:11 +0000 (UTC)
Received: by mail-pl1-f174.google.com with SMTP id ba1so9685584plb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 01 Mar 2021 03:20:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=from:to:references:in-reply-to:subject:date:message-id:mime-version
:content-language:thread-index;
bh=vIrhOIlTDdto1fo6YJQdZf2LZ5Z5XUdn44ONsduWzlI=;
b=hvN/huqbi6leKZAKWOO+AqNNq1IXKkhEdiaUvqJmQ6PjCYp5qYqwllfj/KQUCqxibV
DOIal5VkkEnKyOXGC6ZcithtLsy6Nvd5DwWb7tsEJiHAt+qD+NX6qsIGR/6bku59hxUq
Ag9Xqr9jAX55uQUPG85/M3Piry8Sy1667o1bgQw+oydD718KksBgw+fyJD/Q25m8lQWL
p63hsdHwzsuZekdkmppqnYeGHbnSTJaddk8VlWdnrRkahV9B13qvDxxLsW3QFIGuy8hx
d0uG646GSN4N3WOauDMEMER73eeoUZ5jNhdT7y9vor/MMp/HWJ8txkdtb64sK8TMsv0j
bcyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:references:in-reply-to:subject:date
:message-id:mime-version:content-language:thread-index;
bh=vIrhOIlTDdto1fo6YJQdZf2LZ5Z5XUdn44ONsduWzlI=;
b=qKC/oJqhxI64gBbVudFWGl3XLmfS+kR1lOoXCv6qfX0ZF9PlWDjfOdL0QegUqdbnJK
xGoFxtnpvQkmg4hHEcEWB5wCApFSMqBAHH622xDZsQFQtQw85JcS3gocRWDdUOOyqAfY
WahIES/MDL+RCCKnRiZTjuwlJpzO1WyT2mgHQn+Xnv6VaTrhfIGLDr/2mrF6R/3DGveu
5DWIyQLb0T2QeLo5Oio2A0lN0+HbJD/MMX1ojpbxu/oWdwegi0+TztEmdF1Gf++/UJtR
wfTo5LcAINM2DAA7FKNM2lGwneezGDV9j07LRjHICUI1B/zJoaaQUf+ZUAxVy5d6yuGg
9sZA==
X-Gm-Message-State: AOAM531S4SWYlEADdb/+s9NurXhx9TLU9JXIn5YaGQ+/sLgFxK0ABuK6
THtxrK7ejcBY6F3iPHAupjhMvkraiO0RVdxl
X-Google-Smtp-Source: ABdhPJyLivn8fEq4TEAm8QkF0tcPyroU04vRTh3izWph3J1YmgdVk7QVYjGFt2jiFNZm9/v7PzjoQg==
X-Received: by 2002:a62:16c9:0:b029:1ed:df04:8fcf with SMTP id
192-20020a6216c90000b02901eddf048fcfmr14571010pfw.63.1614591426496;
Mon, 01 Mar 2021 01:37:06 -0800 (PST)
Received: from ERICDESKTOP ([2601:600:9c00:1d0::b000])
by smtp.gmail.com with ESMTPSA id q4sm16757202pfs.134.2021.03.01.01.37.05
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Mon, 01 Mar 2021 01:37:05 -0800 (PST)
From: <eric@voskuil.org>
To: "'Bitcoin Protocol Discussion'" <bitcoin-dev@lists.linuxfoundation.org>
References: <CALeFGL1WSSA69ARvJW3di-UC_gz7NV9q7=6zd7s=CHnmttdQFg@mail.gmail.com>
<CAJx8jdz3uOCpwed3MZkf1ghkvaZMfy-+vvOCVZdvhz2KAn38DQ@mail.gmail.com>
<b895f2e4-513f-0c0d-91ac-52af055f332c@LeoWandersleb.de>
<CAPR5oBND9DS1Ea=RMqrhnMBjFqU6wpCpv-sMeX9mxqgyLJGYiQ@mail.gmail.com>
In-Reply-To: <CAPR5oBND9DS1Ea=RMqrhnMBjFqU6wpCpv-sMeX9mxqgyLJGYiQ@mail.gmail.com>
Date: Mon, 1 Mar 2021 01:37:06 -0800
Message-ID: <00b001d70e7e$7204e2f0$560ea8d0$@voskuil.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_00B1_01D70E3B.63E350A0"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQC3ML5SL96bh4vDDY9y8HYjlqZLVgImxkDAAI7sjCMBipy/mayMlTug
Subject: Re: [bitcoin-dev] A design for Probabilistic Partial Pruning
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Mar 2021 11:20:12 -0000
This is a multipart message in MIME format.
------=_NextPart_000_00B1_01D70E3B.63E350A0
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
On Sun, Feb 28, 2021 at 10:18 AM Leo Wandersleb via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org> > wrote:
=20
> Only headers need to be downloaded sequentially so downloading =
relevant blocks from one node is totally possible with gaps in between.
=20
In fact this is exactly how libbitcoin v4 works. We download and store =
blocks in parallel. In the case of a restart block gaps are repopulated. =
Given that headers are validated, we go after the most responsive nodes. =
Based on standard deviation, we drop the slowest peers and rebalance =
load to new/empty channels. We make ordered but not necessarily =
sequential requests. There is no distinction between =
=E2=80=9Cinitial=E2=80=9D block download, a restart, or a single or few =
blocks at the top. So it=E2=80=99s referred to as continuous parallel =
block download.
=20
But we don=E2=80=99t prune. Personally I consider this =
counterproductive. Apart from the complexity, it=E2=80=99s not healthy. =
And the chain grows linearly with storage cost falling exponentially, =
leading to a straightforward conclusion.
=20
e
------=_NextPart_000_00B1_01D70E3B.63E350A0
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta =
name=3DGenerator content=3D"Microsoft Word 15 (filtered =
medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple style=3D'word-wrap:break-word'><div =
class=3DWordSection1><div><div><p class=3DMsoNormal>On Sun, Feb 28, 2021 =
at 10:18 AM Leo Wandersleb via bitcoin-dev <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.l=
inuxfoundation.org</a>> wrote:<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>> Only =
headers need to be downloaded sequentially so downloading relevant =
blocks from one node is totally possible with gaps in =
between.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal>In fact this is exactly how libbitcoin v4 works. We =
download and store blocks in parallel. In the case of a restart block =
gaps are repopulated. Given that headers are validated, we go after the =
most responsive nodes. Based on standard deviation, we drop the slowest =
peers and rebalance load to new/empty channels. We make ordered but not =
necessarily sequential requests. There is no distinction between =
=E2=80=9Cinitial=E2=80=9D block download, a restart, or a single or few =
blocks at the top. So it=E2=80=99s referred to as continuous parallel =
block download.<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>But we =
don=E2=80=99t prune. Personally I consider this counterproductive. Apart =
from the complexity, it=E2=80=99s not healthy. And the chain grows =
linearly with storage cost falling exponentially, leading to a =
straightforward conclusion.<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal>e<o:p></o:p></p></div></div></div></body></html>
------=_NextPart_000_00B1_01D70E3B.63E350A0--
|
