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 55D59483 for ; Thu, 17 May 2018 18:34:48 +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 C23716D0 for ; Thu, 17 May 2018 18:34:47 +0000 (UTC) Received: by mail-ua0-f174.google.com with SMTP id g9-v6so3648105uak.7 for ; Thu, 17 May 2018 11:34:47 -0700 (PDT) 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:cc; bh=WkRERrfrM+p9UFIeLWhfLH5bRHn/aoxSsjfaAgXBslA=; b=VCLrob63HY4dXjoQoh5/0P8zJkuBcFuDIvGB73Hxt5Z41iG3k736BowF+C34Z62vfh R1xJN2zv3m80GHJ7rkqx+8Vmx9M7XjLVbF8my6JcpOsQX0KO42sWGFtbQJdgaY13fZos 4UDfVQkhEdBeEq9g6BhsBSzNwDxoS/jKNi0tYL+w5ifWODMw7ce6+I/pMw5fyRvcjzqg nJEnqo/mDgDERozePcskNxtUdqxLYvtJY/IefJunwOPK/5HAMpPCbguXamK2EXjKFEk3 R4aodhgKVmjcVkU+AiUQPKCihOonOMtWudUPZXc3rdpsg/D0svzGayJlsBU/BbFfJ3Fd 3lqQ== 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:cc; bh=WkRERrfrM+p9UFIeLWhfLH5bRHn/aoxSsjfaAgXBslA=; b=a1atulJ/V0Hov073hR00LLBPzV5wiHrXHl4Sy3UQ5znaWk6NWabZkaOboZ8BdW12bb Nk5lxo/2zIsBgh8B/PjaHbPU3/+pxk8tuVm5sDAPfxxqsZtB8V4HRltCEo0yB5i9hH8b swLHNFajBKaNK22GSZ7gkzfzGjw7E/Ok2W8+YDS6HpJakYDktBQiqqMwZAOTSLMn+PfX jX2vsX23qoCmSljGGVjqADHbMAclLopiycjwQ5IHTMLNL1bSwg07T5ZPMnuYNx6ufyGw Rmg1IXjmSSdNHBeSkonnxKR2T2haArl6yo1tLCyU8OVC2oqBkxfMCUtfPXzQteJ0ChC6 uTJA== X-Gm-Message-State: ALKqPwcq9FIwARUPAVIIjySEshtKjECssdcOZsix12RUtTsKxjmkuLj7 UwcmpXaoNgTUcFkhSMZa6EIihGiLr6qqMVtBSAM= X-Google-Smtp-Source: AB8JxZojI0+OaYAbCkW6XpydL9JL/8g1NfrKZ0rKx/ftic1zTrXxBKWY9iUEAvXKlbpf6d2vpcIyVrv92rZvMO3QRuk= X-Received: by 2002:ab0:1092:: with SMTP id d18-v6mr5150705uab.87.1526582086905; Thu, 17 May 2018 11:34:46 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.81.132 with HTTP; Thu, 17 May 2018 11:34:45 -0700 (PDT) In-Reply-To: <22d375c7-a032-8691-98dc-0e6ee87a4b08@mattcorallo.com> References: <22d375c7-a032-8691-98dc-0e6ee87a4b08@mattcorallo.com> From: Gregory Maxwell Date: Thu, 17 May 2018 18:34:45 +0000 X-Google-Sender-Auth: pKkCF3uwd3M8SrYeFYhbooAem-0 Message-ID: To: Matt Corallo 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 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size 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: Thu, 17 May 2018 18:34:48 -0000 On Thu, May 17, 2018 at 4:59 PM, Matt Corallo wrote: > Yea I generally would really prefer something like that but it > significantly complicates the download logic - currently clients can > easily cross-check [...] Maybe > there is some other reasonable download logic to replace it with, however. I think lite clients cross checking is something which very likely will never be implemented by anyone, and probably not stay working (due to under-usage) if it is implemented. This thought is driven by three things (1) the bandwidth overhead of performing the check, (2) thinking about the network-interacting-state-machine complexity of it, and by the multitude of sanity checks that lite clients already don't implement (e.g. when a lite client noticed a split tip it could ask peers for the respective blocks and check at least the stateless checks, but none has ever done that), and... (3) that kind of checking would be moot if the filters were committed and validated... and the commitment would be both much simpler to check for lite clients and provide much stronger protection against malicious peers. My expectation is that eventually one of these filter-map designs would become committed-- not after we already had it deployed and had worked out the design to the n-th generation (just as your proposed revisions are doing to the initial proposal), but eventually. Also, even without this change clients can still do that "are multiple peers telling me the same thing or different things" kind of checking, which I expect is the strongest testing we'd actually see them implement absent a commitment.