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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1XtwuK-0000MN-Kg
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Nov 2014 11:06:44 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.54 as permitted sender)
client-ip=74.125.82.54; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f54.google.com;
Received: from mail-wg0-f54.google.com ([74.125.82.54])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XtwuJ-0005Iw-Dr
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Nov 2014 11:06:44 +0000
Received: by mail-wg0-f54.google.com with SMTP id l2so6157234wgh.41
for <bitcoin-development@lists.sourceforge.net>;
Thu, 27 Nov 2014 03:06:37 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.104.197 with SMTP id gg5mr12359062wib.7.1417086384977;
Thu, 27 Nov 2014 03:06:24 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.89.130 with HTTP; Thu, 27 Nov 2014 03:06:24 -0800 (PST)
In-Reply-To: <CAAS2fgRSxBmyDg5R7WgisB-XmhrpGVKHXQpchtL-Ow0xDQAziA@mail.gmail.com>
References: <CAJHLa0N6+hpwNECpHUSiKuj4-BYohh=Wr1DP=67Ff8xVBsi8-Q@mail.gmail.com>
<54760A50.201@riseup.net> <20141127020947.A13D2E19A09@quidecco.de>
<CAAS2fgRSxBmyDg5R7WgisB-XmhrpGVKHXQpchtL-Ow0xDQAziA@mail.gmail.com>
Date: Thu, 27 Nov 2014 12:06:24 +0100
X-Google-Sender-Auth: JLDwOMOZ9S5MpKKE5cJkd_i4NrM
Message-ID: <CANEZrP2JLUu9V4HGSLWr1Mg37qmTFVuihTQhJeJ4iyQPxrqsMQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=f46d041825bc97c0340508d522ec
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XtwuJ-0005Iw-Dr
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P
network paper
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: Thu, 27 Nov 2014 11:06:44 -0000
--f46d041825bc97c0340508d522ec
Content-Type: text/plain; charset=UTF-8
>
> [As an aside I agree that there are lots of things to improve here,
> but the fact that users can in theory be forced off of tor via DOS
> attacks is not immediately concerning to me because its a conscious
> choice users would make to abandon their privacy
Bitcoin already has a large population of users who have little or no
technical skill, it wouldn't surprise me at all if it was found to be the
clear majority by now. Assuming success and growth in future, very few
users will make any decisions at all about their privacy, they will just
accept the defaults. In such a world no consumer wallet is going to
directly expose Tor to end users - if used at all it'll just be used behind
the scenes. So automated fallback or control over exits would be a concern
for such wallets.
My gut feeling about this stuff has changed over time. I don't think it'd
be a great idea to tie Bitcoin to Tor too deeply, convenient though its
infrastructure is. Most apps don't need a whole lot of onion routing - a
small amount built in to the p2p layer would be sufficient. Tor is huge,
complicated and could be a liability in future.
--f46d041825bc97c0340508d522ec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">[As an aside I agree that there are lots of thin=
gs to improve here,<br>
but the fact that users can in theory be forced off of tor via DOS<br>
attacks is not immediately concerning to me because its a conscious<br>
choice users would make to abandon their privacy</blockquote><div><br></div=
><div>Bitcoin already has a large population of users who have little or no=
technical skill, it wouldn't surprise me at all if it was found to be =
the clear majority by now. Assuming success and growth in future, very few =
users will make any decisions at all about their privacy, they will just ac=
cept the defaults. In such a world no consumer wallet is going to directly =
expose Tor to end users - if used at all it'll just be used behind the =
scenes. So automated fallback or control over exits would be a concern for =
such wallets.</div><div><br></div><div>My gut feeling about this stuff has =
changed over time. I don't think it'd be a great idea to tie Bitcoi=
n to Tor too deeply, convenient though its infrastructure is. Most apps don=
't need a whole lot of onion routing - a small amount built in to the p=
2p layer would be sufficient. Tor is huge, complicated and could be a liabi=
lity in future.</div></div></div></div>
--f46d041825bc97c0340508d522ec--
|
