MIME-Version: 1.0
References: <d43c6082-1b2c-c95b-5144-99ad0021ea6c@mattcorallo.com>
	<CAAS2fgRF-MhOvpFY6c_qAPzNMo3GQ28RExdSbOV6Q6Oy2iWn1A@mail.gmail.com>
	<22d375c7-a032-8691-98dc-0e6ee87a4b08@mattcorallo.com>
	<CAAS2fgR3QRHeHEjjOS1ckEkL-h7=Na56G12hYW9Bmy9WEMduvg@mail.gmail.com>
	<CADZtCShLmH_k-UssNWahUNHgHvWQQ1y638LwaOfnJEipwjbiYg@mail.gmail.com>
	<CAAS2fgQLCN_cuZ-3QPjCLfYOtHfEk=SenTn5=y9LfGzJxLPR3Q@mail.gmail.com>
	<CADZtCSjYr6VMBVQ=rx44SgRWcFSXhVXUZJB=rHMh4X78Z2eY1A@mail.gmail.com>
	<CAO3Pvs9K3n=OzVQ06XGQvzNC+Aqp9S60kWM9VRPA8hWTJ3u9BQ@mail.gmail.com>
	<c23a5346-9f99-44f0-abbf-d7e7979bf1d8@gmail.com>
	<CAO3Pvs_MA4TtgCCu1NgCBjK2bZRN+rKnGQJN6m4yTrViBXRiPA@mail.gmail.com>
	<CAD3i26BibcaMdbQv-j+Egz_1y0GuhzepBp5ATNpj=Qv8hi1TVA@mail.gmail.com>
	<CADZtCShAYpbN=4qNoX5c8yd1j08+mEZzG8gZwcHrj2suY0mb9w@mail.gmail.com>
	<CADZtCShYnM3A949H18V2+BArA-K9J+cDkd=rX8xRn0+0js5CwA@mail.gmail.com>
	<CAAS2fgTXS5Tains7dfe_Rc9JxR6M=NuFW9UtieRELm+6N2uNog@mail.gmail.com>
	<CAFfwr8F+ghYb2HYEgC7Lh7Z-ytNE7EABr6cxiVXYhWLk-TPO7A@mail.gmail.com>
	<CADZtCShDzPK_jqeOrK4XBoB2uriU9c9T8Dm7By-8ew3XOoAeQg@mail.gmail.com>
	<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>
In-Reply-To: <CAAS2fgSyVi0d_ixp-auRPPzPfFeffN=hsWhWT5=EzDO3O+Ue1g@mail.gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Fri, 1 Jun 2018 17:01:43 -0700
Message-ID: <CAO3Pvs_0qCZbRCfL8EJw6gzWjZeXWcJrtg27g_SJ7+PkYTHg6A@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000008b8043056d9d68cc"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size
Precedence: list

--0000000000008b8043056d9d68cc
Content-Type: text/plain; charset="UTF-8"

> 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.

> The original propsal for using these kinds of maps was that their digests
> could eventually be commited and then checked against the commitment,
> matching the same general security model used otherwise in SPV.

Indeed, but no such proposal for committing the filters has emerged yet.
Slinging filters with new p2p messages requires much less coordination that
adding a new committed structure to Bitcoin. One could imagine that if
consensus exists to add new committed structures, then there may also be
initiatives to start to commit sig-ops, block weight, utxo's etc. As a
result one could imagine a much longer deployment cycle compared to a pure
p2p roll out in the near term, and many applications are looking for a
viable alternative to BIP 37.

> Unfortunately, using the scripts instead of the outpoints takes us further
> away from a design that is optimized for committing (or, for that matter,
> use purely locally by a wallet)...

I agree that using the prev input scripts would indeed be optimal from a
size perspective when the filters are to be committed. The current proposal
makes way for future filter types and it's likely the case that only the
most optimal filters should be committed (while other more niche filters
perhaps, remain only on the p2p level).

