From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A780CB3 for ; Mon, 18 Dec 2017 17:30:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pl0-f52.google.com (mail-pl0-f52.google.com [209.85.160.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 835AF405 for ; Mon, 18 Dec 2017 17:30:20 +0000 (UTC) Received: by mail-pl0-f52.google.com with SMTP id s3so5210484plp.4 for ; Mon, 18 Dec 2017 09:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=QfOZ7UJ+mfDNVs6GjkFxN14vMKnasp31Z12vV1CfW4Y=; b=uGy06dFlLNj8u2EN5otLomcXLgmFHzzwaas3rsoldvYXWeJ5V7OgPt7Xw2QLZqEaiL YCkoIW9mNcdn7RdA4IDrUdjNDOUDSDuM7XVSt18H3bKNxkR4pTX/mhG+N4F8D9eqdova JdY2EX/rHqOizLjAMyshXPfkTEvU6mSB6WFACkY0j3zRh2QsajkptfktgC0/M0aJfARB 5JYcUHKbEEQj+JgL8x2sF6JNTZTW71LsgbMSSypC1GsGnhH2wUxYvYgE9xS4itfjDeQt pnIITKsdwd1emv16s7d16uKCDaoeK8u4ynxSjVvP5FDQVlaGaeVifBED8McJ3joVqmGe yp7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=QfOZ7UJ+mfDNVs6GjkFxN14vMKnasp31Z12vV1CfW4Y=; b=QJxu43EALG9Om29dIaMdGd9a6riSs7kYbyCqWtZG8pFqXDsg9wBZ8Njl3M46IwO4Tc 0Onnah2W2sjbcj23EksgLn3e47C+Qu6Hjod81W3XWPOBFSp6T64OY9shN29x49XiKNYS 5IpzY/ohLurlbMCxZuCDyZOIk0mfcYFUYP6iruji7oxdCOVge3bzmMUGV0a2GurrtxF9 EM9nFEflegT11ZYIaP2FUfmpNghggAYxD4cRmI78I+B4ER3Po3jSCRvl8hxjs+Y4ASrT vxvzIMzNVbLSj01AdViq7vILYEh8huvlW2BlkDTAm26qnH18/TlxjiPlWGRgXS8BsZec dfWA== X-Gm-Message-State: AKGB3mK+H623T3Wy0qIaw5j4GxACncHqLeU/sxgXXh+0/Rap+xHx5gVE URslC63uwxoLxRV4cGtWwUp0d56jjXA= X-Google-Smtp-Source: ACJfBov7KvbA1vxjIjCWAjVDAV2gtRBc6lpKuoHGGWCbdBmEx+yPGpuzgHQy+TuzV/XSDjKp7mGpow== X-Received: by 10.84.215.146 with SMTP id l18mr394351pli.451.1513618220036; Mon, 18 Dec 2017 09:30:20 -0800 (PST) Received: from ?IPv6:2601:646:8080:4dbb:949b:6f19:8460:3d9? ([2601:646:8080:4dbb:949b:6f19:8460:3d9]) by smtp.gmail.com with ESMTPSA id j17sm22133910pgv.40.2017.12.18.09.30.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 09:30:19 -0800 (PST) From: Mark Friedenbach Content-Type: multipart/alternative; boundary="Apple-Mail=_E40D9A28-3FF7-44D7-ACF3-4F906AB74C43" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 18 Dec 2017 09:30:17 -0800 References: To: Eric Voskuil , Bitcoin Protocol Discussion In-Reply-To: Message-Id: <61B0AEC9-3B1D-416F-8883-A030E5109538@friedenbach.org> X-Mailer: Apple Mail (2.3445.5.20) 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 17:30:21 -0000 --Apple-Mail=_E40D9A28-3FF7-44D7-ACF3-4F906AB74C43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sign-to-contract enables some interesting protocols, none of which are = in wide use as far as I=E2=80=99m aware. But if they were (and arguably = this is an area that should be more developed), then SPV nodes = validating these protocols will need access to witness data. If a node = is performing IBD with assumevalid set to true, and is also intending to = prune history, then there=E2=80=99s no reason to fetch those witnesses = as far as I=E2=80=99m aware. But it would be a great disservice to the = network for nodes intending to serve SPV clients to prune this portion = of the block history.=20 > On Dec 18, 2017, at 8:19 AM, Eric Voskuil via bitcoin-dev = wrote: >=20 > 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.=20 >=20 > 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.) >=20 > 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. >=20 > 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. >=20 > e >=20 > On Dec 18, 2017, at 08:35, Kalle Rosenbaum > wrote: >=20 >> 2017-12-18 13:43 GMT+01:00 Eric Voskuil >: >>=20 >> > On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev = > 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. >>=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 initial block >> download also must download witnesses when it is going to skip = verification of the witnesses anyway." >>=20 >> I'm referring to the "assumevalid" feature of Bitcoin Core that skips = signature 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_E40D9A28-3FF7-44D7-ACF3-4F906AB74C43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sign-to-contract enables some interesting protocols, none of = which are in wide use as far as I=E2=80=99m aware. But if they were (and = arguably this is an area that should be more developed), then SPV nodes = validating these protocols will need access to witness data. If a node = is performing IBD with assumevalid set to true, and is also intending to = prune history, then there=E2=80=99s no reason to fetch those witnesses = as far as I=E2=80=99m aware. But it would be a great disservice to the = network for nodes intending to serve SPV clients to prune this portion = of the block history. 

On Dec 18, 2017, at 8:19 AM, = Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

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

=
_______________________________________________bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">
= --Apple-Mail=_E40D9A28-3FF7-44D7-ACF3-4F906AB74C43--