MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <537fb7106e0387c77537f0b1279cbeca@cock.lu>
References: <CAO3Pvs8ccTkgrecJG6KFbBW+9moHF-FTU+4qNfayeE3hM9uRrg@mail.gmail.com>
	<oi8e8k$g56$1@blaine.gmane.org>
	<537fb7106e0387c77537f0b1279cbeca@cock.lu>
From: Gregory Maxwell <greg@xiph.org>
Date: Mon, 19 Jun 2017 22:41:49 +0000
Message-ID: <CAAS2fgQ4nfYrRasm7jwx4B86fNKb6NvpHy-Dt=3bfiaNt10snA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for
 Light Clients
Precedence: list

On Mon, Jun 19, 2017 at 12:26 PM, bfd--- via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Several times. It's been debated if unconfirmed transactions are necessary,
> methods of doing more private filtering have been suggested, along with
> simply not filtering unconfirmed transactions at all. My collected data
> suggests that there is very little use of BIP37 at present, based on
> incoming connections to nodes I know end up in the DNS seed responses (no
> "SPV" clients do their own peer management).

Sending just the output addresses of each transaction would use about
1 kilobit/s of data. Sending the entire transactions would use
~14kbit/sec data.  These don't seem to be a unsustainable tremendous
amount of data to use while an application is running.

Doubly so for SPV wallets which are highly vulnerable to unconfirmed
transactions, and many which last I heard testing reports on became
pretty severely corrupted once given a fake transaction.

Can someone make a case why saving no more than those figures would
justify the near total loss of privacy that filtering gives?

"Because they already do it" isn't a good argument when talking about
a new protocol feature; things which already do BIP37 will presumably
continue to already do BIP37.