MIME-Version: 1.0
In-Reply-To: <CAAS2fgRuLWbQLw=2EQEODGHOp0=OrLkGguw=jJSCpQXEC_P+hQ@mail.gmail.com>
References: <CAPswA9ycPdTtm9PeD5a2R36cZ46HwnkwJu06FXuoE-F5Dx+eZQ@mail.gmail.com>
	<CAAS2fgRuLWbQLw=2EQEODGHOp0=OrLkGguw=jJSCpQXEC_P+hQ@mail.gmail.com>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
Date: Mon, 18 Dec 2017 22:51:40 +0100
Message-ID: <CAPswA9xurB=RJq4z1pJxkLN+ojSccf+T5nK4YJh2eAwwpb7r9A@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary="94eb2c19215e02814f0560a45b5d"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why not witnessless nodes?
Precedence: list

--94eb2c19215e02814f0560a45b5d
Content-Type: text/plain; charset="UTF-8"

Hi Greg,

2017-12-18 21:42 GMT+01:00 Gregory Maxwell <greg@xiph.org>:

> Because it would make no meaningful difference now,


Sure.


> and if you are not
> going to check the history


I'm not going to do any less checks than a node running with assumevalid.
Well not exactly true, because a node running today with assumevalid will
verify the witness root hash, right?


> there are much more efficient things to
> do-- like not transfer it at all.
>

I'm not sure what you are referring to.

Thank you
/Kalle


>
> On Mon, Dec 18, 2017 at 8:32 AM, 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
> > 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
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

--94eb2c19215e02814f0560a45b5d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">Hi G=
reg,</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">2=
017-12-18 21:42 GMT+01:00 Gregory Maxwell <span dir=3D"ltr">&lt;<a href=3D"=
mailto:greg@xiph.org" target=3D"_blank">greg@xiph.org</a>&gt;</span>:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">Because it would make no meaningful difference=
 now, </blockquote><div><br></div><div>Sure.</div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">and if you are not<br>
going to check the history</blockquote><div><br></div><div>I&#39;m not goin=
g to do any less checks than a node running with assumevalid. Well not exac=
tly true, because a node running today with assumevalid will verify the wit=
ness root hash, right?</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
> there are much more efficient things to<br>
do-- like not transfer it at all.<br></blockquote><div><br></div><div>I&#39=
;m not sure what you are referring to.</div><div><br></div><div>Thank you</=
div><div>/Kalle</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"m_-1044669899652844137HOEnZb"><div class=3D"m_-10446698996528=
44137h5"><br>
On Mon, Dec 18, 2017 at 8:32 AM, Kalle Rosenbaum via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br>
&gt; Dear list,<br>
&gt;<br>
&gt; I find it hard to understand why a full node that does initial block<b=
r>
&gt; download also must download witnesses if they are going to skip<br>
&gt; verification anyway. 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&#39;s important to verify the witness root hash beca=
use<br>
&gt; a bad peer may send me invalid witnesses during initial block<br>
&gt; download, and if I don&#39;t verify that the witness root hash actuall=
y<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;<br>
&gt; So both the reasons above (there may be more that I don&#39;t know abo=
ut)<br>
&gt; are actually the same reason: To be able to send witnesses to others<b=
r>
&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&#39;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<b=
r>
&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<b=
r>
&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<=
br>
&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>
&gt;<br>
</div></div><div class=3D"m_-1044669899652844137HOEnZb"><div class=3D"m_-10=
44669899652844137h5">&gt; ______________________________<wbr>______________=
___<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
&gt;<br>
</div></div></blockquote></div><br></div></div>

--94eb2c19215e02814f0560a45b5d--