To: Olaoluwa Osuntokun <laolu32@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Tamas Blummer <tamas.blummer@gmail.com>
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>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <97c96822-df5e-0c65-3992-6e292577ce66@mattcorallo.com>
Date: Tue, 5 Feb 2019 12:21:45 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
	Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <CAO3Pvs_gvYy99Bch=7RwVszM_0PFTKUyqDVok=xfm4OOcqwaaQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Cc: Jim Posen <jimpo@coinbase.com>
Subject: Re: [bitcoin-dev] Interrogating a BIP157 server,
 BIP158 change proposal
Precedence: list


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