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
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id ADED3BD1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Dec 2017 12:44:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com
[209.85.216.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1EA01403
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Dec 2017 12:44:02 +0000 (UTC)
Received: by mail-qt0-f180.google.com with SMTP id w10so19723905qtb.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Dec 2017 04:44:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=from:content-transfer-encoding:mime-version:date:subject:message-id
:references:in-reply-to:to;
bh=2D9vXo/ZQOJb/u9GzPXtdrFDIqyv/6c8E2MOf6m0uuk=;
b=xIJCrxhQpPMzhqdWa0fi6nuoFpyOkqd67HcH+Ck210RGXAsGA3cowkmibrp3s/Xlax
pDzxMCzwIHzzm3cSgP/SAW2DFUIVYUj28TDD1cFaHLPCoKAKOWMD2QRoTJ7UTIKoVVlg
NwqnkTSpWYETDgtH4Xz1tQ98+y11MTVOoI7mkV3YyOmU6jj6GB/mxFjL7Vbv9VQDiQbb
psvrEAVJKBWZ81SacHzSomiOhWGgEDl+Dc+bVzcIBNQqJrMM82ojv0kfgQ5l4Cd+6qwU
TKNe5Av5KnEpyvOE88AW53RuPTid1rUZsxAamWDdArPd/BN/+1Nh+obB6lcZl6vdFCbR
IC4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:content-transfer-encoding:mime-version:date
:subject:message-id:references:in-reply-to:to;
bh=2D9vXo/ZQOJb/u9GzPXtdrFDIqyv/6c8E2MOf6m0uuk=;
b=b+gcX5wy4s5471s1DSHlHuxmvdb0qVmDlTR76HIaLyp0XxmQzAMucgkKNGj7dDuier
D/y7yFVQcNGeVpzlrLvenPGRUXyaBDfiM0xJWLvUxhf2EkoMyEeB0A8CWAP/Er6rD+F7
BNA+82Eg3HJQFAPy8YHO7aY9WmyzkZ/klbvLJL9A6uWXEoSqpOHa/Xi1m/WuAa9ZB6Nx
ztbWSHLfZmyYcAadC65kNDxr4fsD4Me8IkoOTMamJ8oQCKbZILetR28jPnDWOPxAaPt6
Xd8TJ9PARF0Lyy/O02gULUo5t694/8hkLRNYaxZ+Ixb8x6EnMuyPq8dsgFnTcV6FkFTO
kQFA==
X-Gm-Message-State: AKGB3mLKvGAB1sQYgKQjqz7VbMTKZyEkW4hM8PGdUQdOvRJQjsxwt7HZ
8K+YjVrjuMOmY82NcUAQLlt3tJleEmU=
X-Google-Smtp-Source: ACJfBossqdCouoyN3oPEWyDvTrW9iEtyViLmkwC8VRS0dDBESJrjKVA3hYy2Wu2drJ8LMozrPYs4OA==
X-Received: by 10.237.56.5 with SMTP id j5mr36290551qte.53.1513601041167;
Mon, 18 Dec 2017 04:44:01 -0800 (PST)
Received: from ?IPv6:2600:380:8c78:ea97:2452:3928:8ddd:33dd?
([2600:380:8c78:ea97:2452:3928:8ddd:33dd])
by smtp.gmail.com with ESMTPSA id
c16sm8012130qtd.80.2017.12.18.04.43.59
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 18 Dec 2017 04:44:00 -0800 (PST)
From: Eric Voskuil <eric@voskuil.org>
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Mon, 18 Dec 2017 07:43:58 -0500
Message-Id: <CD7FBCF6-5386-4E9E-A3B9-D5B3DBAF312C@voskuil.org>
References: <CAPswA9ycPdTtm9PeD5a2R36cZ46HwnkwJu06FXuoE-F5Dx+eZQ@mail.gmail.com>
In-Reply-To: <CAPswA9ycPdTtm9PeD5a2R36cZ46HwnkwJu06FXuoE-F5Dx+eZQ@mail.gmail.com>
To: Kalle Rosenbaum <kalle@rosenbaum.se>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (14G60)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, MIME_QP_LONG_LINE,
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 13:58:11 +0000
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 12:44:02 -0000
> On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:
>=20
> Dear list,
>=20
> 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 verificati=
on anyway.
Why run a full node if you are not going to verify the chain?
> If my full node skips signature verification for
> blocks earlier than X, it seems the reasons for downloading the
> witnesses for those blocks are:
>=20
> * to be able to send witnesses to other nodes.
>=20
> * to verify the witness root hash of the blocks
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Do witnessless nodes risk dividing the network in two parts, one
> witnessless and one with full nodes, with few connections between the
> parts?
>=20
> So basically, what are the reasons not to implement witnessless
> nodes?
>=20
> Thank you,
> /Kalle
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
