Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8BBAEA4DB for ; Wed, 6 Feb 2019 00:06:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A5E005D0 for ; Wed, 6 Feb 2019 00:06:12 +0000 (UTC) Received: by mail-yb1-f179.google.com with SMTP id k9so1798712ybg.1 for ; Tue, 05 Feb 2019 16:06:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dshSWAtVxdcR1FHPv7r2V0Im41zbUcuTC6THHlz+74E=; b=ZnI9V9eQfQywcQirPhGP9c28iGduKKrVqc2vYidjbCJyOAy1VZLn9p5mFLU5KyYngo Hl7Ynf9NGpYR+OAYGLgmNvioO+U+r7OejB9VuZjIOl2zhuMgcweV/TMR/+vyWspfnpsM CO/d7C9jUMeN+63ITkyDA4FVPQinXMhVTgHSEte0FuKW/kawkIe5wpSSSortsdFG1EZ2 WvPCBwCYHQFxSMymUKi4rZnZXQ2GJFrQMeKvuvLKwMeAkZ7IuHpPtoPjATCHFdyNzMs/ R6zApFvijZkvaA+I8RLV72hnErtWYKPUo87C0mWHt6PKL6PDg0wBm99t/jW2cTH8q3Gb Fuqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dshSWAtVxdcR1FHPv7r2V0Im41zbUcuTC6THHlz+74E=; b=hdPbK1JxqjX4j4buqog+pJn0yquH4jWcukSLmykAozKOr6ssG0pjA1B/Jsj5or0a2r 9PZAp5Pcq3Ebup+8gvZFZBL+lACnXj4/F7r+e4CmsBM6JQP7OaOihA1KsdVbb66fMaso Vf7ofmgxfnM9NfN2tBrUqOhAkDJPZPV3sbevftBumktOKUBx2NB3RWcJp1yb/oE6t43g qC0lrT/mK50bRtaBcQqQG8B3itJw02ETyf4+LS8ytCDMajwFgmvaLW89ceETZmViOeia e8c/iMezGgiXyJQROrTxFI1QTkPmmYAzNESxVWtcYjOC54gQEGStTiI/iQvWxEXea2Rf kkrQ== X-Gm-Message-State: AHQUAuaDAjH0EqVOJSLUJJGVbGDBRQPKWtVW1zNaSHMRoZD8zJVAMqXm lEekr6NsoVpFBN29CNlE1bYbUN7kjKt41NwmySs= X-Google-Smtp-Source: AHgI3IYNSOlGOp/wM3TApR1mCcumyqWMYt9ge54+PH3SAhNswHi7rtLjWgKI8OxNXFjhoA9v99vMID2+xY24SekdW+0= X-Received: by 2002:a25:241:: with SMTP id 62mr6042862ybc.201.1549411571428; Tue, 05 Feb 2019 16:06:11 -0800 (PST) MIME-Version: 1.0 References: <6D57649F-0236-4FBA-8376-4815F5F39E8A@gmail.com> <97c96822-df5e-0c65-3992-6e292577ce66@mattcorallo.com> In-Reply-To: <97c96822-df5e-0c65-3992-6e292577ce66@mattcorallo.com> From: Olaoluwa Osuntokun Date: Tue, 5 Feb 2019 16:05:57 -0800 Message-ID: To: Matt Corallo Content-Type: multipart/alternative; boundary="00000000000053729505812e7e3d" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 06 Feb 2019 15:48:05 +0000 Cc: Bitcoin Protocol Discussion , Jim Posen Subject: Re: [bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal 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: Wed, 06 Feb 2019 00:06:13 -0000 --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 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
Hi Matt,

> In (the realis= tic) thread model where an attacker is trying to blind you
> f= rom some output, they can simply give you "undo data" where scrip= tPubKeys
> 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 witn= ess script is included in the witness (the last element), I
can e= asily verify that the pkScript given is the proper witness program.

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

I'd wager that most developers reading = this email right now are familiar
with neutrino as a project. Man= y even routinely use "neutrino" to refer to
BIP 157+158= . There are several projects in the wild that have already
deploy= ed applications built on lnd+neutrino live on mainnet. lnd+neutrino is
also the only project (as far as I'm aware) that has fully integr= ated 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 suc= h as atomic swaps. Using
scripts also allows for faster rescans i= f one knows all their keys ahead of
time, as the checks can be pa= rallelized. Additionally, the current filter
also lends better to= an eventual commitment as you literally can't remove
anythin= g from it, and still have it be useful for the traditional wallet use
=
case.

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

-- Laolu


=
On Tue, Fe= b 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 -
=C2=A0> 1) Introduce a new P2P message to retrieve all prev-outputs for = a given
=C2=A0> block (essentially the undo data in Core), and verify the script= s
=C2=A0> against the block by executing them. While this permits some for= ms of
=C2=A0> input script malleability (and thus cannot discriminate between = all
=C2=A0> valid and invalid filters), it restricts what an attacker can do= . This
=C2=A0> was proposed by Laolu AFAIK, and I believe this is how btcd is <= br> 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_T= RUE
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 c= hange
> things around yet again. Instead, the BIP already has measures in plac= e for
> adding _new_ filter types in the future. This along with a few other f= ilter
> 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 <= br> as "too late into the current deployment"?

Matt
--00000000000053729505812e7e3d--