To address the at-least-one-honest peer security assumption for light clients, I think this is a rather good security model for light clients. First it significantly reduces the chances that an attacker can eclipse a client just by chance, and clients can implement measures like ensuring connectivity to peers from different subnets. But even if, as you suggest, a network attacker controls the target's local network, peers still can have good security guarantees by requiring authenticated connections to semi-trusted peers. A client can select a set of N servers that it believes will not collude to attack it, and only sync filters if connected to a threshold of them. So even if the network is malicious, the attacker cannot forge the authenticated responses. The level of trust in these designated parties again is quite low because only one has to be honest. This would require something like BIP 150.

Even if clients are uncomfortable with whitelisting required peers, it could have a policy of requiring a certain number of connections to peers that have honestly served it filters in the past. This is sort of like trust-on-first-use. This type of scheme, however, would require nodes to advertise a pubkey per address, which BIP 150/151 does not support at present.

All in all, I think this is an acceptable security model for light clients. Without the ability to verify filter validity, a client would have to stop syncing altogether in the presence of just one malicious peer, which is unacceptable.

The other concern you raise, Greg, is using a filter for P2P communications that we expect may be replaced in the future. You also raise the point that full node wallets can use the smaller filters for rescans because the filter validity is not in question. I'd perfectly fine with the idea of defining two filter types in the BIP, one that is output script + outpoint and the other output script + prev script. But I imagine some people would object to the idea of full nodes storing two different filters that overlap in contents. If we had to pick just one though, I'm strongly in support of output script + outpoint so that BIP 157 can be deployed ASAP without a consensus change. It's entirely possible we will learn even more about optimal filter design through deployment and adoption.

On Fri, Jun 1, 2018 at 5:22 PM Gregory Maxwell <greg@xiph.org> wrote:
On Sat, Jun 2, 2018 at 12:01 AM, Olaoluwa Osuntokun <laolu32@gmail.com> wrote:
>> 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.

I wish that were the true, but absent commitments that wouldn't be the
case unless you were always downloading all the blocks-- since you
wouldn't have any sign that there was something wrong with the
filter-- and downloading all the blocks would moot using the filters
in the first place. :)

Or have I misunderstood you massively here?

For segwit originally I had proposed adding additional commitments
that would make it possible to efficiently prove invalidity of a
block; but that got stripped because many people were of the view that
the "assume you have at least one honest peer who saw that block and
rejected it to tell you that the block was invalid" security
assumption was of dubious value. Maybe it's more justifiable to make
use of a dubious assumption for a P2P feature than for a consensus
feature?  Perhaps,  I'd rather have both filter types from day one so
that things not implementing the comparison techniques don't get the
efficiency loss or the extra work to change filter types for a
consensus one.

[I think now that we're much closer to a design that would be worth
making a consensus committed version of than we were a few months ago
now, since we are effectively already on a second generation of the
design with the various improvements lately]