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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 70100C48
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Nov 2017 18:45:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com
[209.85.213.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C0EAE14D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Nov 2017 18:45:35 +0000 (UTC)
Received: by mail-vk0-f46.google.com with SMTP id s197so8272880vkh.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Nov 2017 10:45:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:content-transfer-encoding;
bh=siNNRgHeZzIGbzxfyvgKi54GIYf1vXKs8Gdwr+KZ7DA=;
b=auUKE26DOW7O7Cbx2JTQbFaJ9RZr0VUc6Rlcs0LxJeXnu0qBnygG9E3LM2A7kQJd6a
KHj9ZD1AwyulXuQrX8m+ojw4eGXBq7bc/xZHgaE4aTmpJuVRoaxdfakqtG5aCtMpjtvW
PcL+7+ksr65+4qRizpMnMJLeU/yY2ePZh6jz1jwl94FXvyirnjTUsXbTve1eFjcn/5ah
bMVLrPo427xgbSllGnc05AAGDQ6i1LbNBfOMmUU/UY+WNnmlPj2KmoMZHhyrlyD0jBFa
NgRdkdfL81W7rnuOOnPY/MIV7zj9+MA5abicK+lmbfahjTCgxtRImRiHGKKfyB19aK80
tt/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:content-transfer-encoding;
bh=siNNRgHeZzIGbzxfyvgKi54GIYf1vXKs8Gdwr+KZ7DA=;
b=fj7L5NFVPDEbi8X6vGdLkECwOrSMy0bYwkNdakvy/Fk/rnc5VQHEit9V/waHSo7dpT
827NdsJldAge8VjJy3AVXuktmghMw3g8+UI9FoOWO7EweJbYs0mtlD1R1gjWnLKDVGSE
OtpcySDlrZL0pz6tWYsUf4vR1sJSKXsY/nHbxS79Vb5EWvcP9UgY3Nn8HlGZYf1DI7fe
/zaOj5TZOo21Sjtr81QFYAeLVzQ1KP1skA++OtaCW0zRPtiz8wy8JNRYMRhbyVX6ZxpS
bKFraHuPNUxvlwPgEEFQA1t2ZxBi8aofQy/r0WUbAlR0DB3bKLBWjQaeQesTmP17xyyE
vDXA==
X-Gm-Message-State: AJaThX7kxJv3tMQ5fYHiighnJOOiMXvbZYIIf8AhdAL1t5FrXOHFVOQZ
i+b7n/Zff5qWwOWcJ1GCRR+b9gBfOwFDi4lwRss=
X-Google-Smtp-Source: AGs4zMba90aGiP0azHQ9wsSAhtI/LtZpJVykmel7F6AzPkJoq4Z6fTkJOLXuavVIWlN22+WDn2iu4tvbldm/Uzgygwk=
X-Received: by 10.31.224.6 with SMTP id x6mr13845068vkg.149.1511289934713;
Tue, 21 Nov 2017 10:45:34 -0800 (PST)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.85.148 with HTTP; Tue, 21 Nov 2017 10:45:33 -0800 (PST)
In-Reply-To: <BF359C7E-7FEF-43A6-8ED9-05BED8E0EB64@sprovoost.nl>
References: <BF359C7E-7FEF-43A6-8ED9-05BED8E0EB64@sprovoost.nl>
From: Gregory Maxwell <greg@xiph.org>
Date: Tue, 21 Nov 2017 18:45:33 +0000
X-Google-Sender-Auth: uBSVGzK3Ueefn3TAoWEe64hTmDc
Message-ID: <CAAS2fgRZT6mStLa-PhpDOhccGvQ4jhD2m1PtzTd0_gfvtwBm7A@mail.gmail.com>
To: Sjors Provoost <sjors@sprovoost.nl>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP159 - NODE_NETWORK_LIMITED service bits,
extendability
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Tue, 21 Nov 2017 18:45:37 -0000
With the way pruning works today my expirence is that virtually no one
sets any parameter other than the minimum, though even with that set a
few more blocks can be available.
In the future we would set further pruning identifying bits, with
those set node would (obviously) answer for their blocks. An earlier
version of this BIP had such a bit defined but it appeared that we
lacked sufficient experience from practice to usefully specify what
height it should mean exactly and the proposals sounded like they
would likely interact poorly with other future proposals, so we
thought it better to delay defining any additional levels for the
time.
Part of your concern is mooted by the logistics of actually fetching
those additional blocks. At least in the network today we have a
superabundance of nodes that serve anything, to handle them being rare
will require very different approaches than we have now. We have no
reason to believe that "like the pruning thing but more blocks" is
actually all that useful-- and some reason to expect that its not:
once you go back more than a handful of weeks the probably of fetching
get pretty close to uniform, those fetches are only be newly
initializing nodes that need all the blocks.
On Tue, Nov 21, 2017 at 2:03 PM, Sjors Provoost via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I came across the proposed Bitcoin Core implementation of BIP159 [0] in t=
his PR [1]. The goal is to allow pruned nodes to "serve a limited number of=
historical blocks" (as opposed to none at all).
>
> It contains a counter-measure for peer fingerprinting. I'm trying to unde=
rstand how that impacts extendibility.
>
>> Peers may have different prune depths (depending on the peers configurat=
ion,
>> disk space, etc.) which can result in a fingerprinting weakness (finding=
the
>> prune depth through getdata requests). NODE_NETWORK_LIMITED
>> supporting peers SHOULD avoid leaking the prune depth and therefore
>> not serve blocks deeper then the signaled NODE_NETWORK_LIMITED
>> thresholds.
>
> This means pruned nodes can only serve the last 288 blocks:
>
>> If signaled, the peer MUST be capable of serving at least the last 288 b=
locks (~2 day
>
> As the blockchain keeps growing there will be ever more pruned nodes (per=
haps offset by new nodes with more storage). Although a strict improvement=
over todays situation, it seems a bit wasteful to have a node with 10-100 =
GB of storage only be able to share the most recent 288 blocks.
>
> It would be nice if a future extension of this BIP allows more flexibilit=
y. To limit the ability to fingerprint nodes, we could limit the number of =
choices to e.g. 288 + 1000 * 2^n. That yields only 8 possibilities at the c=
urrent chain size. A slightly better formula could take into account typica=
l hard drive size increments, leaving enough space for the OS and other dat=
a. Node operators could opt-in to this if they think the increased fingerpr=
int risk outweighs their desire to share archived blocks.
>
> I can also imagine - but not implement :-) - a future scenario where node=
s prune a random subset of their chain, meaning that even nodes with little=
storage can be of help during Initial Blockchain Download (IBD) of other n=
odes.
>
>
> How would such extension be signaled for? Would we need a whole new versi=
on bit?
>
> Would upgraded nodes need a new message type to communicate the chosen pr=
une depth? Or can that information tag along some existing message?
>
> Jonas Schnelli pointed out on the Github discussion that waiting for BIP1=
50 would be appropriate. Can you explain how this is related? Although I ca=
n see why whitelisted peers can be exempted from the anti-fingerprinting me=
asure, I would not want to restrict it to just those.
>
>
> Some minor suggestions for improving the BIP itself:
> * add link to mailinglist discussion(s) in reference section
> * explain that 288 is not just the minimum limit for Bitcoin Core, but al=
so the bulk of traffic (as I understand from earlier discussion [2])
>
> Cheers,
>
> Sjors
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki
> [1] https://github.com/bitcoin/bitcoin/pull/10387
> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/thre=
ad.html#14315
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
