path: root/90/96af557251031d88439e6f7336acbd6c29f0a2

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 E2F4BBAD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 21:51:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com
	[209.85.217.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3959B1A6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 21:51:42 +0000 (UTC)
Received: by mail-ua0-f169.google.com with SMTP id i4so11676406uab.5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 13:51:42 -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
	:cc; bh=7iHHYqprp3c9kF9YqusoqXZlHORq2Q6Ww1x3J0AHdNE=;
	b=QYz8g8RIFFADkwkl88EZG5yjwFyONRcvU0t3tfQHL3QGrNhK20q2GbmQHxrVUziJcy
	yDe3A4gBLMfqgW8QWtweeq8eOmyE3OTAk608ncx3f9PqpX0rlyyMJd7xuWzofm+MCLdL
	WqfrIjuBiWjgglQdELl1t7bv3RHazGos7zTTvamJZKTmOGq5PBz9mf/agVZ6y7jsHNwx
	Kf9jWW+GW3IE0bHwQkMaf024Sr3DR9Lv7e+ldme3/RMgiOQK0FvLp/vwJHspIeRTintw
	bHfhqYMrwazVO166N8AtD/+My9VcMNnFtpBp7bgx7cJvBxA5zAhoSd2NDzv+U61WyvJX
	Hq/w==
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:cc;
	bh=7iHHYqprp3c9kF9YqusoqXZlHORq2Q6Ww1x3J0AHdNE=;
	b=hsHdNh4HRuU4J8HCl2Oaw113uTslsysEiRiJ0RlCRG+ObGvbCzZ388MS6BGMYPZ2Cd
	jGHEnQI0ln8uicTEV9QaPviUblg73Z9FYyA2X51hLVtX6py/2D7PRfbV/2MjHgwu3JAM
	nM0c71qCzyI/MEbSARb9reXTKhm5WIO1BTtPy4flC+oswkktZYfyXfEQNiutYSjFP15z
	PdjTn/lurmZN9XPOXCPN5dnU0JCzq4Bli/qpkPLPcpbyhGZR346rmfhYBpvsTiJaeWIB
	2HTjL+Xry5Hs4Im8kXH6eD6TTrKfPBT1yfUEGvtIE83emzkxvYmOh7X7eYtK3iH5PuEM
	HQ7g==
X-Gm-Message-State: AKGB3mLgn46oMuUEV20CON7WLh3hzIK6dKkdVi9D7SoJVyvh5bWYAA7Q
	wnmiH79a4olvu70lr2SlJxU4yHcMjPE4zR5+KolP4nGb
X-Google-Smtp-Source: ACJfBoskdG1jsepRMpVF62RER6Uhu8urkvgMYmGRnAGiq2J7Fg9pufb1gNvXMnxJ64JqcZT4OmIL3CwbXHRB6SsXzWo=
X-Received: by 10.176.81.233 with SMTP id h38mr1381183uaa.46.1513633901343;
	Mon, 18 Dec 2017 13:51:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.30.138 with HTTP; Mon, 18 Dec 2017 13:51:40 -0800 (PST)
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"
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 22:14: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 21:51:43 -0000

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