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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <cryptocurrencies@quidecco.de>) id 1XK5uf-00022M-MR
for bitcoin-development@lists.sourceforge.net;
Wed, 20 Aug 2014 13:26:53 +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 1XK5ue-0005Sh-2q
for bitcoin-development@lists.sourceforge.net;
Wed, 20 Aug 2014 13:26:53 +0000
Received: from localhost (localhost [127.0.0.1])
by quidecco.de (Postfix) with SMTP id CB71CE043A5;
Wed, 20 Aug 2014 14:59:01 +0200 (CEST)
To: <bitcoin-development@lists.sourceforge.net>
From: Isidor Zeuner <cryptocurrencies@quidecco.de>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; format=flowed
In-Reply-To: <20140818164543.GB31175@localhost.localdomain>
Message-Id: <20140820125901.CB71CE043A5@quidecco.de>
Date: Wed, 20 Aug 2014 14:59:01 +0200 (CEST)
X-Spam-Score: -0.7 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1XK5ue-0005Sh-2q
Cc: Ivan Pustogarov <ivan.pustogarov@uni.lu>
Subject: [Bitcoin-development] Proposal: PoW-based throttling of addresses
(was: Outbound connections rotation)
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: Wed, 20 Aug 2014 13:26:53 -0000
Hi there,
quote:
[...]
> If two distinct transactions (with unrelated bitcoin addresses)
> come from the same set of 8 peers, the attacker can conclude that they
> originated from the same user. This gives another method (in addition
> to transaction graph analysis) for an attacker to link different BC
> addresses of the same user.
Using the same set of nodes for posting transactions using unrelated
inputs kind of limits the privacy improvement that can be gained from
using unrelated inputs in the first place.
Similar to how Tor uses different circuits for different hosts to
connect to, it may make more sense to only use the same set of nodes
for posting a subsequent transaction when the input addresses are also
the same.
[...]
> Some details are here: https://www.cryptolux.org/index.php/Bitcoin
>
I also find the topic of banning Tor exit nodes interesting.
I wonder if it makes more sense not to ban IP addresses completely,
but instead to throttle them using a PoW-based access control
scheme. Misbehaving addresses can have their connecting difficulty
scaled up, which should make it uneconomic to try to DoS the usage of
Tor exit nodes for connecting to Bitcoin.
It may also help nodes behind a NAT router if they share their global
IP with misconfigured nodes.
Best regards,
Isidor
|
