Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EA7A197A for ; Mon, 18 Dec 2017 20:42:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f174.google.com (mail-ua0-f174.google.com [209.85.217.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8841F403 for ; Mon, 18 Dec 2017 20:42:35 +0000 (UTC) Received: by mail-ua0-f174.google.com with SMTP id i20so11554374uak.6 for ; Mon, 18 Dec 2017 12:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=hGXPEzqjkKy+rONmdiOcrxq9kvRIpbPB6TtZCj8uCfk=; b=WGrOuuKncFRU0HUWklVR45yeTy5q/+0YplCXzglcLpXbMmW39mOJImCsHne5YQlEkD Js723JyAQkhQZFCpApPiCbFmON5+R2NLSRVvP7lGUXfhzj0A4n9VDN/G4wWTMjCn9ji0 LE64bzRTFRsGjJRFeaH3ia/0eIGzzUcRD5g4NUaHcQ7qKwjzg4DPpfDsltS3q4HOPbru AkJbkkMmpU+lYD5C0VcgKGwaIymKIPPtvcT+c1wdsioNuZTNBBc37wslmeQOlHB+CN5i 9USNrtaAdsshT2yVIfzBQUGnIeeK2PMD5+WeBYGij6KUaGqpsXnS2QWgTfRh/i2zUQaV x0CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=hGXPEzqjkKy+rONmdiOcrxq9kvRIpbPB6TtZCj8uCfk=; b=o6C2T4lapbT6defIya/FJKz/5R0075ZyIK1may8h0WplrOO/YaMCCc8wNCIuqdBHT6 lX9NjJvUlbOth0Hcv66f0dHJnuymSRjS3bISUk81D7DystCarcmw5H18cKv3kZGAfDm+ MyVJ+mE8k/WzGZA6ZUDdqkVN8UQGqsJRPJD4xZADYSVVcNB8aTn8Neq3NELhGH7Szb0L ZHdns92fIArVSRiWYVbLHKQ0EVsfQDUdKtHz5dq3Qs2byIY0xOY0tjqb3X6H7ciFZJ5N N1Gi3tGgATsgEv9aJu12mHNT2VnrAgZ4szHdtq8ZR/HuD8l2nJSvf50mLcHmrsMUfpJz olJg== X-Gm-Message-State: AKGB3mJ3OjLazRZ3BPsZlJFFkbkI/yaEW6Bb8P8xBUThlmoWchZK8aSu nExIFNBksk38fQ4in2ohqDnzqYgxXkjf4oh9gXQ= X-Google-Smtp-Source: ACJfBovB2+fNhpJqWqIkF/ByxS/5Tn3mJJaAuJpdTBHrImQQlyFOxb8DnuoQgcFdTawP2zIIGJXSgugjys7fGJ2DVi4= X-Received: by 10.176.7.202 with SMTP id d10mr1085865uaf.21.1513629754702; Mon, 18 Dec 2017 12:42:34 -0800 (PST) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.85.148 with HTTP; Mon, 18 Dec 2017 12:42:34 -0800 (PST) In-Reply-To: References: From: Gregory Maxwell Date: Mon, 18 Dec 2017 20:42:34 +0000 X-Google-Sender-Auth: c1tZBKzOYVFRQ4GC7dOVbrXHdjY Message-ID: To: Kalle Rosenbaum , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, 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 20:42:36 -0000 Because it would make no meaningful difference now, and if you are not going to check the history there are much more efficient things to do-- like not transfer it at all. On Mon, Dec 18, 2017 at 8:32 AM, 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. 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 >