path: root/ae/85128269847b46a0fe75697bba274ab1cf29af

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 4151892F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 20:34:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com
	[209.85.213.47])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7DAC4403
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 20:34:32 +0000 (UTC)
Received: by mail-vk0-f47.google.com with SMTP id j192so10262808vkc.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 12:34:32 -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=55+wCnqZSUpr+JyCLFx2qbob8+aS5VL3f01WIKD5d6s=;
	b=djUC3XixXtd54Wywnx5b+Ztb827RnegH10IA326X0XQbKtBRV9m2zNegFT3yNRXE9j
	QpGekQHUMG20cvzEhfyBeHYRh34jRv27bXbhRZ4wfh8YD/PjzCsHu55jvTYWxirpxOHe
	8ufOjAol00427JUWe9oo/tMaVoeS/1px2UojjOlo92eGkAH9DBAuhTr8tIGGQX6vho3H
	QF1j+fPalY8Bnw4vV+42SZF1YAld0P81wOPqnGPnYq8wePMtbghRP6ovnkurIwNAo590
	u9aIbQHLUioh8WtiX+IASVpLHBkJhrGnFkqiSp/3v6cDOy2z0wRb9E0KE2KJnmHyXRqU
	BvvA==
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=55+wCnqZSUpr+JyCLFx2qbob8+aS5VL3f01WIKD5d6s=;
	b=udQrtWLf9iyauGsN/hEw1KcJN2NvuEAfQW8pmHyh1dyYrVeRxsL54MJNLV5umLmbcM
	oZovKT+7GVxkLDV76psqAY8zfHC1RufGuxw80OkQTOmP0Bob3T5d3QapTYLtTwnMEjd3
	hUzA3wK3tFz7EPoXIGxDgv7GTQzxcERTZlsnOPyAf1kJMs6EQPbG9BUsEOzeWFgzG1og
	yQAL8tALTjAIdkZI/pVouXbg1aFTE05cGgCoY7SQuPWcS5FCz7R36E/sW9LRdg4z/JM1
	W/zdHPO+ALmeD8943x0fdriqM9A9vpsQINmO7XxfVppPsmjRKztFxbbjVFLNncBEvHO7
	MT0A==
X-Gm-Message-State: AKGB3mIrfTylDitFzWJK0WuNYyDSkgm2NH1FdpJhjfy7exDbngBhwyG/
	S0o9as+vCxX0bwVTacqIgbPbuqLTqgNffbz1UF+mJhpd
X-Google-Smtp-Source: ACJfBotSabRgo4wgE8GU6T1tJHFL4F815asUO4+vA6/xwUtQCCO5Ug7byxX8hkKeGA7xyceApztr4SHsQisKGq7Qu3o=
X-Received: by 10.31.164.204 with SMTP id n195mr1077509vke.144.1513629271586; 
	Mon, 18 Dec 2017 12:34:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.30.138 with HTTP; Mon, 18 Dec 2017 12:34:30 -0800 (PST)
Received: by 10.176.30.138 with HTTP; Mon, 18 Dec 2017 12:34:30 -0800 (PST)
In-Reply-To: <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>
	<A2B6418E-069F-476A-86EE-638C6D9E826A@voskuil.org>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
Date: Mon, 18 Dec 2017 21:34:30 +0100
Message-ID: <CAPswA9z2+kf7LrCQpsPftPC7SdcUT0fi6GqeyxMtwxAop00xFA@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary="001a1142e10a0e0b340560a34773"
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 20:39:24 +0000
Cc: bitcoin-dev <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 20:34:34 -0000

--001a1142e10a0e0b340560a34773
Content-Type: text/plain; charset="UTF-8"

Thanks Eric.

It would be a pity if early witnesses got lost due to nodes abandoning them
by running witnessless. But as long as there's at least one accessible
source for them left we're OKish. Let's hope we don't get to that point in
the near future. As long as Bitcoin Core doesn't implement witnessless
mode, there's little risk.

What do people here think about the benefits and risks with running
witnessless?

/Kalle

Sent from my Sinclair ZX81

Den 18 dec. 2017 17:19 skrev "Eric Voskuil" <eric@voskuil.org>:

> You can't know (assume) a block is valid unless you have previously
> validated the block yourself. But in the case where you have, and then
> intend to rely on it in a future sync, there is no need for witness data
> for blocks you are not going to validate. So you can just not request it.
>
> However you will not be able to provide those blocks to nodes that *are*
> validating; 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 than 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
> transactions nor to extract payment addresses from them.
>
> The harm to the network by pruning is that eventually it can become harder
> and even impossible for anyone to validate the chain. But because you are
> fully validating you individually remain secure, so there is no individual
> incentive working against this system harm.
>
> e
>
> On Dec 18, 2017, at 08:35, Kalle Rosenbaum <kalle@rosenbaum.se> wrote:
>
> 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
>>
>
>

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

<div dir=3D"auto"><span style=3D"font-family:sans-serif">Thanks Eric.</span=
><div style=3D"font-family:sans-serif" dir=3D"auto"><br></div><div style=3D=
"font-family:sans-serif" dir=3D"auto">It would be a pity if early witnesses=
 got lost due to nodes abandoning them by running witnessless. But as long =
as there&#39;s at least one accessible source for them left we&#39;re OKish=
. Let&#39;s hope we don&#39;t get to that point in the near future. As long=
 as Bitcoin Core doesn&#39;t implement witnessless mode, there&#39;s little=
 risk.=C2=A0</div><div style=3D"font-family:sans-serif" dir=3D"auto"><br></=
div><div dir=3D"auto" style=3D"font-family:sans-serif">What do people here =
think about the benefits and risks with running witnessless?=C2=A0</div><di=
v dir=3D"auto" style=3D"font-family:sans-serif"><br></div><div style=3D"fon=
t-family:sans-serif" dir=3D"auto">/Kalle</div><br><div data-smartmail=3D"gm=
ail_signature">Sent from my Sinclair ZX81</div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">Den 18 dec. 2017 17:19 skrev &quot;Eric=
 Voskuil&quot; &lt;<a href=3D"mailto:eric@voskuil.org">eric@voskuil.org</a>=
&gt;:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"au=
to"><div></div><div>You can&#39;t know (assume) a block is valid unless you=
 have previously validated the block yourself. But in the case where you ha=
ve, and then intend to rely on it in a future sync, there is no need for wi=
tness data for blocks you are not going to validate. So you can just not re=
quest it.=C2=A0</div><div><br></div><div>However you will not be able to pr=
ovide those blocks to nodes that *are* validating; 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 than the witnessless client.)</d=
iv><div><br></div><div>There is no other reason that a node requires witnes=
s data. SPV clients don&#39;t need it as it is neither require it to verify=
 header commitment to transactions nor to extract payment addresses from th=
em.</div><div><br></div><div>The harm to the network by pruning is that eve=
ntually it can become harder and even impossible for anyone to validate the=
 chain. But because you are fully validating you individually remain secure=
, so there is no individual incentive working against this system harm.</di=
v><div><br></div><div>e</div><div><br>On Dec 18, 2017, at 08:35, Kalle Rose=
nbaum &lt;<a href=3D"mailto:kalle@rosenbaum.se" target=3D"_blank">kalle@ros=
enbaum.se</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><div><div d=
ir=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><blockqu=
ote 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"m_8641878199240195=
011gmail-"><br>
&gt; On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfounda<wbr>tion.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"m_8641878199240195011gmail-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" 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>
</blockquote></div><br></div></div>
</div></blockquote></div></blockquote></div></div>

--001a1142e10a0e0b340560a34773--