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
|
Return-Path: <kalle@rosenbaum.se>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D50768D9
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Dec 2017 08:32:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com
[209.85.217.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3D0EFFE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Dec 2017 08:32:25 +0000 (UTC)
Received: by mail-ua0-f182.google.com with SMTP id p33so10108810uag.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Dec 2017 00:32:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=rosenbaum-se.20150623.gappssmtp.com; s=20150623;
h=mime-version:from:date:message-id:subject:to;
bh=kp0bAYpThKPDtZsgLpkvSphPynouGTONmQA9HRFvLIQ=;
b=Mr+HJWjXq/yOr5kNtXY3BR3dh8Y5uUxa4fD71TaZ7Lezfxa1Tde1AsyozW37q9Ew1U
VM5rshAnoE/tO/RfM8vo29BRXglZhelMKaxiH55OqaLGegKerPlqYtFZ90o1h3zyixNI
d77zBds7vt0oJMbOlMgSs62nE36PtcjpTs6Bc+qOtwDvkfsDwnyvYup4lALpgOGgG0yU
H4yMeD71wNJgHZSEJX38plIupB8f5q5/4kuyQ8MvIntzj2uhsbxf+1NfCCw4DKfqFRHw
KGDoH6+j+iOwVe5/mGodkgQsSet2Mm4928UREYTL5Pz1J4sMNsbKF06tQzuKK4bRDdtI
iSFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=kp0bAYpThKPDtZsgLpkvSphPynouGTONmQA9HRFvLIQ=;
b=KdpnzQpqKyjIoZOgEXkhZWDjJ4G/9p0Q9ep4xJkYlszazBI6hPCp4BRoWwAelutDIl
G+r6w4QsPimw0vLynclU8O79sdAfb4iGwz9uSg09V0HkAuixwwHAk9tOKnPJ3VanSqaq
cl4atmgtl1kXtPASRb7on7+ENrs5ATMG312ot/l7VsXpWN1Nujj8TjEIG3NnJVm2tQ75
4ZqFR6HAibGf+VTQWWoIKpdmJ/gTWfg78sTuBSQZgeXwGaOAA010FU7LMx7OMaPr3k1O
B3+I89c3l/3cAqwtpztZj/P/xvtfQP/eTxQzU139WYqU8oyk06Hpl2fQuPatvWxd/8+V
KmRg==
X-Gm-Message-State: AKGB3mKm/b34ywY1ITXqV7LKOIVkq9pdEYnTTX46vetFnvkvMj/NCrmp
Mne/WIVpSM1Cj1uk1B9gITjlDPEfT4bI4KPFbcaswuaAPfg=
X-Google-Smtp-Source: ACJfBovN9+chOxkIzDBF4KHlTbMZMdno5xHUtiP0tNRkgglcyqmRD9q9DVD1F47P1i4M/Msu+KNILfIBmZWGOQVxNQo=
X-Received: by 10.159.35.161 with SMTP id 30mr23483986uao.44.1513585943945;
Mon, 18 Dec 2017 00:32:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.30.138 with HTTP; Mon, 18 Dec 2017 00:32:23 -0800 (PST)
From: Kalle Rosenbaum <kalle@rosenbaum.se>
Date: Mon, 18 Dec 2017 09:32:23 +0100
Message-ID: <CAPswA9ycPdTtm9PeD5a2R36cZ46HwnkwJu06FXuoE-F5Dx+eZQ@mail.gmail.com>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c04063286bbce05609930ef"
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
X-Mailman-Approved-At: Mon, 18 Dec 2017 11:55:15 +0000
Subject: [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 08:32:26 -0000
--94eb2c04063286bbce05609930ef
Content-Type: text/plain; charset="UTF-8"
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. 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
--94eb2c04063286bbce05609930ef
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Dear list,</div><div><br></div><div>I find it hard to=
understand why a full node that does initial block</div><div>download also=
must download witnesses if they are going to skip</div><div>verification a=
nyway. If my full node skips signature verification for</div><div>blocks ea=
rlier than X, it seems the reasons for downloading the</div><div>witnesses =
for those blocks are:</div><div><br></div><div>* to be able to send witness=
es to other nodes.</div><div><br></div><div>* to verify the witness root ha=
sh of the blocks</div><div><br></div><div>I suppose that it's important=
to verify the witness root hash because</div><div>a bad peer may send me i=
nvalid witnesses during initial block</div><div>download, and if I don'=
t verify that the witness root hash actually</div><div>commits to them, I w=
ill get banned by peers requesting the blocks from</div><div>me because I s=
end them garbage.</div><div><br></div><div>So both the reasons above (there=
may be more that I don't know about)</div><div>are actually the same r=
eason: To be able to send witnesses to others</div><div>without getting ban=
ned.</div><div><br></div><div>What if a node could chose not to download wi=
tnesses and thus chose to</div><div>send only witnessless blocks to peers. =
Let's call these nodes</div><div>witnessless nodes. Note that witnessle=
ss nodes are only witnessless</div><div>for blocks up to X. Everything afte=
r X is fully verified.</div><div><br></div><div>Witnessless nodes would be =
able to sync faster because it needs to</div><div>download less data to cal=
culate their UTXO set. They would therefore</div><div>more quickly be able =
to provide full service to SPV wallets and its</div><div>local wallets as w=
ell as serving blocks to other witnessless nodes</div><div>with same or hig=
her assumevalid block. For witnessless nodes with</div><div>lower assumeval=
id they can serve at least some blocks. It could also</div><div>serve block=
s to non-segwit nodes.</div><div><br></div><div>Do witnessless nodes risk d=
ividing the network in two parts, one</div><div>witnessless and one with fu=
ll nodes, with few connections between the</div><div>parts?</div><div><br><=
/div><div>So basically, what are the reasons not to implement witnessless</=
div><div>nodes?</div><div><br></div><div>Thank you,</div><div>/Kalle</div><=
/div>
--94eb2c04063286bbce05609930ef--
|
