MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Sun, 02 Apr 2017 09:49:03 +1000
From: bfd@cock.lu
To: Chris Belcher <belcher@riseup.net>, Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <f8511114-4bcd-32a0-f654-414a723781fa@riseup.net>
References: <71d822e413ac457a530e1c367811cc24@cock.lu>
	<f8511114-4bcd-32a0-f654-414a723781fa@riseup.net>
Message-ID: <fd0fe6db5af3e7407744ebbe521797bf@cock.lu>
User-Agent: Roundcube Webmail/1.2.3
Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet
 performance and SPV security
Precedence: list

On 2017-02-17 11:28, Chris Belcher via bitcoin-dev wrote:
> I think this committed bloom filter idea is very good and much better
> than bip37, but for good privacy for when bitcoin is used often still
> requires certain behavior namely downloading blocks
> from many different peers with new tor circuits.
> 
> Note that I've been dealing with counting transaction subgraphs but
> actually finding them from blocks might also be computationally
> infeasible. Although a Bayesian approach worked very
> well for similar transaction subgraph linking
> [https://arxiv.org/pdf/1612.06747v3.pdf]
> 
> It would also be interesting to analyze what information a spy can get
> if they are missing some blocks that the wallet downloaded.
> 
> For the long term, private and high-volume bitcoin use will be best
> served by off-chain transactions. They will probably be a huge win just
> because the large and public blockchain is such a non-private
> way of doing things.
> 

Thank you for the analysis, this generally matches my views about the
properties offered by the system.

I've generally developed the opinion that BIP37 is effectively unused
by all but a very small number of wallets and services now, setting up
sinkhole nodes in the network to monitor `filterload` commands seems
to back that up.