Date: Thu, 17 May 2018 15:46:18 +0000
In-Reply-To: <20180517154315.pcs6cmx3lx3on4dz@petertodd.org>
References: <d43c6082-1b2c-c95b-5144-99ad0021ea6c@mattcorallo.com>
	<20180517154315.pcs6cmx3lx3on4dz@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----LMBZD6S3EPYT4XDAMO6O7H54MYPNXC"
Content-Transfer-Encoding: 7bit
To: Peter Todd <pete@petertodd.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <4703B065-AFDA-4AB6-9523-859067CF50F7@mattcorallo.com>
Subject: Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size
Precedence: list

------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 <pete@petertodd=2Eorg> 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

<html><head></head><body>(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<br><br><div class=3D"gmail_quote">On May 17, 2018 =
3:43:15 PM UTC, Peter Todd &lt;pete@petertodd=2Eorg&gt; wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; border-left: 1px=
 solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On Thu, May 17, 2018 at 11:25:12AM -0400, Matt Coral=
lo via bitcoin-dev wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #729fcf; padding-left: 1ex=
;"> BIP 158 currently includes the following in the "basic" filter: 1)<br> =
txids, 2) output scripts, 3) input prevouts=2E<br> <br> I believe (1) could=
 be skipped entirely - there is almost no reason why<br> you'd not be able =
to filter for, eg, the set of output scripts in a<br> transaction you know =
about and (2) and (3) may want to be split out -<br> many wallets may wish =
to just find transactions paying to them, as<br> transactions spending from=
 their outputs should generally be things<br> they've created=2E<br></block=
quote><br>So I think we have two cases where wallets want to find txs spend=
ing from their<br>outputs:<br><br>1) Waiting for a confirmation<br>2) Detec=
ting theft<br><br>The former can be turned off once there are no expected u=
nconfirmed<br>transactions=2E<br><br>As for the latter, this is probably a =
valuable thing for wallets to do=2E Modulo<br>reorgs, reducing the frequenc=
y that you check for stolen funds doesn't decrease<br>total bandwidth cost =
- it's one filter match per block regardless - but perhaps<br>the real-worl=
d bandwidth cost can be reduced by, say, waiting for a wifi<br>connection r=
ather than using cellular data=2E<br></pre></blockquote></div></body></html=
>
------LMBZD6S3EPYT4XDAMO6O7H54MYPNXC--