diff options
| author | Gregory Maxwell <greg@xiph.org> | 2018-06-09 15:45:54 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-06-09 15:45:58 +0000 |
| commit | 63e3f858124acb0e06a17db8f9699071828809ac (patch) | |
| tree | 940a67c419cc4a0a738fdeeae7207bd18addea75 | |
| parent | 71565178ba8d4c40b7ec26babb6df67d579f3973 (diff) | |
| download | pi-bitcoindev-63e3f858124acb0e06a17db8f9699071828809ac.tar.gz pi-bitcoindev-63e3f858124acb0e06a17db8f9699071828809ac.zip | |
Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size
| -rw-r--r-- | e5/7fc512b0a581174b8e8dcc7ecb9ef7c2f24baf | 176 |
1 files changed, 176 insertions, 0 deletions
diff --git a/e5/7fc512b0a581174b8e8dcc7ecb9ef7c2f24baf b/e5/7fc512b0a581174b8e8dcc7ecb9ef7c2f24baf new file mode 100644 index 000000000..3337fe47a --- /dev/null +++ b/e5/7fc512b0a581174b8e8dcc7ecb9ef7c2f24baf @@ -0,0 +1,176 @@ +Return-Path: <gmaxwell@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id B4F992119 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 9 Jun 2018 15:45:58 +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 9FC6A5D3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 9 Jun 2018 15:45:57 +0000 (UTC) +Received: by mail-ua0-f174.google.com with SMTP id e8-v6so10836885uam.13 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 09 Jun 2018 08:45:57 -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=N/kRs0fANBe+hj2+DHqaFjW6YIiAXE62wFgKsO+C7uY=; + b=ChiOCIJeA4/ONNNcSAH2DR3ZX70IPdYyjGjP8/0EjpOmRQb2fLsABa41BCSr1eO/JD + Gdta9bMA46oTPbyP1KguJUUVsYNSebysl/XxHvUBWhpGkKfIWo2Wc8GFbFaXNQ+VZloB + GHegCgljZ9LOWvNpGcVvS6b2GOAJ5wtnPvEa3mzdHu6ROIr4xVrds5C7ir9R39ihxadX + 42L2i3Yq9dlU2HMs1gli3sT6kWMkAeIYzBfhiZxNfbke3o03pHKdtAUQbtWoDGQ+OUM3 + HY2XBE2y1c2YO2k0VIRN5+QAQ+SdLaH/5n7Cc48xUnG09PTokP1TJFhrD/JmUPxUlPlm + 9TpQ== +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=N/kRs0fANBe+hj2+DHqaFjW6YIiAXE62wFgKsO+C7uY=; + b=ZpGjr9ka6DNqWMEXW+4y3GnZay2EQnrH8aCJbFasgHmYw08hw1dwixovLFCx0fe08i + qzx568YEXdFKJpzzgqPDA8KFVRZgSyuib3i6Wegmrin/KHK1sYQoshVxX0L2FZs3npdF + AkbajPLEK8Zt5+wBs4+maaCPx7giPK9rUoxIx/LPnJ1RbiEHvNWC6wfSbQWgnBvV0tp9 + EuvReEE5Rj4VNQA741TIsG7lPTCC4BjNa44aOXjDgRZdIorYbwvxZnfXhthbNIZta+2q + X/dgfgDQDFwlW1uS4i2Fm/5GQZEQ77QpIzlsrzLu3K2RfjkvT+tuIBOqxIlJWLCcppxN + I+wg== +X-Gm-Message-State: APt69E3zkeelviSJd3nhIlL86HcrW4bFf2BgHwhdOG7RfqN9Di9yt0GG + 1FiKqGl/dIvc3ZYpnZQsw2VX9zyPQ+O3YAbCCoU= +X-Google-Smtp-Source: ADUXVKKTjbfGzzfD6/4vaIwwk4lbo9Hre1gs+I6hQWs07zW2Q5js/q5jmtN1iZOSHey55Aht4EQWCnmPcDuIq5w2bPc= +X-Received: by 2002:a9f:2048:: with SMTP id 66-v6mr6728429uam.76.1528559156670; + Sat, 09 Jun 2018 08:45:56 -0700 (PDT) +MIME-Version: 1.0 +Sender: gmaxwell@gmail.com +Received: by 2002:a67:5193:0:0:0:0:0 with HTTP; + Sat, 9 Jun 2018 08:45:54 -0700 (PDT) +In-Reply-To: <CAO3Pvs89_196socS-mxZpciYNO172Fiif=ncSQF0DA9n1g0+fQ@mail.gmail.com> +References: <7E4FA664-BBAF-421F-8C37-D7CE3AA5310A@gmail.com> + <F87D7069-0FDC-4572-B02B-398A2A455935@gmail.com> + <CAAS2fgT716PiP0ucoASxryM9y+s9H2z06Z0ToaP1xT3BozAtNw@mail.gmail.com> + <CADZtCSguto2z6Z9CykymxnCokqo1G=sW0Ov0ht+KcD+KMnYyow@mail.gmail.com> + <CAO3Pvs-YDzfRqmyJ85wTH0ciccjCvkm5stGyP_tVGGna=PMv3A@mail.gmail.com> + <CAO3Pvs9p5COiS_7Jbj1r2iAKTEdXUcnVTRzL27c3=CeuB9WDTQ@mail.gmail.com> + <CAAS2fgSyVi0d_ixp-auRPPzPfFeffN=hsWhWT5=EzDO3O+Ue1g@mail.gmail.com> + <CAO3Pvs_0qCZbRCfL8EJw6gzWjZeXWcJrtg27g_SJ7+PkYTHg6A@mail.gmail.com> + <CAAS2fgTs+aKyiL8Kg_AZk=Mdh6896MEg=KHa6ANAZO7unsGEsg@mail.gmail.com> + <CADZtCShyYbgKk2zsKzQniqDw--XKfYWTk3Hk3o50V=MgT6zeuQ@mail.gmail.com> + <20180602124157.744x7j4u7dqtaa43@email> + <343A3542-3103-42E9-95B7-640DFE958FFA@gmail.com> + <CAAS2fgQDdJpzPR9Ve81hhyqU+MO7Ryy125fzK-iv=sfwwORDCw@mail.gmail.com> + <37BECD1A-7515-4081-85AC-871B9FB57772@gmail.com> + <CAPg+sBjXbwTKW+qbGwJgau-Q2-uJC6N1JH8hH4KThv0Ah3WuqA@mail.gmail.com> + <CAO3Pvs9BQ2Dc9GCuJNxko_34Jx5kSOd8jxYkfpMW2E_1EOBEuQ@mail.gmail.com> + <CAAS2fgRmvqJrtk5n7e9xc-zPpDLCKa2Te_dGCk9xb9OH_AG0nw@mail.gmail.com> + <CAO3Pvs89_196socS-mxZpciYNO172Fiif=ncSQF0DA9n1g0+fQ@mail.gmail.com> +From: Gregory Maxwell <greg@xiph.org> +Date: Sat, 9 Jun 2018 15:45:54 +0000 +X-Google-Sender-Auth: qUr2471NTbCMkv_8X9Uv3J_voGw +Message-ID: <CAAS2fgTtm0PaE=Z-eRNh_XVA-bvRAO09ijs-Twhf5ZQBNkux=g@mail.gmail.com> +To: Olaoluwa Osuntokun <laolu32@gmail.com> +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 <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sat, 09 Jun 2018 15:45:58 -0000 + +> So what's the cost in using +> the current filter (as it lets the client verify the filter if they want to, + +An example of that cost is you arguing against specifying and +supporting the design that is closer to one that would be softforked, +which increases the time until we can make these filters secure +because it slows convergence on the design of what would get +committed. + +>> I don't agree at all, and I can't see why you say so. +> +> Sure it doesn't _have_ to, but from my PoV as "adding more commitments" is +> on the top of every developers wish list for additions to Bitcoin, it would +> make sense to coordinate on an "ultimate" extensible commitment once, rather +> than special case a bunch of distinct commitments. I can see arguments for +> either really. + +We have an extensible commitment style via BIP141 already. I don't see +why this in particular demands a new one. + +> 1. The current filter format (even moving to prevouts) cannot be committed +> in this fashion as it indexes each of the coinbase output scripts. This +> creates a circular dependency: the commitment is modified by the +> filter, + +Great point, but it should probably exclude coinbase OP_RETURN output. +This would exclude the current BIP141 style commitment and likely any +other. + +Should I start a new thread on excluding all OP_RETURN outputs from +BIP-158 filters for all transactions? -- they can't be spent, so +including them just pollutes the filters. + +> 2. Since the coinbase transaction is the first in a block, it has the +> longest merkle proof path. As a result, it may be several hundred bytes +> (and grows with future capacity increases) to present a proof to the + +If 384 bytes is a concern, isn't 3840 bytes (the filter size +difference is in this ballpark) _much_ more of a concern? Path to the +coinbase transaction increases only logarithmically so further +capacity increases are unlikely to matter much, but the filter size +increases linearly and so it should be much more of a concern. + +> In regards to the second item above, what do you think of the old Tier Nolan +> proposal [1] to create a "constant" sized proof for future commitments by +> constraining the size of the block and placing the commitments within the +> last few transactions in the block? + +I think it's a fairly ugly hack. esp since it requires that mining +template code be able to stuff the block if they just don't know +enough actual transactions-- which means having a pool of spendable +outputs in order to mine, managing private keys, etc... it also +requires downstream software not tinker with the transaction count +(which I wish it didn't but as of today it does). A factor of two +difference in capacity-- if you constrain to get the smallest possible +proof-- is pretty stark, optimal txn selection with this cardinality +constraint would be pretty weird. etc. + +If the community considers tree depth for proofs like that to be such +a concern to take on technical debt for that structure, we should +probably be thinking about more drastic (incompatible) changes... but +I don't think it's actually that interesting. + +> I don't think its fair to compare those that wish to implement this proposal +> (and actually do the validation) to the legacy SPV software that to my +> knowledge is all but abandoned. The project I work on that seeks to deploy + +Yes, maybe it isn't. But then that just means we don't have good information. + +When a lot of people were choosing electrum over SPV wallets when +those SPV wallets weren't abandoned, sync time was frequently cited as +an actual reason. BIP158 makes that worse, not better. So while I'm +hopeful, I'm also somewhat sceptical. Certainly things that reduce +the size of the 158 filters make them seem more likely to be a success +to me. + +> too difficult to implement "full" validation, as they're bitcoin developers +> with quite a bit of experience. + +::shrugs:: Above you're also arguing against fetching down to the +coinbase transaction to save a couple hundred bytes a block, which +makes it impossible to validate a half dozen other things (including +as mentioned in the other threads depth fidelity of returned proofs). +There are a lot of reasons why things don't get implemented other than +experience! :) + |