-- Laolu


On Thu, May 31, 2018 at 9:14 PM Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Fri, Jun 1, 2018 at 2:52 AM, Olaoluwa Osuntokun via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > One notable thing that I left off is the proposed change to use the
> previous
> > output script rather than the outpoint. Modifying the filters in this
> > fashion would be a downgrade in the security model for light clients, as
> it
>
> Only if you make a very strong assumption about the integrity of the
> nodes the client is talkign to. 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.
>
> The original propsal for using these kinds of maps was that their
> digests could eventually be commited and then checked against the
> commitment, matching the same general security model used otherwise in
> SPV.
>
> Unfortunately, using the scripts instead of the outpoints takes us
> further away from a design that is optimized for committing (or, for
> that matter, use purely locally by a wallet)...
>

--0000000000008b8043056d9d68cc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt; A typical network attacker (e.g.=C2=A0 someone o=
n your lan or wifi segmet, or</div><div>&gt; someone who has compromised or=
 operates an upstream router) can be all of</div><div>&gt; your peers.</div=
><div><br></div><div>This is true, but it cannot make us accept any invalid=
 filters unless the</div><div>attacker is also creating invalid blocks w/ v=
alid PoW.</div><div><br></div><div>&gt; The original propsal for using thes=
e kinds of maps was that their digests</div><div>&gt; could eventually be c=
ommited and then checked against the commitment,</div><div>&gt; matching th=
e same general security model used otherwise in SPV.</div><div><br></div><d=
iv>Indeed, but no such proposal for committing the filters has emerged yet.=
</div><div>Slinging filters with new p2p messages requires much less coordi=
nation that</div><div>adding a new committed structure to Bitcoin. One coul=
d imagine that if</div><div>consensus exists to add new committed structure=
s, then there may also be</div><div>initiatives to start to commit sig-ops,=
 block weight, utxo&#39;s etc. As a</div><div>result one could imagine a mu=
ch longer deployment cycle compared to a pure</div><div>p2p roll out in the=
 near term, and many applications are looking for a</div><div>viable altern=
ative to BIP 37.</div><div><br></div><div>&gt; Unfortunately, using the scr=
ipts instead of the outpoints takes us further</div><div>&gt; away from a d=
esign that is optimized for committing (or, for that matter,</div><div>&gt;=
 use purely locally by a wallet)...</div><div><br></div><div>I agree that u=
sing the prev input scripts would indeed be optimal from a</div><div>size p=
erspective when the filters are to be committed. The current proposal</div>=
<div>makes way for future filter types and it&#39;s likely the case that on=
ly the</div><div>most optimal filters should be committed (while other more=
 niche filters</div><div>perhaps, remain only on the p2p level).</div><div>=
<br></div><div>-- Laolu</div><div><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr">On Thu, May 31, 2018 at 9:14 PM Gregory Maxwell &lt;<a hre=
f=3D"mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Fri, Jun 1, 2018 at 2:52 AM, Olaoluwa Osu=
ntokun via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; One notable thing that I left off is the proposed change to use the pr=
evious<br>
&gt; output script rather than the outpoint. Modifying the filters in this<=
br>
&gt; fashion would be a downgrade in the security model for light clients, =
as it<br>
<br>
Only if you make a very strong assumption about the integrity of the<br>
nodes the client is talkign to. A typical network attacker (e.g.<br>
someone on your lan or wifi segmet, or someone who has compromised or<br>
operates an upstream router) can be all of your peers.<br>
<br>
The original propsal for using these kinds of maps was that their<br>
digests could eventually be commited and then checked against the<br>
commitment, matching the same general security model used otherwise in<br>
SPV.<br>
<br>
Unfortunately, using the scripts instead of the outpoints takes us<br>
further away from a design that is optimized for committing (or, for<br>
that matter, use purely locally by a wallet)...<br>
</blockquote></div></div>

--0000000000008b8043056d9d68cc--