Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A25311BD7 for ; Tue, 5 Jun 2018 01:08:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 10E39136 for ; Tue, 5 Jun 2018 01:08:14 +0000 (UTC) Received: by mail-qk0-f172.google.com with SMTP id g14-v6so461449qkm.6 for ; Mon, 04 Jun 2018 18:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2MG9oTgFfR9kNIwYzj/ZpGdzEO3OgttM+y0i1O4W0rw=; b=aADd1088R8D/GyAGAwEG0X+4pnSwxsWKXHhe1x3Irnwpa/tiaRFSqXKjecDq4tYlAs sX88MwYBUBIIV9I9Uf0qTwBA0wA8ahuHPuN3Hmh3w364l11CBS4Eaw85zRuO1mFyehTL 5mJ733W+VjpYU0ig4uHKy5hpcWvJ4j/AwpfzixN0i2pPQlqv5ucJlV2Vg5NuINNDdYJG tai9PNVTO1oLBUvdKqtTqrL3kv/LXGcXP+JwkDvSbXugAf7CXLVkBC2mTkDA3bvjEhjq Ph2RiwoKklFyD4niPJ+n42v0aB/q5zYZgEa2/BxRAzuVNznPyZT+grMvSPEOGlTnqfIz TJyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2MG9oTgFfR9kNIwYzj/ZpGdzEO3OgttM+y0i1O4W0rw=; b=YDOsNreS9CNZvmHuCd2bCWWC23Qz86VEQy3x9at2WnQAfWt9o0PgtrZC21nNYLMDie uq7LbaHyiQaayzi0d2RJReMn870aQlZgnCoZDfAFjzpgxjotSlnGjBvHuFt/DI2ylrK6 zJsGiK9ad+0znnfdJZvy4QTHh2kcZFMvOME0ZYCkqVRz/ouhxy4+ttWRiYG/nAWIE2cB peHIMJBKbP2YfsQ27nFp4Nl8lkxlLYIHZM+ojl5LKsZmRzPGca8g0Yxcr9U634Droulu IOdptnYC6fYb3ZNVQsbsDoMpFFIZw6TjPLYNLWAdZrcqegGdbX8UUbeZ8cYORFP1jtwW rslw== X-Gm-Message-State: APt69E29Rd4a+6ZiqkswXqXZrbprIih+Pxmxv9U0yX5lqgkcnq/Mt8Ad ZdOjLTigG7eCDclgdD5em+ykGrpV315vhCACa08= X-Google-Smtp-Source: ADUXVKKtWpnCxba0MGqshcQzAprSijyHD8nRiBGQo0Dti8qLKDIcgeRoTSS4Fz/O0dtTcjTSZnKSSe1Q6krGT/FNqek= X-Received: by 2002:a37:a80d:: with SMTP id r13-v6mr12087466qke.41.1528160893985; Mon, 04 Jun 2018 18:08:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jim Posen Date: Mon, 4 Jun 2018 18:08:01 -0700 Message-ID: To: Riccardo Casatta , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000003ee8c5056ddaaf0c" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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: Tue, 05 Jun 2018 01:13:42 +0000 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: Tue, 05 Jun 2018 01:08:15 -0000 --0000000000003ee8c5056ddaaf0c Content-Type: text/plain; charset="UTF-8" > > I was wondering why this multi-layer multi-block filter proposal isn't > getting any comment, > is it because not asking all filters is leaking information? > It's an interesting idea, but it adds more complexity to the client and could be added later on if clients adopt BIP 157 and complain about bandwidth. It also derives all bandwidth gains from address reuse. So I'm hesitant to make the complexity tradeoff for bandwidth savings due to a behavior that is actively discouraged. On another note, I've been thinking that block TXO commitments could resolve the issue we are facing now with deciding between the prev script approach and outpoint. The whole argument for outpoints is that there are compact-ish (<1 MiB) proofs of filter validity, which is not currently possible if the filters included prev output data. Such proofs would be feasible if blocks headers (well, actually coinbase txs) had a commitment to the Merkle root of all newly created outputs in the block. This idea has been tossed around before in the context of fraud proofs and TXO bitfields, and seems to unlock a whole bunch of other P2P commitments. For example, if we wanted to do P2P commitments (BIP 157-style) to the distribution of tx fees in a block, one could use block TXO commitments to prove correctness of fees for non-segwit txs. It also enables block validity proofs (assuming parent blocks are valid), which are not as powerful as invalidity/fraud proofs, but interesting nonetheless. This would require a new getdata type BLOCK_WITH_PREVOUTS or something. I assume for most coinbase-tx-committed proposals, we'll also need a new getcoinbases/coinbases that requests the coinbase tx and Merkle branch for a range of headers as well. But with these additions, we could start serving more block-derived data to light clients under the BIP 157 at-least-one-honest-peer assumption. --0000000000003ee8c5056ddaaf0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=
I was wondering why this mu= lti-layer multi-block filter proposal isn't getting any comment,
<= div style=3D"font-size:small">is it because not asking all filters is leaki= ng information?

It's an interesting idea, but it adds more complexity to the client= and could be added later on if clients adopt BIP 157 and complain about ba= ndwidth. It also derives all bandwidth gains from address reuse. So I'm= hesitant to make the complexity tradeoff for bandwidth savings due to a be= havior that is actively discouraged.
On another note, I've been think= ing that block TXO commitments could resolve the issue we are facing now wi= th deciding between the prev script approach and outpoint. The whole argume= nt for outpoints is that there are compact-ish (<1 MiB) proofs of filter= validity, which is not currently possible if the filters included prev out= put data. Such proofs would be feasible if blocks headers (well, actually c= oinbase txs) had a commitment to the Merkle root of all newly created outpu= ts in the block.

= This idea has been tossed around before in the context o= f fraud proofs and TXO bitfields, and seems to unlock a whole bunch of othe= r P2P commitments. For example, if we wanted to do P2P commitments (BIP 157= -style) to the distribution of tx fees in a block, one could use block TXO = commitments to prove correctness of fees for non-segwit txs. It also enable= s block validity proofs (assuming parent blocks are valid), which are not a= s powerful as invalidity/fraud proofs, but interesting nonetheless.<= /div>

This = would require a new getdata type BLOCK_WITH_PREVOUTS or something. I assume= for most coinbase-tx-committed proposals, we'll also need a new getcoi= nbases/coinbases that requests the coinbase tx and Merkle branch for a rang= e of headers as well. But with these additions, we could start serving more= block-derived data to light clients under the BIP 157 at-least-one-honest-= peer assumption.
--0000000000003ee8c5056ddaaf0c--