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 0304011AA for ; Thu, 17 May 2018 15:46:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 52FEEA3 for ; Thu, 17 May 2018 15:46:22 +0000 (UTC) Received: from [IPv6:2607:fb90:7d6:4119:5206:c22a:4c4e:19e5] (unknown [172.56.34.52]) by mail.bluematt.me (Postfix) with ESMTPSA id EDA421A569F; Thu, 17 May 2018 15:46:20 +0000 (UTC) Date: Thu, 17 May 2018 15:46:18 +0000 In-Reply-To: <20180517154315.pcs6cmx3lx3on4dz@petertodd.org> References: <20180517154315.pcs6cmx3lx3on4dz@petertodd.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----LMBZD6S3EPYT4XDAMO6O7H54MYPNXC" Content-Transfer-Encoding: 7bit To: Peter Todd , Bitcoin Protocol Discussion From: Matt Corallo Message-ID: <4703B065-AFDA-4AB6-9523-859067CF50F7@mattcorallo.com> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE 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] 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 15:46:23 -0000 ------LMBZD6S3EPYT4XDAMO6O7H54MYPNXC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable (1) can be accomplished by filtering for the set of outputs in the transact= ion you created=2E I agree (2) would ideally be done to avoid issues with a= copied wallet (theft or not), but I am worried about the size of the filte= rs themselves, not just the size of the blocks downloaded after a match=2E On May 17, 2018 3:43:15 PM UTC, Peter Todd wrote: >On Thu, May 17, 2018 at 11:25:12AM -0400, Matt Corallo via bitcoin-dev >wrote: >> BIP 158 currently includes the following in the "basic" filter: 1) >> txids, 2) output scripts, 3) input prevouts=2E >>=20 >> I believe (1) could be skipped entirely - there is almost no reason >why >> you'd not be able to filter for, eg, the set of output scripts in a >> transaction you know about and (2) and (3) may want to be split out - >> many wallets may wish to just find transactions paying to them, as >> transactions spending from their outputs should generally be things >> they've created=2E > >So I think we have two cases where wallets want to find txs spending >from their >outputs: > >1) Waiting for a confirmation >2) Detecting theft > >The former can be turned off once there are no expected unconfirmed >transactions=2E > >As for the latter, this is probably a valuable thing for wallets to do=2E >Modulo >reorgs, reducing the frequency that you check for stolen funds doesn't >decrease >total bandwidth cost - it's one filter match per block regardless - but >perhaps >the real-world bandwidth cost can be reduced by, say, waiting for a >wifi >connection rather than using cellular data=2E > >--=20 >https://petertodd=2Eorg 'peter'[:-1]@petertodd=2Eorg ------LMBZD6S3EPYT4XDAMO6O7H54MYPNXC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable (1) can be accomplished by filtering for the set o= f outputs in the transaction you created=2E I agree (2) would ideally be do= ne to avoid issues with a copied wallet (theft or not), but I am worried ab= out the size of the filters themselves, not just the size of the blocks dow= nloaded after a match=2E

On May 17, 2018 = 3:43:15 PM UTC, Peter Todd <pete@petertodd=2Eorg> wrote:
On Thu, May 17, 2018 at 11:25:12AM -0400, Matt Coral=
lo via bitcoin-dev wrote:
 BIP 158 currently includes the following in the "basic" filter: 1)
 =
txids, 2) output scripts, 3) input prevouts=2E
 
 I believe (1) could=
 be skipped entirely - there is almost no reason why
 you'd not be able =
to filter for, eg, the set of output scripts in a
 transaction you know =
about and (2) and (3) may want to be split out -
 many wallets may wish =
to just find transactions paying to them, as
 transactions spending from=
 their outputs should generally be things
 they've created=2E

So I think we have two cases where wallets want to find txs spend=
ing from their
outputs:

1) Waiting for a confirmation
2) Detec=
ting theft

The former can be turned off once there are no expected u=
nconfirmed
transactions=2E

As for the latter, this is probably a =
valuable thing for wallets to do=2E Modulo
reorgs, reducing the frequenc=
y that you check for stolen funds doesn't decrease
total bandwidth cost =
- it's one filter match per block regardless - but perhaps
the real-worl=
d bandwidth cost can be reduced by, say, waiting for a wifi
connection r=
ather than using cellular data=2E
------LMBZD6S3EPYT4XDAMO6O7H54MYPNXC--