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 BCFAC127B for ; Sat, 2 Jun 2018 00:22:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f66.google.com (mail-vk0-f66.google.com [209.85.213.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5AFC9108 for ; Sat, 2 Jun 2018 00:22:27 +0000 (UTC) Received: by mail-vk0-f66.google.com with SMTP id q135-v6so14093308vkh.1 for ; Fri, 01 Jun 2018 17:22:27 -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=/XrVhyDtoRBfe0+JJLH9aod+BBRkTCpv2z97wOGWGZg=; b=SXD6hREToTLTZdg/lvCrw8FIf3i6osFqJPCTKv+vxW9sWCy3+YISm9jH8me+pbKWk1 AS6ByVJsOfxueNzfuJoRmhDjNWeY0PHvxlEi8oPR2QbI0JSQzPqeuTfKcB5n2rQRbCGo APFfXTv4YhN06JZ79N+04AxOa6HQQ6AgIh2dgJKRfpWsi3TRCudWYsacKnfnwxpOMHFx 3LOqdpTCz4wW6FMVgGWi6BdDc7UG/nMs5M7Jx7XY0PQcezly6sJIDcgY9KaB4sAATPJr HaJDVBPdUA592/wTd1IithRlckE2wwamMY0KAhBXo0sSLfdD4ejv7lRJqvxS62E/dPMR aBnA== 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=/XrVhyDtoRBfe0+JJLH9aod+BBRkTCpv2z97wOGWGZg=; b=pGfqXUAYHIskuDsgNzx5KXbH6vhdTOWNp4hdt69gKxlAxltuRhvNS/IZJt5LVc2Ben 6KXDRFJ/P3j04ynP2gbzyIeumXvx4YiT9kiV9VlksiUG2ubeACBs635bQNr8N1Ac55yf 86tWSwOJwLKkv3MvA3FLVy9WQ90mEAW8SLYiReDahzKE2PYlXmPbSAKO+25vEAxvWKyM HwxJBumcqxNhqkfeV4QPPbYp1E9JtfB9Y8FQdmJxNi9NqrEM0wG6aVZzh6BSKXMc4XdT noIpceHyAJyA6Od3LrHb3aQRenIysLpSSeJ1VnGuht5XkgoIVHb3Bkxg/MMFkkppdn5T 3InA== X-Gm-Message-State: ALKqPwdwf9ykhreKEaHj+6IUcX1iI4Ayuvi2L8hSERCcWyD0gGhpeDR2 nls1jnsgzYIQGoBch1tMI/Y7EnwFKuv7UsTE+No= X-Google-Smtp-Source: ADUXVKK9fN0cotALi9nlXzQ5c99vqfEziKacE5dffu3miNdMYWLcsQztHuXIkakOTTn4s5VXeP5bm79yJXrDEiBaAq8= X-Received: by 2002:a1f:9c6:: with SMTP id 189-v6mr8537657vkj.74.1527898946521; Fri, 01 Jun 2018 17:22:26 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 2002:a67:5193:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 17:22:25 -0700 (PDT) In-Reply-To: References: <22d375c7-a032-8691-98dc-0e6ee87a4b08@mattcorallo.com> <7E4FA664-BBAF-421F-8C37-D7CE3AA5310A@gmail.com> From: Gregory Maxwell Date: Sat, 2 Jun 2018 00:22:25 +0000 X-Google-Sender-Auth: aYGUFLsn7dXCRUM6a54M0gy0-DY Message-ID: To: Olaoluwa Osuntokun 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: Sat, 02 Jun 2018 00:22:27 -0000 On Sat, Jun 2, 2018 at 12:01 AM, Olaoluwa Osuntokun wrote: >> A typical network attacker (e.g. someone on your lan or wifi segmet, or >> someone who has compromised or operates an upstream router) can be all of >> your peers. > > This is true, but it cannot make us accept any invalid filters unless the > attacker is also creating invalid blocks w/ valid PoW. I wish that were the true, but absent commitments that wouldn't be the case unless you were always downloading all the blocks-- since you wouldn't have any sign that there was something wrong with the filter-- and downloading all the blocks would moot using the filters in the first place. :) Or have I misunderstood you massively here? For segwit originally I had proposed adding additional commitments that would make it possible to efficiently prove invalidity of a block; but that got stripped because many people were of the view that the "assume you have at least one honest peer who saw that block and rejected it to tell you that the block was invalid" security assumption was of dubious value. Maybe it's more justifiable to make use of a dubious assumption for a P2P feature than for a consensus feature? Perhaps, I'd rather have both filter types from day one so that things not implementing the comparison techniques don't get the efficiency loss or the extra work to change filter types for a consensus one. [I think now that we're much closer to a design that would be worth making a consensus committed version of than we were a few months ago now, since we are effectively already on a second generation of the design with the various improvements lately]