Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ADED3BD1 for ; Mon, 18 Dec 2017 12:44:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com [209.85.216.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1EA01403 for ; Mon, 18 Dec 2017 12:44:02 +0000 (UTC) Received: by mail-qt0-f180.google.com with SMTP id w10so19723905qtb.10 for ; Mon, 18 Dec 2017 04:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=2D9vXo/ZQOJb/u9GzPXtdrFDIqyv/6c8E2MOf6m0uuk=; b=xIJCrxhQpPMzhqdWa0fi6nuoFpyOkqd67HcH+Ck210RGXAsGA3cowkmibrp3s/Xlax pDzxMCzwIHzzm3cSgP/SAW2DFUIVYUj28TDD1cFaHLPCoKAKOWMD2QRoTJ7UTIKoVVlg NwqnkTSpWYETDgtH4Xz1tQ98+y11MTVOoI7mkV3YyOmU6jj6GB/mxFjL7Vbv9VQDiQbb psvrEAVJKBWZ81SacHzSomiOhWGgEDl+Dc+bVzcIBNQqJrMM82ojv0kfgQ5l4Cd+6qwU TKNe5Av5KnEpyvOE88AW53RuPTid1rUZsxAamWDdArPd/BN/+1Nh+obB6lcZl6vdFCbR IC4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=2D9vXo/ZQOJb/u9GzPXtdrFDIqyv/6c8E2MOf6m0uuk=; b=b+gcX5wy4s5471s1DSHlHuxmvdb0qVmDlTR76HIaLyp0XxmQzAMucgkKNGj7dDuier D/y7yFVQcNGeVpzlrLvenPGRUXyaBDfiM0xJWLvUxhf2EkoMyEeB0A8CWAP/Er6rD+F7 BNA+82Eg3HJQFAPy8YHO7aY9WmyzkZ/klbvLJL9A6uWXEoSqpOHa/Xi1m/WuAa9ZB6Nx ztbWSHLfZmyYcAadC65kNDxr4fsD4Me8IkoOTMamJ8oQCKbZILetR28jPnDWOPxAaPt6 Xd8TJ9PARF0Lyy/O02gULUo5t694/8hkLRNYaxZ+Ixb8x6EnMuyPq8dsgFnTcV6FkFTO kQFA== X-Gm-Message-State: AKGB3mLKvGAB1sQYgKQjqz7VbMTKZyEkW4hM8PGdUQdOvRJQjsxwt7HZ 8K+YjVrjuMOmY82NcUAQLlt3tJleEmU= X-Google-Smtp-Source: ACJfBossqdCouoyN3oPEWyDvTrW9iEtyViLmkwC8VRS0dDBESJrjKVA3hYy2Wu2drJ8LMozrPYs4OA== X-Received: by 10.237.56.5 with SMTP id j5mr36290551qte.53.1513601041167; Mon, 18 Dec 2017 04:44:01 -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 c16sm8012130qtd.80.2017.12.18.04.43.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 04:44:00 -0800 (PST) From: Eric Voskuil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Mon, 18 Dec 2017 07:43:58 -0500 Message-Id: References: In-Reply-To: To: Kalle Rosenbaum , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (14G60) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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 13:58:11 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 12:44:02 -0000 > On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev wrote: >=20 > Dear list, >=20 > 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 verificati= on anyway. Why run a full node if you are not going to verify the chain? > If my full node skips signature verification for > blocks earlier than X, it seems the reasons for downloading the > witnesses for those blocks are: >=20 > * to be able to send witnesses to other nodes. >=20 > * to verify the witness root hash of the blocks >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Do witnessless nodes risk dividing the network in two parts, one > witnessless and one with full nodes, with few connections between the > parts? >=20 > So basically, what are the reasons not to implement witnessless > nodes? >=20 > Thank you, > /Kalle > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev