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
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1WsyC3-00007g-Ca
for bitcoin-development@lists.sourceforge.net;
Fri, 06 Jun 2014 17:44:43 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.113 as permitted sender)
client-ip=62.13.149.113; envelope-from=pete@petertodd.org;
helo=outmail149113.authsmtp.com;
Received: from outmail149113.authsmtp.com ([62.13.149.113])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WsyC2-0005zj-2s for bitcoin-development@lists.sourceforge.net;
Fri, 06 Jun 2014 17:44:43 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s56HiVZU069151;
Fri, 6 Jun 2014 18:44:31 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s56HiJJw050511
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 6 Jun 2014 18:44:21 +0100 (BST)
Date: Fri, 6 Jun 2014 13:45:45 -0400
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20140606174545.GB29195@savin>
References: <20140606081933.GA29458@savin>
<20140606084852.GA30247@netbook.cypherspace.org>
<20140606090441.GA19256@savin>
<20140606104543.GA31085@netbook.cypherspace.org>
<20140606164639.GB14891@savin>
<CAAS2fgTKiPMPOazNTPL8+3Ov1xOj=H+yK3u+sd_pe=nyDSPgTw@mail.gmail.com>
<20140606170524.GA29195@savin>
<CAAS2fgT3CfJ9Lf2H2BYVfUeJoF0RBi+EMmAghj5G2vJPtahmjg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA"
Content-Disposition: inline
In-Reply-To: <CAAS2fgT3CfJ9Lf2H2BYVfUeJoF0RBi+EMmAghj5G2vJPtahmjg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 316e2647-eda2-11e3-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgQUEkAaAgsB AmIbWlxeVFl7W2E7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrBBp5 X2RkFRl3dwBHeTBx YkJgVj5YXUIvd0B5
RVMBQTwEeGZhPWMC WRZfcx5UcAFPdx8U a1N6AHBDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4hGjk7 QlgIFDQzdQAA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1WsyC2-0005zj-2s
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bloom bait
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 06 Jun 2014 17:44:43 -0000
--neYutvxvOLaeuPCA
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jun 06, 2014 at 10:10:51AM -0700, Gregory Maxwell wrote:
> On Fri, Jun 6, 2014 at 10:05 AM, Peter Todd <pete@petertodd.org> wrote:
> > Again, you *don't* have to use brute-force prefix selection. You can
> > just as easily give your peer multiple prefixes, each of which
> > corresponds at least one address in your wallet with some false positive
> > rate. I explained all this in detail in my original blockchain data
> > privacy writeup months ago.
>=20
> I'm not trying to pick nits about all the options, I just found it
> surprising that you were saying that data published in a super public
> manner is no different than something used between nodes.
Because I was designing a system under the assumption that you were
highly likely to connect to an attacker at some point, and the trade-off
available with the available math was to either give very detailed info
to that attacker, or give away some probabalistic info to everyone.
> > I explained all this in detail in my original blockchain data privacy w=
riteup months ago.
>=20
> Communication is a two way street, Adam and I (and others) are
> earnestly trying=E2=80=94 that we're not following your arguments may be a
> suggestion that they need to be communicated somewhat differently.
Quite likely - I think most of this disagreement stems from the fact
that we have different starting assumptions. In particular my assumption
that you are likely to end up connecting to an attacker logging data,
and my desire to have a standard that can be implemented with existing
cryptographic primatives. Remember that I'm spending a lot of time
working with wallet authors; they have approximately zero interest in
standards that require crypto any more fancy than HD wallets do.
> I'm still failing to see the usefulness of having any prefix filtering
> for DH-private outputs. It really complicates the security story=E2=80=94=
in
> particular you don't know _now_ what activities will turn your prior
> information leaks into compromising ones retrospectivelly, and doesn't
> seem at very necessary for scanning performance.
Scanning performance is different from bandwidth performance. Prefix
brute-forcing was designed to address the latter concern for cases where
you are bandwidth limited and don't have a trusted peer to do the
scanning for you.
--=20
'peter'[:-1]@petertodd.org
00000000000000001c5e0fca7bd6d96211a37543c1d0cc2f594c15423ee3cdd8
--neYutvxvOLaeuPCA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJTkf5FXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxOWU5YTIwNDdiZTNmOTYwOGQ4ZWZhNTVlYTAzZjdmMzc5
MTFlMDVmYTNlMTgzOGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsUjQf+ILSV0jvyXulBefvuz4eivTOD
2K4Jc6Tbc7bAWBFgT8JgiT3G1lnPVoBke31i38MxM95jY92hJNn/JJ1cUt7lWr1T
g/MG/Lsi63uXJ1h/JJx9gPxmmhnulv+w+KeudjVbbtxZ3RCFr1AKR0r/n6SciQdy
UWw6AmyPXiu2rdxC/lEIX6+3oneH26ITJlZSS0RB/nKZFjFt3JgCrYSJ8byLrP5F
bchMCt1gOzOUakPYh9vblxJ9P9KpOnYU+no9q1M/+PKcjW64z3O0CBetgp0dI78R
qqhPrvCUOCmhzuTSseB1qfWDJt6y27RCscZwlhyjDjFWny6oA7rAgnEF5OI/qw==
=UgCA
-----END PGP SIGNATURE-----
--neYutvxvOLaeuPCA--
|
