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
|
Return-Path: <sjors@sprovoost.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B1651BF2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Nov 2017 14:03:51 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
[66.111.4.28])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E0CF51AE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Nov 2017 14:03:50 +0000 (UTC)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailout.nyi.internal (Postfix) with ESMTP id F022620D27
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Nov 2017 09:03:49 -0500 (EST)
Received: from frontend2 ([10.202.2.161])
by compute1.internal (MEProxy); Tue, 21 Nov 2017 09:03:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h=
content-type:date:from:message-id:mime-version:subject:to
:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=wYxPPE0R+6rCZpZlU
RZxpDNnD70FM7E2Tt/PBCGl2pQ=; b=BEwFMo1Zb7mRP/l0X/iJQg25VGXPXkZPX
EkUBLfywITkZxnSl4eirq3gE2Pp4lkz06t4uRlqHclfoeZqDm03+SbNrQqL/Jw6i
s8jmSPUhFNS0CubSYDdVGQ5gPZibYMrzSmOwCDSEY1QadhhVKD6of1JauSTOL96F
0UXe2tyO0Ym1bRn75v161Z/W4FkWyw1ibq2HTwDMLyYmWtuADiY3vXCIrvQzr6rh
tNhYqNWcJ5e/plt8tTpnSMA8X+ieS8uzChk4P00lxLH7Zyn7uRqFmwgOU9FWP+HV
rGjxyf1+bGSBMrByjr6p1q1UryLzG2iWNIl3BV+giEQW1caVoSg5Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=content-type:date:from:message-id
:mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=
fm1; bh=wYxPPE0R+6rCZpZlURZxpDNnD70FM7E2Tt/PBCGl2pQ=; b=JZNu4RvB
EB3XuYTKxQogMw/te4UW9U8Xo028t+XnYAFryt6UY3but+UVimX8Gp5pGmKhgdiN
IfRSsWsI80n1mWvAmfOFrOfZK43syuRWwrtMs16mSSpQr2z7iFGW7R7fFUY8o2gT
PJrT7Ri88YfKxnee+NA/zekqn4anXtbzRFNMcZukbuhrBhfK0rtuigWndmSo5MQP
Zq0gDEuQi2/frD0Ekq9L5NLIk8GKOmBhh8MtzDeXsprG5M61z2KsK+GWWiYDArAy
VAo94+PVqHj308+yTKCgfwsWHRyUQf6Hi30epy04e/8tmdlhI8JJ+QvsKcF1nYqR
aAqUQb+43UUVSA==
X-ME-Sender: <xms:RTIUWvV3OKH2QU2BWm3tjuw93YAdvubvLTq3VD7T-i5POgWOd1wbDA>
Received: from [192.168.178.108] (54693d0f.cm-12-2a.dynamic.ziggo.nl
[84.105.61.15])
by mail.messagingengine.com (Postfix) with ESMTPA id A285924B36
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Nov 2017 09:03:48 -0500 (EST)
From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: multipart/signed;
boundary="Apple-Mail=_B985A468-2BD4-4362-9B4F-EA5DFB10F153";
protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Message-Id: <BF359C7E-7FEF-43A6-8ED9-05BED8E0EB64@sprovoost.nl>
Date: Tue, 21 Nov 2017 15:03:46 +0100
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.3445.4.7)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 21 Nov 2017 14:58:46 +0000
Subject: [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 14:03:51 -0000
--Apple-Mail=_B985A468-2BD4-4362-9B4F-EA5DFB10F153
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
I came across the proposed Bitcoin Core implementation of BIP159 [0] in =
this 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 =
understand how that impacts extendibility.
> Peers may have different prune depths (depending on the peers =
configuration,
> 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 =
blocks (~2 day
As the blockchain keeps growing there will be ever more pruned nodes =
(perhaps 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 =
flexibility. 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 current chain size. A slightly better formula could =
take into account typical hard drive size increments, leaving enough =
space for the OS and other data. Node operators could opt-in to this if =
they think the increased fingerprint risk outweighs their desire to =
share archived blocks.
I can also imagine - but not implement :-) - a future scenario where =
nodes 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 nodes.
How would such extension be signaled for? Would we need a whole new =
version bit?
Would upgraded nodes need a new message type to communicate the chosen =
prune depth? Or can that information tag along some existing message?
Jonas Schnelli pointed out on the Github discussion that waiting for =
BIP150 would be appropriate. Can you explain how this is related? =
Although I can see why whitelisted peers can be exempted from the =
anti-fingerprinting measure, 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 =
also 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/thread.ht=
ml#14315
--Apple-Mail=_B985A468-2BD4-4362-9B4F-EA5DFB10F153
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAloUMkIACgkQV/+b28ww
EAm/tg//R7myNx09WqsbGDpzJTPxr40Y4IBdc/BpTcWIWgAEW0l0JuTLQRJZLoMA
y9YSgRFCi4B26E3RgXLASA7pr2F9TczoyQGb9R2jzBl2lKTrCx6/EXWmx1JCeio0
7KdPVcFs3auc7V/NvJpHi1R6CnDYNkMpKctmwt6b1/IBIKCGeJWQ9LtiuudlKAl0
4Z/rJRJmbIxQDDYsa7B3Raqo79V351OamSyQ6LQft8/FXEpvv5BRg0ONtlIaHLBy
Ebegvr3e5sw7rJxi/uvQqkUTXkkWQ0M7/EvLdFMN/qlrFT4o7RafzQdg4GuIli8K
qkW29TDPSSWKO9B/gsIT6VooJfOs1PfoctaDZn2gMfEjxv+bVfpFYqOEtTrJ+xfR
ORgY5j75aaDfxYH5OdyWMltZJ+XFsqt1BegY905KuWJuT0HD/DnRSpwc2K85wOIS
qR3rnhGx4wIqm8FwpI6ZrJ8CyBvoMu12a7pxN661n9zxPjWFJnUdk1/6K5J4t9gL
9jFslsbS+1T+W2UKpmOIBUI/Ldw1pynjZF52bnDefjf73YWwDEV06UmoKcXvfa8H
qfAni6PwH2oGry0bsxuE3Vuv9Vp0yXv/2alsDhKKMKFS5e45+g5nnWZobzKQDFPE
/GJXlma2iCEas2tI9Nr4agUE3MiMqtELd4WTz7Vz9Lfqrf7Q8Ag=
=JAN4
-----END PGP SIGNATURE-----
--Apple-Mail=_B985A468-2BD4-4362-9B4F-EA5DFB10F153--
|
