path: root/a3/d388f8bccb11a35b44710c652ffc06dda1ea32

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 708F8B1E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 16:19:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com
	[209.85.220.176])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E42D5171
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 16:19:37 +0000 (UTC)
Received: by mail-qk0-f176.google.com with SMTP id z203so18986688qkb.5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 08:19:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=oSklJM7iQo2B2a88+nmeFteDJAfZ28Nhm/sVzrs/cPY=;
	b=pI79YsMRVG3sxSdo96R1UPTEKhiIeK9XHJBsTyJtO7urQD0WFp512IHFgnTEjCgPVE
	6L87LSkztZQNj8dS3AI24K1gZSrtKHy832CnETXFCO1ntx9KAa0xXl5sHQMutYVIaRYh
	9ITZgRw/EyjuoabQlttkAq4PepK5Xpy+zcQPOAdeIX1CTrWLIxz/cLPUGyC29LTP7z0E
	upAIP4iFX6q7dgdbr3IAhumFalUemIFOKfIKbNdBYT/abAn0/Av7meF5fsvqFH/dGFVt
	k18YuG3wsBR+e13izY/wQWdUJBS8+boi9hCpf6W/aoxFrSgKDcKRx8lPO343BBz+6Xh4
	r8nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=oSklJM7iQo2B2a88+nmeFteDJAfZ28Nhm/sVzrs/cPY=;
	b=PSRIwVb6Jg815wWw7zUQb4mDWcJQLc45/4G8nGEqxo8tbl9UFc0boVeInVRdQiuPM2
	W/ejFDgilFjpCbmdz5k9byreL4Ba5ir4lXVYiKEpOGGUzU7Oz5/YW3P5WecPFrVsv0dZ
	z2pSwHCtmNoah2kBSOzw6uYloAJdQ2MX46zjZGRnqXMFpkxIMljs+8XbSzdsT1YIhL4u
	6Xv1DOx0QSG07LxfE6QdmoJz75YsW7B62OwyeO1Yo+tCeyzD1BdwjG4DrD7JdmXeiUPy
	tcW1POb7VQRVFBunsqmNTDZ/55ryVDkyXJdnqPkGkzLLx6XcNSSL8SaWjru5Gvd8MLrz
	CHYg==
X-Gm-Message-State: AKGB3mLJR73Xs5N1MGOXN7PMq9VMSMP+nCFt0FC8YYX8+Rqyb96Fzj3D
	K/JNbc8F+pZIf6EHATYobeNnPg==
X-Google-Smtp-Source: ACJfBotB/717A7CA0mSB8C6rgsOxkiLgW78PAPIyEZQlg0j1JZj0GwM+ALbODyF36nahN6jwqkrX+Q==
X-Received: by 10.55.221.20 with SMTP id n20mr350121qki.181.1513613977073;
	Mon, 18 Dec 2017 08:19:37 -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 n3sm8209793qte.14.2017.12.18.08.19.35
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 18 Dec 2017 08:19:35 -0800 (PST)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-501AAE1E-A8AE-4340-9F89-7F4F5A39EFC6
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <CAPswA9zo1dLYHP9A+xrYLsrFO5GVYFqVLQC-A9uHQSCie7xeYg@mail.gmail.com>
Date: Mon, 18 Dec 2017 11:19:34 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <A2B6418E-069F-476A-86EE-638C6D9E826A@voskuil.org>
References: <CAPswA9ycPdTtm9PeD5a2R36cZ46HwnkwJu06FXuoE-F5Dx+eZQ@mail.gmail.com>
	<CD7FBCF6-5386-4E9E-A3B9-D5B3DBAF312C@voskuil.org>
	<CAPswA9zo1dLYHP9A+xrYLsrFO5GVYFqVLQC-A9uHQSCie7xeYg@mail.gmail.com>
To: Kalle Rosenbaum <kalle@rosenbaum.se>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, 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 16:21:12 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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 16:19:39 -0000


--Apple-Mail-501AAE1E-A8AE-4340-9F89-7F4F5A39EFC6
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

You can't know (assume) a block is valid unless you have previously validate=
d the block yourself. But in the case where you have, and then intend to rel=
y on it in a future sync, there is no need for witness data for blocks you a=
re not going to validate. So you can just not request it.=20

However you will not be able to provide those blocks to nodes that *are* val=
idating; 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 t=
han the witnessless client.)

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 transac=
tions nor to extract payment addresses from them.

The harm to the network by pruning is that eventually it can become harder a=
nd even impossible for anyone to validate the chain. But because you are ful=
ly validating you individually remain secure, so there is no individual ince=
ntive working against this system harm.

e

> On Dec 18, 2017, at 08:35, Kalle Rosenbaum <kalle@rosenbaum.se> wrote:
>=20
> 2017-12-18 13:43 GMT+01:00 Eric Voskuil <eric@voskuil.org>:
>>=20
>> > On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev <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 verific=
ation 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 ini=
tial block
> download also must download witnesses when it is going to skip verificatio=
n of the witnesses anyway."
>=20
> I'm referring to the "assumevalid" feature of Bitcoin Core that skips sign=
ature 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
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20

