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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <cryptocurrencies@quidecco.de>) id 1Y0VeN-0002Vy-GD
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Dec 2014 13:25:23 +0000
X-ACL-Warn:
Received: from quidecco.de ([81.169.136.15])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Y0VeL-0006kl-Jl
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Dec 2014 13:25:23 +0000
Received: from localhost (localhost [127.0.0.1])
by quidecco.de (Postfix) with SMTP id BCC88E2353B;
Mon, 15 Dec 2014 14:25:14 +0100 (CET)
To: Wladimir <laanwj@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
From: Isidor Zeuner <cryptocurrencies@quidecco.de>
References: <CA+s+GJBsxmQJkrUYekFuUOgmEcD7qeL2e9Rf-d2nD1G1N7c_EQ@mail.gmail.com>
<CAJHLa0N6+hpwNECpHUSiKuj4-BYohh=Wr1DP=67Ff8xVBsi8-Q@mail.gmail.com>
<54760A50.201@riseup.net> <20141127020947.A13D2E19A09@quidecco.de>
<CAAS2fgRSxBmyDg5R7WgisB-XmhrpGVKHXQpchtL-Ow0xDQAziA@mail.gmail.com>
In-Reply-To: <CA+s+GJBsxmQJkrUYekFuUOgmEcD7qeL2e9Rf-d2nD1G1N7c_EQ@mail.gmail.com>
Message-Id: <20141215132514.BCC88E2353B@quidecco.de>
Date: Mon, 15 Dec 2014 14:25:14 +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: 1Y0VeL-0006kl-Jl
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, 15 Dec 2014 13:25:23 -0000
[...]
> > 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.
>
> In my experience the problem has always been getting bootstrapped.
> Most nodes hardly give any hidden service nodes in their getaddr.
> (this has been improved in master by including a set of hidden service
> seed nodes)
> But this assumes -onlynet=tor. Tor with exit nodes should be less
> problematic, unless someone managed to DoSban all the exit nodes as
> described in the paper (but I've never seen such an attack myself).
>
When refering to "getting bootstrapped", do you only mean collecting
node addresses, or also syncing blocks?
If you're saying the drops in connection counts are likely to be
not caused by a DoSban attack on the exit nodes, what could be other
reasons to look into?
> > Can you tell me more about how you measured this?
> >
> > [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.]
>
> Right, there's something to be said for splitting your own transaction
> submission from normal P2P networking and transaction relay.
> (esp for non-SPV wallets which don't inherently leak any information
> about their addresses)
>
> There was a pull request about this for Bitcoin Core one, maybe I
> closed it unfairly https://github.com/bitcoin/bitcoin/issues/4564 .
>
Great! I find it very interesting to research options for splitting
communication between Tor and non-Tor as long as the introduced
information leakage between both connection methods can be proved to
be nonexistent or negligible.
In the case of Bitcoin, this makes me wonder about an attack that
could look approximately like this:
* Node A connects to Bitcoin using Tor (for submitting transactions)
and IPv4 (for all other communication).
* Node B strives for direct IPv4 connections with node A
* Node B uses the direct IPv4 connections in order to supply Node A
with additional peer addresses not supplied to any other nodes
* Node B observes these additional peer addresses
For transactions submitted to the additional peer addresses supplied
by node B, how to prevent that the probability of these originating
from node A is higher than for originating from other nodes?
For handling block propagation using non-Tor connections, it's
probably harder to create information leaks, as the logic for handling
disagreement about blocks is pretty well-researched, meaning that
it's less important where the blocks come from.
Best regards,
Isidor
|
