summaryrefslogtreecommitdiff
path: root/80/f0c8eb279f10d1d96a822894f72ab812af56ef
blob: b0d789504f72a0d06d60e31f29c0669d72d87f04 (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
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <cryptocurrencies@quidecco.de>) id 1XvORf-0002Cl-AZ
	for bitcoin-development@lists.sourceforge.net;
	Mon, 01 Dec 2014 10:43:07 +0000
X-ACL-Warn: 
Received: from quidecco.de ([81.169.136.15])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1XvORd-0005Wk-IJ
	for bitcoin-development@lists.sourceforge.net;
	Mon, 01 Dec 2014 10:43:07 +0000
Received: from localhost (localhost [127.0.0.1])
	by quidecco.de (Postfix) with SMTP id 9E56EE170B7;
	Mon,  1 Dec 2014 11:42:58 +0100 (CET)
From: Isidor Zeuner <cryptocurrencies@quidecco.de>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
References: <CAAS2fgRSxBmyDg5R7WgisB-XmhrpGVKHXQpchtL-Ow0xDQAziA@mail.gmail.com>
	<CAJHLa0N6+hpwNECpHUSiKuj4-BYohh=Wr1DP=67Ff8xVBsi8-Q@mail.gmail.com>
	<54760A50.201@riseup.net> <20141127020947.A13D2E19A09@quidecco.de>
In-Reply-To: <CAAS2fgRSxBmyDg5R7WgisB-XmhrpGVKHXQpchtL-Ow0xDQAziA@mail.gmail.com>
Message-Id: <20141201104258.9E56EE170B7@quidecco.de>
Date: Mon,  1 Dec 2014 11:42:58 +0100 (CET)
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1XvORd-0005Wk-IJ
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: Mon, 01 Dec 2014 10:43:07 -0000

Hi Gregory,

response below quote:
> > Since this attack vector has been discussed, I started making some
> > measurements on how effective it is to connect to Bitcoin using Tor,
> > and I found that the number of connections dropping to near-zero is
> > a situation which occurs rather frequently, which suggests that there
> > is still room to improve on the DoS handling.
>
> I'm confused by this, I run quite a few nodes exclusively on tor and
> chart their connectivity and have seen no such connection dropping
> behaviour.
>
> Can you tell me more about how you measured this?
>

When you say "running exclusively on Tor", what do you mean exactly?
Do you also connect or allow connections through hidden services?

I made outbound connections through Tor exit points the only way to
connect to Bitcoin, and increased the number of allowed outbound
connection in order to get more meaningful values.

Lately, I could see unusual behaviour at:

* 2014-11-28 13:14 UTC
* 2014-11-25 07:32 UTC
* 2014-11-24 13:06 UTC

Anything I should look into?

> [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 (and the behaviour of
> the system here is known and intentional). There are other mechanisms
> available for people to relay their transactions than connecting
> directly to the bitcoin network; so their choice isn't just abandon
> privacy or don't use bitcoin at all.]
>

I think this issue is more important than it seems.

Firstly, when running Tor-only, there are still attack vectors which
make use of the DoS protection deficiencies.

Secondly, if we tell people not to connect directly if they want
privacy, how do we ensure that these indirect methods will not come
with implications for their privacy?

Best regards,

Isidor