--Apple-Mail-501AAE1E-A8AE-4340-9F89-7F4F5A39EFC6
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div></div><div>You can't know (assume) a b=
lock is valid unless you have previously validated the block yourself. But i=
n the case where you have, and then intend to rely on it in a future sync, t=
here is no need for witness data for blocks you are not going to validate. S=
o you can just not request it.&nbsp;</div><div><br></div><div>However you wi=
ll not be able to provide those blocks to nodes that *are* validating; the c=
lient is pruned and therefore not a peer (cannot reciprocate). (An SPV clien=
t is similarly not a peer; it is a more deeply pruned client than the witnes=
sless client.)</div><div><br></div><div>There is no other reason that a node=
 requires witness data. SPV clients don't need it as it is neither require i=
t to verify header commitment to transactions nor to extract payment address=
es from them.</div><div><br></div><div>The harm to the network by pruning is=
 that eventually it can become harder and even impossible for anyone to vali=
date the chain. But because you are fully validating you individually remain=
 secure, so there is no individual incentive working against this system har=
m.</div><div><br></div><div>e</div><div><br>On Dec 18, 2017, at 08:35, Kalle=
 Rosenbaum &lt;<a href=3D"mailto:kalle@rosenbaum.se">kalle@rosenbaum.se</a>&=
gt; wrote:<br><br></div><blockquote type=3D"cite"><div><div dir=3D"ltr"><div=
 class=3D"gmail_extra"><div class=3D"gmail_quote">2017-12-18 13:43 GMT+01:00=
 Eric Voskuil <span dir=3D"ltr">&lt;<a href=3D"mailto:eric@voskuil.org" targ=
et=3D"_blank">eric@voskuil.org</a>&gt;</span>:<br><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>
&gt; On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev &lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxf=
oundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Dear list,<br>
&gt;<br>
&gt; I find it hard to understand why a full node that does initial block<br=
>
&gt; download also must download witnesses if they are going to skip verific=
ation anyway.<br>
<br>
</span>Why run a full node if you are not going to verify the chain?<br></bl=
ockquote><div><br></div>I meant to say "<span style=3D"color:rgb(80,0,80);fo=
nt-size:12.8px">I find it hard to understand why a full node that does initi=
al block</span><br style=3D"color:rgb(80,0,80);font-size:12.8px"><span style=
=3D"color:rgb(80,0,80);font-size:12.8px">download also must download witness=
es when it is going to skip verification of the witnesses anyway."</span></d=
iv><div class=3D"gmail_quote"><span style=3D"color:rgb(80,0,80);font-size:12=
.8px"><br></span></div><div class=3D"gmail_quote"><span style=3D"color:rgb(8=
0,0,80);font-size:12.8px">I'm referring to the "assumevalid" feature of Bitc=
oin Core that skips signature verification up to block X. Or have I misunder=
stood assumevalid?</span></div><div class=3D"gmail_quote"><span style=3D"col=
or:rgb(80,0,80);font-size:12.8px"><br></span></div><div class=3D"gmail_quote=
"><span style=3D"color:rgb(80,0,80);font-size:12.8px">/Kalle</span></div><di=
v class=3D"gmail_quote">&nbsp;<br></div><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">
<div><div class=3D"gmail-h5"><br>
&gt; If my full node skips signature verification for<br>
&gt; blocks earlier than X, it seems the reasons for downloading the<br>
&gt; witnesses for those blocks are:<br>
&gt;<br>
&gt; * to be able to send witnesses to other nodes.<br>
&gt;<br>
&gt; * to verify the witness root hash of the blocks<br>
&gt;<br>
&gt; I suppose that it's important to verify the witness root hash because<b=
r>
&gt; a bad peer may send me invalid witnesses during initial block<br>
&gt; download, and if I don't verify that the witness root hash actually<br>=

&gt; commits to them, I will get banned by peers requesting the blocks from<=
br>
&gt; me because I send them garbage.<br>
&gt; So both the reasons above (there may be more that I don't know about)<b=
r>
&gt; are actually the same reason: To be able to send witnesses to others<br=
>
&gt; without getting banned.<br>
&gt;<br>
&gt; What if a node could chose not to download witnesses and thus chose to<=
br>
&gt; send only witnessless blocks to peers. Let's call these nodes<br>
&gt; witnessless nodes. Note that witnessless nodes are only witnessless<br>=

&gt; for blocks up to X. Everything after X is fully verified.<br>
&gt;<br>
&gt; Witnessless nodes would be able to sync faster because it needs to<br>
&gt; download less data to calculate their UTXO set. They would therefore<br=
>
&gt; more quickly be able to provide full service to SPV wallets and its<br>=

&gt; local wallets as well as serving blocks to other witnessless nodes<br>
&gt; with same or higher assumevalid block. For witnessless nodes with<br>
&gt; lower assumevalid they can serve at least some blocks. It could also<br=
>
&gt; serve blocks to non-segwit nodes.<br>
&gt;<br>
&gt; Do witnessless nodes risk dividing the network in two parts, one<br>
&gt; witnessless and one with full nodes, with few connections between the<b=
r>
&gt; parts?<br>
&gt;<br>
&gt; So basically, what are the reasons not to implement witnessless<br>
&gt; nodes?<br>
&gt;<br>
&gt; Thank you,<br>
&gt; /Kalle<br>
</div></div>&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>=
org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div><br></div></div>
</div></blockquote></body></html>=

--Apple-Mail-501AAE1E-A8AE-4340-9F89-7F4F5A39EFC6--