Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 708F8B1E for ; Mon, 18 Dec 2017 16:19:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E42D5171 for ; Mon, 18 Dec 2017 16:19:37 +0000 (UTC) Received: by mail-qk0-f176.google.com with SMTP id z203so18986688qkb.5 for ; Mon, 18 Dec 2017 08:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oSklJM7iQo2B2a88+nmeFteDJAfZ28Nhm/sVzrs/cPY=; b=pI79YsMRVG3sxSdo96R1UPTEKhiIeK9XHJBsTyJtO7urQD0WFp512IHFgnTEjCgPVE 6L87LSkztZQNj8dS3AI24K1gZSrtKHy832CnETXFCO1ntx9KAa0xXl5sHQMutYVIaRYh 9ITZgRw/EyjuoabQlttkAq4PepK5Xpy+zcQPOAdeIX1CTrWLIxz/cLPUGyC29LTP7z0E upAIP4iFX6q7dgdbr3IAhumFalUemIFOKfIKbNdBYT/abAn0/Av7meF5fsvqFH/dGFVt k18YuG3wsBR+e13izY/wQWdUJBS8+boi9hCpf6W/aoxFrSgKDcKRx8lPO343BBz+6Xh4 r8nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oSklJM7iQo2B2a88+nmeFteDJAfZ28Nhm/sVzrs/cPY=; b=PSRIwVb6Jg815wWw7zUQb4mDWcJQLc45/4G8nGEqxo8tbl9UFc0boVeInVRdQiuPM2 W/ejFDgilFjpCbmdz5k9byreL4Ba5ir4lXVYiKEpOGGUzU7Oz5/YW3P5WecPFrVsv0dZ z2pSwHCtmNoah2kBSOzw6uYloAJdQ2MX46zjZGRnqXMFpkxIMljs+8XbSzdsT1YIhL4u 6Xv1DOx0QSG07LxfE6QdmoJz75YsW7B62OwyeO1Yo+tCeyzD1BdwjG4DrD7JdmXeiUPy tcW1POb7VQRVFBunsqmNTDZ/55ryVDkyXJdnqPkGkzLLx6XcNSSL8SaWjru5Gvd8MLrz CHYg== X-Gm-Message-State: AKGB3mLJR73Xs5N1MGOXN7PMq9VMSMP+nCFt0FC8YYX8+Rqyb96Fzj3D K/JNbc8F+pZIf6EHATYobeNnPg== X-Google-Smtp-Source: ACJfBotB/717A7CA0mSB8C6rgsOxkiLgW78PAPIyEZQlg0j1JZj0GwM+ALbODyF36nahN6jwqkrX+Q== X-Received: by 10.55.221.20 with SMTP id n20mr350121qki.181.1513613977073; Mon, 18 Dec 2017 08:19:37 -0800 (PST) Received: from ?IPv6:2600:380:8c78:ea97:2452:3928:8ddd:33dd? ([2600:380:8c78:ea97:2452:3928:8ddd:33dd]) by smtp.gmail.com with ESMTPSA id n3sm8209793qte.14.2017.12.18.08.19.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 08:19:35 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-501AAE1E-A8AE-4340-9F89-7F4F5A39EFC6 Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Mon, 18 Dec 2017 11:19:34 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: To: Kalle Rosenbaum X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, MIME_QP_LONG_LINE, 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 16:21:12 +0000 Cc: Bitcoin Protocol Discussion 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 16:19:39 -0000 --Apple-Mail-501AAE1E-A8AE-4340-9F89-7F4F5A39EFC6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable You can't know (assume) a block is valid unless you have previously validate= d the block yourself. But in the case where you have, and then intend to rel= y on it in a future sync, there is no need for witness data for blocks you a= re not going to validate. So you can just not request it.=20 However you will not be able to provide those blocks to nodes that *are* val= idating; 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 t= han 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 transac= tions nor to extract payment addresses from them. The harm to the network by pruning is that eventually it can become harder a= nd even impossible for anyone to validate the chain. But because you are ful= ly validating you individually remain secure, so there is no individual ince= ntive working against this system harm. e > 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 verific= ation 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 ini= tial block > download also must download witnesses when it is going to skip verificatio= n of the witnesses anyway." >=20 > I'm referring to the "assumevalid" feature of Bitcoin Core that skips sign= ature 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 --Apple-Mail-501AAE1E-A8AE-4340-9F89-7F4F5A39EFC6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
You can't know (assume) a b= lock is valid unless you have previously validated the block yourself. But i= n the case where you have, and then intend to rely on it in a future sync, t= here is no need for witness data for blocks you are not going to validate. S= o you can just not request it. 

However you wi= ll not be able to provide those blocks to nodes that *are* validating; the c= lient is pruned and therefore not a peer (cannot reciprocate). (An SPV clien= t is similarly not a peer; it is a more deeply pruned client than the witnes= sless client.)

There is no other reason that a node= requires witness data. SPV clients don't need it as it is neither require i= t to verify header commitment to transactions nor to extract payment address= es from them.

The harm to the network by pruning is= that eventually it can become harder and even impossible for anyone to vali= date the chain. But because you are fully validating you individually remain= secure, so there is no individual incentive working against this system har= m.

e

On Dec 18, 2017, at 08:35, Kalle= Rosenbaum <kalle@rosenbaum.se&= gt; 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.linuxf= oundation.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 verific= ation 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 initi= al block
download also must download witness= es when it is going to skip verification of the witnesses anyway."

I'm referring to the "assumevalid" feature of Bitc= oin Core that skips signature verification up to block X. Or have I misunder= stood 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<= br> > 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<= br> > 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@li= sts.linuxfoundation.org
> https://lists.linuxfoundation.= org/mailman/listinfo/bitcoin-dev

= --Apple-Mail-501AAE1E-A8AE-4340-9F89-7F4F5A39EFC6--