MIME-Version: 1.0
References: <6D57649F-0236-4FBA-8376-4815F5F39E8A@gmail.com>
	<CADZtCSgKu1LvjePNPT=0C0UYQvb47Ca0YN+B_AfgVNTpcOno4w@mail.gmail.com>
	<CDAFC2F7-A0AD-460B-B5B1-A717F7EC700E@gmail.com>
	<CAO3Pvs_gvYy99Bch=7RwVszM_0PFTKUyqDVok=xfm4OOcqwaaQ@mail.gmail.com>
	<97c96822-df5e-0c65-3992-6e292577ce66@mattcorallo.com>
In-Reply-To: <97c96822-df5e-0c65-3992-6e292577ce66@mattcorallo.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Tue, 5 Feb 2019 16:05:57 -0800
Message-ID: <CAO3Pvs8wKgxo_z73FNy6Dgo_Z68Pa13CU7xHzUbpNATraqACpA@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary="00000000000053729505812e7e3d"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Jim Posen <jimpo@coinbase.com>
Subject: Re: [bitcoin-dev] Interrogating a BIP157 server,
	BIP158 change proposal
Precedence: list

--00000000000053729505812e7e3d
Content-Type: text/plain; charset="UTF-8"

Hi Matt,

> In (the realistic) thread model where an attacker is trying to blind you
> from some output, they can simply give you "undo data" where scriptPubKeys
> are OP_TRUE instead of the real script and you'd be none the wiser.

It depends on the input. If I'm trying to verify an input that's P2WSH,
since the witness script is included in the witness (the last element), I
can easily verify that the pkScript given is the proper witness program.

> Huh? I don't think we should seriously consider
> only-one-codebase-has-deployed-anything-with-very-limited-in-the-wild-use
as
> "too late into the current deployment"?

I'd wager that most developers reading this email right now are familiar
with neutrino as a project. Many even routinely use "neutrino" to refer to
BIP 157+158. There are several projects in the wild that have already
deployed applications built on lnd+neutrino live on mainnet. lnd+neutrino is
also the only project (as far as I'm aware) that has fully integrated the
p2p BIP 157+158 into a wallet, and also uses the filters for higher level
applications.

I'm no stranger to this argument, as I made the exact same one 7 months ago
when the change was originally discussed. Since then I realized that using
input scripts can be even _more_ flexible as light clients can use them as
set up or triggers for multi-party protocols such as atomic swaps. Using
scripts also allows for faster rescans if one knows all their keys ahead of
time, as the checks can be parallelized. Additionally, the current filter
also lends better to an eventual commitment as you literally can't remove
anything from it, and still have it be useful for the traditional wallet use
case.

As I mentioned in my last email, this can be added as an additional filter
type, leaving it up the full node implementations that have deployed the
base protocol to integrate it or not.

-- Laolu


On Tue, Feb 5, 2019 at 4:21 AM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

>
> On 2/4/19 8:18 PM, Jim Posen via bitcoin-dev wrote:
> - snip -
>  > 1) Introduce a new P2P message to retrieve all prev-outputs for a given
>  > block (essentially the undo data in Core), and verify the scripts
>  > against the block by executing them. While this permits some forms of
>  > input script malleability (and thus cannot discriminate between all
>  > valid and invalid filters), it restricts what an attacker can do. This
>  > was proposed by Laolu AFAIK, and I believe this is how btcd is
> proceeding.
>
> I'm somewhat confused by this - how does the undo data help you without
> seeing the full (mistate compressed) transaction? In (the realistic)
> thread model where an attacker is trying to blind you from some output,
> they can simply give you "undo data" where scriptPubKeys are OP_TRUE
> instead of the real script and you'd be none the wiser.
>
> On 2/5/19 1:42 AM, Olaoluwa Osuntokun via bitcoin-dev wrote:
> - snip -
> > I think it's too late into the current deployment of the BIPs to change
> > things around yet again. Instead, the BIP already has measures in place
> for
> > adding _new_ filter types in the future. This along with a few other
> filter
> > types may be worthwhile additions as new filter types.
> - snip -
>
> Huh? I don't think we should seriously consider
> only-one-codebase-has-deployed-anything-with-very-limited-in-the-wild-use
> as "too late into the current deployment"?
>
> Matt
>

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

