summaryrefslogtreecommitdiff
path: root/8b/03099391ad65a1f6b5ae786e2164ba583c7c79
blob: b129bf972b8d8ad80fe04b778cbebc6fd56989e7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
Return-Path: <bfd@cock.lu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id BE4BAB7B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  1 Apr 2017 23:49:07 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from cock.li (cock.li [185.100.85.212])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C93C7FD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  1 Apr 2017 23:49:06 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.1
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.lu; s=mail;
	t=1491090543; bh=0AgZcQVvGwsLYtr2b2Nlpd11UMOR5vZubQRkHk74qM8=;
	h=Date:From:To:Subject:In-Reply-To:References:From;
	b=hRwmrFI+7npi7YXm8yLF/mGMhbyZsvpZd/gv6iYUAp7M68IexfR3gVtr8RYaGR7bZ
	Mi9A0nsh2CCHAl+5hNg59i1VJWLtSOaZSk2YkZcGP49ehbBv1llji0LrmgVaEC9sEn
	HnAzPHHiIHhfN92pIxSjrCh9EVro343laTfdWR7paN4GpOv2bgyoEBgP7rVYO03THr
	kKfaOwWK4dE6hzS2pfvX1+3CWFbvrTMnZ2SnOxrNtT3ohI/U3UCGnNF27lbjRq0Etx
	LYM/sxkOCKeiANtWuaosIb0L95w6j7iGPj0ifJCJ+MpLy4qY7qS6U7Fr0c3mTWhBF7
	aCKa1aT/HZENg==
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>
X-Sender: bfd@cock.lu
User-Agent: Roundcube Webmail/1.2.3
X-Mailman-Approved-At: Sat, 01 Apr 2017 23:50:17 +0000
Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet
 performance and SPV security
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Apr 2017 23:49:07 -0000

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.