Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.171 as permitted sender)
	client-ip=209.85.213.171; envelope-from=gmaxwell@gmail.com;
	helo=mail-ig0-f171.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP32M-hSU-a1DA5aTQXsx-6425sTeKW-m-cSUuXCYf+zuQ@mail.gmail.com>
References: <CALqxMTE2doZjbsUxd-e09+euiG6bt_J=_BwKY_Ni3MNK6BiW1Q@mail.gmail.com>
	<CANEZrP32M-hSU-a1DA5aTQXsx-6425sTeKW-m-cSUuXCYf+zuQ@mail.gmail.com>
Date: Fri, 20 Feb 2015 17:50:11 +0000
Message-ID: <CAAS2fgSEqYNiGFk0pZ-hT_0zR7_Nh1OUvyfFd-DE=a-cdzgWwQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] bloom filtering, privacy
Precedence: list

On Fri, Feb 20, 2015 at 4:54 PM, Mike Hearn <mike@plan99.net> wrote:
> And then what? So you know the block matches. But with reasonable FP rates
> every block will match at least a few transactions (this is already the case

This approach needs a filter set with a lower FP rate. It doesn't
depend on having a high FP rate for privacy (which is good, since
counting on filter false positives seems to more or less fail to
deliver actual privacy in any case.)

Larger filters mean a somewhat higher baseline bandwidth, though when
users do not reuse addresses and have more addresses than there are
txouts in the block the gap is narrower.

> Ah, I see, I didn't catch that this scheme relies on UTXO commitments

This is talking about a committed bloom filter. Not a committed UTXO set.