<div dir=3D"ltr"><div>Hi Matt,</div><div><br></div><div>&gt; In (the realis=
tic) thread model where an attacker is trying to blind you</div><div>&gt; f=
rom some output, they can simply give you &quot;undo data&quot; where scrip=
tPubKeys</div><div>&gt; are OP_TRUE instead of the real script and you&#39;=
d be none the wiser.</div><div><br></div><div>It depends on the input. If I=
&#39;m trying to verify an input that&#39;s P2WSH,</div><div>since the witn=
ess script is included in the witness (the last element), I</div><div>can e=
asily verify that the pkScript given is the proper witness program.</div><d=
iv><br></div><div>&gt; Huh? I don&#39;t think we should seriously consider<=
/div><div>&gt; only-one-codebase-has-deployed-anything-with-very-limited-in=
-the-wild-use as</div><div>&gt; &quot;too late into the current deployment&=
quot;?</div><div><br></div><div>I&#39;d wager that most developers reading =
this email right now are familiar</div><div>with neutrino as a project. Man=
y even routinely use &quot;neutrino&quot; to refer to</div><div>BIP 157+158=
. There are several projects in the wild that have already</div><div>deploy=
ed applications built on lnd+neutrino live on mainnet. lnd+neutrino is</div=
><div>also the only project (as far as I&#39;m aware) that has fully integr=
ated the</div><div>p2p BIP 157+158 into a wallet, and also uses the filters=
 for higher level</div><div>applications.</div><div><br></div><div>I&#39;m =
no stranger to this argument, as I made the exact same one 7 months ago</di=
v><div>when the change was originally discussed. Since then I realized that=
 using</div><div>input scripts can be even _more_ flexible as light clients=
 can use them as</div><div>set up or triggers for multi-party protocols suc=
h as atomic swaps. Using</div><div>scripts also allows for faster rescans i=
f one knows all their keys ahead of</div><div>time, as the checks can be pa=
rallelized. Additionally, the current filter</div><div>also lends better to=
 an eventual commitment as you literally can&#39;t remove</div><div>anythin=
g from it, and still have it be useful for the traditional wallet use</div>=
<div>case.</div><div><br></div><div>As I mentioned in my last email, this c=
an be added as an additional filter</div><div>type, leaving it up the full =
node implementations that have deployed the</div><div>base protocol to inte=
grate it or not.</div><div><br></div><div>-- Laolu</div><div><br></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Fe=
b 5, 2019 at 4:21 AM Matt Corallo &lt;<a href=3D"mailto:lf-lists@mattcorall=
o.com">lf-lists@mattcorallo.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><br>
On 2/4/19 8:18 PM, Jim Posen via bitcoin-dev wrote:<br>
- snip -<br>
=C2=A0&gt; 1) Introduce a new P2P message to retrieve all prev-outputs for =
a given<br>
=C2=A0&gt; block (essentially the undo data in Core), and verify the script=
s<br>
=C2=A0&gt; against the block by executing them. While this permits some for=
ms of<br>
=C2=A0&gt; input script malleability (and thus cannot discriminate between =
all<br>
=C2=A0&gt; valid and invalid filters), it restricts what an attacker can do=
. This<br>
=C2=A0&gt; was proposed by Laolu AFAIK, and I believe this is how btcd is <=
br>
proceeding.<br>
<br>
I&#39;m somewhat confused by this - how does the undo data help you without=
 <br>
seeing the full (mistate compressed) transaction? In (the realistic) <br>
thread model where an attacker is trying to blind you from some output, <br=
>
they can simply give you &quot;undo data&quot; where scriptPubKeys are OP_T=
RUE <br>
instead of the real script and you&#39;d be none the wiser.<br>
<br>
On 2/5/19 1:42 AM, Olaoluwa Osuntokun via bitcoin-dev wrote:<br>
- snip -<br>
&gt; I think it&#39;s too late into the current deployment of the BIPs to c=
hange<br>
&gt; things around yet again. Instead, the BIP already has measures in plac=
e for<br>
&gt; adding _new_ filter types in the future. This along with a few other f=
ilter<br>
&gt; types may be worthwhile additions as new filter types.<br>
- snip -<br>
<br>
Huh? I don&#39;t think we should seriously consider <br>
only-one-codebase-has-deployed-anything-with-very-limited-in-the-wild-use <=
br>
as &quot;too late into the current deployment&quot;?<br>
<br>
Matt<br>
</blockquote></div></div>

--00000000000053729505812e7e3d--