Content-Type: multipart/alternative;
	boundary=Apple-Mail-501AAE1E-A8AE-4340-9F89-7F4F5A39EFC6
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
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>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why not witnessless nodes?
Precedence: list


--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--