path: root/e5/125416c969463509ff44c689885c1a3cbc36ad

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 DBCA2BE4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 13:35:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f173.google.com (mail-ua0-f173.google.com
	[209.85.217.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E48C81A6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 13:35:45 +0000 (UTC)
Received: by mail-ua0-f173.google.com with SMTP id l36so10651987uae.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 05:35:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=rosenbaum-se.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=ezgU3v8LDwE/1XszAi0WjpqRFndHLURpZm0Ivlfxuh0=;
	b=PB8SoKL4kZBedwkG+MIObWFgsnMUXC12qkd+paxxJOK46N+5XWV7PdQqmrQDNEDaji
	szeVsISzfnAhOzQqHtP0AZdvTGnsoi7ipir0q44ykRyUHXOsGmYgJgIL/WPt3OieROPa
	4qP2xcBpASVE67O0tbPLBtDHNt5mR8hMVsL1z1Zg71zEmA0cv3pnkDfSr1fVqRW0HnmE
	gHlvUoH4iwwJ7L/5iAqUbIs7W27mGNk/tyGratLVs7KJc+nGrHPJes0O3WDemYp+ROnS
	M25Tlc3ubZWTIBfCg04rzoQtVo9IkpJXhcBrH2VHbvIgZ8lgTrD2lLBt/wyx7zmI3Ym2
	HXRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=ezgU3v8LDwE/1XszAi0WjpqRFndHLURpZm0Ivlfxuh0=;
	b=SnQKVqUyFW8ysAuvikSJrntZ5GoegXcehSrX7ipOIp0Tr7eWwDWiGgrlcpIIAgeaP2
	vrfcc765SPSEEmvpwppjzSf9lJrNtadhC8laq1AtxbYjIRPjO4vXzVZ+/utUN8TTg9ni
	dZXFMZuYOhgVDzbg+Eopf6zM+veW19Yap5Xn+a64UXMkjZuUH7z6lXkoIBUOTjZ5fXX/
	l9cZpDFOOJKBN1XJ/znbj4d2ROLuIrib/75jFXd1kSX5+vuMdhqAvjMC7nwmTiHECyjq
	FKGtnnmJ327AAWe+Y7aM3zuIdbQVDT6IpBhmQ++QejqjvZ61VKnbdD1GN+014LE5uHQm
	F0Zg==
X-Gm-Message-State: AKGB3mKG8uqGazt4RZsmS8TbGu8Vkxf0et9KkuVTG9YWlUZJE4q2xOG3
	p4mAeibkItDM79p4zbZwritDMhjulTa7FxjwzVhIFuZAa0g=
X-Google-Smtp-Source: ACJfBouuREpEKhtPvuG8FbFK9Lmt60GvZpITwazV+gJBChpYw3ppenq87gl8K+EcOSLechprstgWA952mnlotsfPynQ=
X-Received: by 10.176.81.233 with SMTP id h38mr8086950uaa.46.1513604144997;
	Mon, 18 Dec 2017 05:35:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.30.138 with HTTP; Mon, 18 Dec 2017 05:35:44 -0800 (PST)
In-Reply-To: <CD7FBCF6-5386-4E9E-A3B9-D5B3DBAF312C@voskuil.org>
References: <CAPswA9ycPdTtm9PeD5a2R36cZ46HwnkwJu06FXuoE-F5Dx+eZQ@mail.gmail.com>
	<CD7FBCF6-5386-4E9E-A3B9-D5B3DBAF312C@voskuil.org>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
Date: Mon, 18 Dec 2017 14:35:44 +0100
Message-ID: <CAPswA9zo1dLYHP9A+xrYLsrFO5GVYFqVLQC-A9uHQSCie7xeYg@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c19215e64b70005609d6d6f"
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 13:58:22 +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 13:35:47 -0000

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

2017-12-18 13:43 GMT+01:00 Eric Voskuil <eric@voskuil.org>:

>
> > 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
> verification anyway.
>
> Why run a full node if you are not going to verify the chain?
>

I meant to say "I find it hard to understand why a full node that does
initial block
download also must download witnesses when it is going to skip verification
of the witnesses anyway."

I'm referring to the "assumevalid" feature of Bitcoin Core that skips
signature verification up to block X. Or have I misunderstood assumevalid?

/Kalle


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

--94eb2c19215e64b70005609d6d6f
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">2017=
-12-18 13:43 GMT+01:00 Eric Voskuil <span dir=3D"ltr">&lt;<a href=3D"mailto=
:eric@voskuil.org" target=3D"_blank">eric@voskuil.org</a>&gt;</span>:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft: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>li=
nuxfoundation.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<b=
r>
&gt; download also must download witnesses if they are going to skip verifi=
cation anyway.<br>
<br>
</span>Why run a full node if you are not going to verify the chain?<br></b=
lockquote><div><br></div>I meant to say &quot;<span style=3D"color:rgb(80,0=
,80);font-size:12.8px">I find it hard to understand why a full node that do=
es initial block</span><br style=3D"color:rgb(80,0,80);font-size:12.8px"><s=
pan style=3D"color:rgb(80,0,80);font-size:12.8px">download also must downlo=
ad witnesses when it is going to skip verification of the witnesses anyway.=
&quot;</span></div><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 st=
yle=3D"color:rgb(80,0,80);font-size:12.8px">I&#39;m referring to the &quot;=
assumevalid&quot; feature of Bitcoin Core that skips signature verification=
 up to block X. Or have I misunderstood assumevalid?</span></div><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(80,0,80);fon=
t-size:12.8px">/Kalle</span></div><div class=3D"gmail_quote">=C2=A0<br></di=
v><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">
<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&#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; 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>
</div></div>&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.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-<wbr>dev</a><br>
</blockquote></div><br></div></div>

--94eb2c19215e64b70005609d6d6f--