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
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A780CB3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Dec 2017 17:30:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pl0-f52.google.com (mail-pl0-f52.google.com
[209.85.160.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 835AF405
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Dec 2017 17:30:20 +0000 (UTC)
Received: by mail-pl0-f52.google.com with SMTP id s3so5210484plp.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Dec 2017 09:30:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
h=from:mime-version:subject:date:references:to:in-reply-to:message-id;
bh=QfOZ7UJ+mfDNVs6GjkFxN14vMKnasp31Z12vV1CfW4Y=;
b=uGy06dFlLNj8u2EN5otLomcXLgmFHzzwaas3rsoldvYXWeJ5V7OgPt7Xw2QLZqEaiL
YCkoIW9mNcdn7RdA4IDrUdjNDOUDSDuM7XVSt18H3bKNxkR4pTX/mhG+N4F8D9eqdova
JdY2EX/rHqOizLjAMyshXPfkTEvU6mSB6WFACkY0j3zRh2QsajkptfktgC0/M0aJfARB
5JYcUHKbEEQj+JgL8x2sF6JNTZTW71LsgbMSSypC1GsGnhH2wUxYvYgE9xS4itfjDeQt
pnIITKsdwd1emv16s7d16uKCDaoeK8u4ynxSjVvP5FDQVlaGaeVifBED8McJ3joVqmGe
yp7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:mime-version:subject:date:references:to
:in-reply-to:message-id;
bh=QfOZ7UJ+mfDNVs6GjkFxN14vMKnasp31Z12vV1CfW4Y=;
b=QJxu43EALG9Om29dIaMdGd9a6riSs7kYbyCqWtZG8pFqXDsg9wBZ8Njl3M46IwO4Tc
0Onnah2W2sjbcj23EksgLn3e47C+Qu6Hjod81W3XWPOBFSp6T64OY9shN29x49XiKNYS
5IpzY/ohLurlbMCxZuCDyZOIk0mfcYFUYP6iruji7oxdCOVge3bzmMUGV0a2GurrtxF9
EM9nFEflegT11ZYIaP2FUfmpNghggAYxD4cRmI78I+B4ER3Po3jSCRvl8hxjs+Y4ASrT
vxvzIMzNVbLSj01AdViq7vILYEh8huvlW2BlkDTAm26qnH18/TlxjiPlWGRgXS8BsZec
dfWA==
X-Gm-Message-State: AKGB3mK+H623T3Wy0qIaw5j4GxACncHqLeU/sxgXXh+0/Rap+xHx5gVE
URslC63uwxoLxRV4cGtWwUp0d56jjXA=
X-Google-Smtp-Source: ACJfBov7KvbA1vxjIjCWAjVDAV2gtRBc6lpKuoHGGWCbdBmEx+yPGpuzgHQy+TuzV/XSDjKp7mGpow==
X-Received: by 10.84.215.146 with SMTP id l18mr394351pli.451.1513618220036;
Mon, 18 Dec 2017 09:30:20 -0800 (PST)
Received: from ?IPv6:2601:646:8080:4dbb:949b:6f19:8460:3d9?
([2601:646:8080:4dbb:949b:6f19:8460:3d9])
by smtp.gmail.com with ESMTPSA id
j17sm22133910pgv.40.2017.12.18.09.30.18
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 18 Dec 2017 09:30:19 -0800 (PST)
From: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative;
boundary="Apple-Mail=_E40D9A28-3FF7-44D7-ACF3-4F906AB74C43"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 18 Dec 2017 09:30:17 -0800
References: <CAPswA9ycPdTtm9PeD5a2R36cZ46HwnkwJu06FXuoE-F5Dx+eZQ@mail.gmail.com>
<CD7FBCF6-5386-4E9E-A3B9-D5B3DBAF312C@voskuil.org>
<CAPswA9zo1dLYHP9A+xrYLsrFO5GVYFqVLQC-A9uHQSCie7xeYg@mail.gmail.com>
<A2B6418E-069F-476A-86EE-638C6D9E826A@voskuil.org>
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <A2B6418E-069F-476A-86EE-638C6D9E826A@voskuil.org>
Message-Id: <61B0AEC9-3B1D-416F-8883-A030E5109538@friedenbach.org>
X-Mailer: Apple Mail (2.3445.5.20)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, 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] Why not witnessless nodes?
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: Mon, 18 Dec 2017 17:30:21 -0000
--Apple-Mail=_E40D9A28-3FF7-44D7-ACF3-4F906AB74C43
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Sign-to-contract enables some interesting protocols, none of which are =
in wide use as far as I=E2=80=99m aware. But if they were (and arguably =
this is an area that should be more developed), then SPV nodes =
validating these protocols will need access to witness data. If a node =
is performing IBD with assumevalid set to true, and is also intending to =
prune history, then there=E2=80=99s no reason to fetch those witnesses =
as far as I=E2=80=99m aware. But it would be a great disservice to the =
network for nodes intending to serve SPV clients to prune this portion =
of the block history.=20
> On Dec 18, 2017, at 8:19 AM, Eric Voskuil via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> You can't know (assume) a block is valid unless you have previously =
validated the block yourself. But in the case where you have, and then =
intend to rely on it in a future sync, there is no need for witness data =
for blocks you are not going to validate. So you can just not request =
it.=20
>=20
> However you will not be able to provide those blocks to nodes that =
*are* validating; the client is pruned and therefore not a peer (cannot =
reciprocate). (An SPV client is similarly not a peer; it is a more =
deeply pruned client than the witnessless client.)
>=20
> There is no other reason that a node requires witness data. SPV =
clients don't need it as it is neither require it to verify header =
commitment to transactions nor to extract payment addresses from them.
>=20
> The harm to the network by pruning is that eventually it can become =
harder and even impossible for anyone to validate the chain. But because =
you are fully validating you individually remain secure, so there is no =
individual incentive working against this system harm.
>=20
> e
>=20
> On Dec 18, 2017, at 08:35, Kalle Rosenbaum <kalle@rosenbaum.se =
<mailto:kalle@rosenbaum.se>> wrote:
>=20
>> 2017-12-18 13:43 GMT+01:00 Eric Voskuil <eric@voskuil.org =
<mailto:eric@voskuil.org>>:
>>=20
>> > On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>> >
>> > Dear list,
>> >
>> > I find it hard to understand why a full node that does initial =
block
>> > download also must download witnesses if they are going to skip =
verification anyway.
>>=20
>> Why run a full node if you are not going to verify the chain?
>>=20
>> I meant to say "I find it hard to understand why a full node that =
does initial block
>> download also must download witnesses when it is going to skip =
verification of the witnesses anyway."
>>=20
>> I'm referring to the "assumevalid" feature of Bitcoin Core that skips =
signature verification up to block X. Or have I misunderstood =
assumevalid?
>>=20
>> /Kalle
>> =20
>>=20
>> > If my full node skips signature verification for
>> > blocks earlier than X, it seems the reasons for downloading the
>> > witnesses for those blocks are:
>> >
>> > * to be able to send witnesses to other nodes.
>> >
>> > * to verify the witness root hash of the blocks
>> >
>> > I suppose that it's important to verify the witness root hash =
because
>> > a bad peer may send me invalid witnesses during initial block
>> > download, and if I don't verify that the witness root hash actually
>> > commits to them, I will get banned by peers requesting the blocks =
from
>> > me because I send them garbage.
>> > So both the reasons above (there may be more that I don't know =
about)
>> > are actually the same reason: To be able to send witnesses to =
others
>> > without getting banned.
>> >
>> > What if a node could chose not to download witnesses and thus chose =
to
>> > send only witnessless blocks to peers. Let's call these nodes
>> > witnessless nodes. Note that witnessless nodes are only witnessless
>> > for blocks up to X. Everything after X is fully verified.
>> >
>> > Witnessless nodes would be able to sync faster because it needs to
>> > download less data to calculate their UTXO set. They would =
therefore
>> > more quickly be able to provide full service to SPV wallets and its
>> > local wallets as well as serving blocks to other witnessless nodes
>> > with same or higher assumevalid block. For witnessless nodes with
>> > lower assumevalid they can serve at least some blocks. It could =
also
>> > serve blocks to non-segwit nodes.
>> >
>> > Do witnessless nodes risk dividing the network in two parts, one
>> > witnessless and one with full nodes, with few connections between =
the
>> > parts?
>> >
>> > So basically, what are the reasons not to implement witnessless
>> > nodes?
>> >
>> > Thank you,
>> > /Kalle
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail=_E40D9A28-3FF7-44D7-ACF3-4F906AB74C43
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" =
class=3D"">Sign-to-contract enables some interesting protocols, none of =
which are in wide use as far as I=E2=80=99m aware. But if they were (and =
arguably this is an area that should be more developed), then SPV nodes =
validating these protocols will need access to witness data. If a node =
is performing IBD with assumevalid set to true, and is also intending to =
prune history, then there=E2=80=99s no reason to fetch those witnesses =
as far as I=E2=80=99m aware. But it would be a great disservice to the =
network for nodes intending to serve SPV clients to prune this portion =
of the block history. <br class=3D""><div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Dec 18, 2017, at 8:19 AM, =
Eric Voskuil via bitcoin-dev <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><meta =
http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8" =
class=3D""><div dir=3D"auto" class=3D""><div class=3D""></div><div =
class=3D"">You can't know (assume) a block is valid unless you have =
previously validated the block yourself. But in the case where you have, =
and then intend to rely on it in a future sync, there is no need for =
witness data for blocks you are not going to validate. So you can just =
not request it. </div><div class=3D""><br class=3D""></div><div =
class=3D"">However you will not be able to provide those blocks to nodes =
that *are* validating; the client is pruned and therefore not a peer =
(cannot reciprocate). (An SPV client is similarly not a peer; it is a =
more deeply pruned client than the witnessless client.)</div><div =
class=3D""><br class=3D""></div><div class=3D"">There is no other reason =
that a node requires witness data. SPV clients don't need it as it is =
neither require it to verify header commitment to transactions nor to =
extract payment addresses from them.</div><div class=3D""><br =
class=3D""></div><div class=3D"">The harm to the network by pruning is =
that eventually it can become harder and even impossible for anyone to =
validate the chain. But because you are fully validating you =
individually remain secure, so there is no individual incentive working =
against this system harm.</div><div class=3D""><br class=3D""></div><div =
class=3D"">e</div><div class=3D""><br class=3D"">On Dec 18, 2017, at =
08:35, Kalle Rosenbaum <<a href=3D"mailto:kalle@rosenbaum.se" =
class=3D"">kalle@rosenbaum.se</a>> wrote:<br class=3D""><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div=
dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">2017-12-18 13:43 GMT+01:00 Eric Voskuil <span =
dir=3D"ltr" class=3D""><<a href=3D"mailto:eric@voskuil.org" =
target=3D"_blank" class=3D"">eric@voskuil.org</a>></span>:<br =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span =
class=3D"gmail-"><br class=3D"">
> On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.<wbr class=3D"">linuxfoundation.org</a>> =
wrote:<br class=3D"">
><br class=3D"">
> Dear list,<br class=3D"">
><br class=3D"">
> I find it hard to understand why a full node that does initial =
block<br class=3D"">
> download also must download witnesses if they are going to skip =
verification anyway.<br class=3D"">
<br class=3D"">
</span>Why run a full node if you are not going to verify the chain?<br =
class=3D""></blockquote><div class=3D""><br class=3D""></div>I meant to =
say "<span style=3D"color:rgb(80,0,80);font-size:12.8px" class=3D"">I =
find it hard to understand why a full node that does initial =
block</span><br style=3D"color:rgb(80,0,80);font-size:12.8px" =
class=3D""><span style=3D"color:rgb(80,0,80);font-size:12.8px" =
class=3D"">download also must download witnesses when it is going to =
skip verification of the witnesses anyway."</span></div><div =
class=3D"gmail_quote"><span style=3D"color:rgb(80,0,80);font-size:12.8px" =
class=3D""><br class=3D""></span></div><div class=3D"gmail_quote"><span =
style=3D"color:rgb(80,0,80);font-size:12.8px" class=3D"">I'm referring =
to the "assumevalid" feature of Bitcoin Core that skips signature =
verification up to block X. Or have I misunderstood =
assumevalid?</span></div><div class=3D"gmail_quote"><span =
style=3D"color:rgb(80,0,80);font-size:12.8px" class=3D""><br =
class=3D""></span></div><div class=3D"gmail_quote"><span =
style=3D"color:rgb(80,0,80);font-size:12.8px" =
class=3D"">/Kalle</span></div><div class=3D"gmail_quote"> <br =
class=3D""></div><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">
<div class=3D""><div class=3D"gmail-h5"><br class=3D"">
> If my full node skips signature verification for<br class=3D"">
> blocks earlier than X, it seems the reasons for downloading the<br =
class=3D"">
> witnesses for those blocks are:<br class=3D"">
><br class=3D"">
> * to be able to send witnesses to other nodes.<br class=3D"">
><br class=3D"">
> * to verify the witness root hash of the blocks<br class=3D"">
><br class=3D"">
> I suppose that it's important to verify the witness root hash =
because<br class=3D"">
> a bad peer may send me invalid witnesses during initial block<br =
class=3D"">
> download, and if I don't verify that the witness root hash =
actually<br class=3D"">
> commits to them, I will get banned by peers requesting the blocks =
from<br class=3D"">
> me because I send them garbage.<br class=3D"">
> So both the reasons above (there may be more that I don't know =
about)<br class=3D"">
> are actually the same reason: To be able to send witnesses to =
others<br class=3D"">
> without getting banned.<br class=3D"">
><br class=3D"">
> What if a node could chose not to download witnesses and thus chose =
to<br class=3D"">
> send only witnessless blocks to peers. Let's call these nodes<br =
class=3D"">
> witnessless nodes. Note that witnessless nodes are only =
witnessless<br class=3D"">
> for blocks up to X. Everything after X is fully verified.<br =
class=3D"">
><br class=3D"">
> Witnessless nodes would be able to sync faster because it needs =
to<br class=3D"">
> download less data to calculate their UTXO set. They would =
therefore<br class=3D"">
> more quickly be able to provide full service to SPV wallets and =
its<br class=3D"">
> local wallets as well as serving blocks to other witnessless =
nodes<br class=3D"">
> with same or higher assumevalid block. For witnessless nodes =
with<br class=3D"">
> lower assumevalid they can serve at least some blocks. It could =
also<br class=3D"">
> serve blocks to non-segwit nodes.<br class=3D"">
><br class=3D"">
> Do witnessless nodes risk dividing the network in two parts, one<br =
class=3D"">
> witnessless and one with full nodes, with few connections between =
the<br class=3D"">
> parts?<br class=3D"">
><br class=3D"">
> So basically, what are the reasons not to implement witnessless<br =
class=3D"">
> nodes?<br class=3D"">
><br class=3D"">
> Thank you,<br class=3D"">
> /Kalle<br class=3D"">
</div></div>> ______________________________<wbr =
class=3D"">_________________<br class=3D"">
> bitcoin-dev mailing list<br class=3D"">
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.<wbr class=3D"">linuxfoundation.org</a><br =
class=3D"">
> <a =
href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.<wbr =
class=3D"">org/mailman/listinfo/bitcoin-<wbr class=3D"">dev</a><br =
class=3D"">
</blockquote></div><br class=3D""></div></div>
=
</div></blockquote></div>_______________________________________________<b=
r class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></blockquote></div><br class=3D""></body></html>=
--Apple-Mail=_E40D9A28-3FF7-44D7-ACF3-4F906AB74C43--
|
