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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <cryptocurrencies@quidecco.de>) id 1Xz2HH-0000pA-AE
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Dec 2014 11:51:27 +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 1Xz2HF-00006A-P7
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Dec 2014 11:51:27 +0000
Received: from localhost (localhost [127.0.0.1])
by quidecco.de (Postfix) with SMTP id C2587E22B8D;
Thu, 11 Dec 2014 12:51:18 +0100 (CET)
From: Isidor Zeuner <cryptocurrencies@quidecco.de>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; format=flowed
References: <CAAS2fgRPZ5yrHYrdG8fEZQi92J-DVY_fZNFc8wnt81Pvx_mLNQ@mail.gmail.com>
<CABssiCpUE=3GhC+Scd3htzVb9+gmLeZ0mEO5LY-zxywvguZ--w@mail.gmail.com>
In-Reply-To: <CAAS2fgRPZ5yrHYrdG8fEZQi92J-DVY_fZNFc8wnt81Pvx_mLNQ@mail.gmail.com>
Message-Id: <20141211115118.C2587E22B8D@quidecco.de>
Date: Thu, 11 Dec 2014 12:51:18 +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: 1Xz2HF-00006A-P7
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, 11 Dec 2014 11:51:27 -0000
[...]
> And, on the flip side if the host is persistently behind tor, even
> with some watermarkable behaviour, their privacy is protected. So
> making sure that hosts can continually use tor (or similar systems)
> should be the higher priority. (And, of course, not reimplementing
> tor leverages the millions of dollars of investment and dozens of
> subject matter experts working on that system).
>
Reimplementing Tor would not only mean to lose all the investment that
ran into Tor, but also to lose a large user base. We can see this with
TorCoin. Still, the fact that Bitcoin is a use case for Tor which
measurably shows some limits where it is not fully clear if Tor or
Bitcoin is to be blamed does not only mean that both projects may
have to evolve in order to properly solve the issue, but also that the
means of interfacing between both projects may have to be
extended. Ideally, in a way which does not require to run a separate
Tor and/or Bitcoin network in order to work, but which will be generic
enough to satisfy both sides' need to still work in a standalone
manner.
But I do see huge merit in exploring better ways of synergy between
the projects. For example, Tor's hardcoded circuit length may be
considered as a hack which was only necessary due to the lack of a
suitable resource compensation mechanism. Which is something that is
available with Bitcoin.
Best regards,
Isidor
|
