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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <cryptocurrencies@quidecco.de>) id 1XL9tT-0007lb-Ex
for bitcoin-development@lists.sourceforge.net;
Sat, 23 Aug 2014 11:54:03 +0000
X-ACL-Warn:
Received: from [81.169.136.15] (helo=quidecco.de)
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1XL9tE-0003zQ-7J
for bitcoin-development@lists.sourceforge.net;
Sat, 23 Aug 2014 11:54:03 +0000
Received: from localhost (localhost [127.0.0.1])
by quidecco.de (Postfix) with SMTP id AC158E07036;
Sat, 23 Aug 2014 13:53:21 +0200 (CEST)
From: Isidor Zeuner <cryptocurrencies@quidecco.de>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
References: <CANEZrP1RzLmSB74xdFZbePAE9nxjR-_hSCGQhNH81vRKSji2AQ@mail.gmail.com>
<20140820125901.CB71CE043A5@quidecco.de>
In-Reply-To: <CANEZrP1RzLmSB74xdFZbePAE9nxjR-_hSCGQhNH81vRKSji2AQ@mail.gmail.com>
Message-Id: <20140823115321.AC158E07036@quidecco.de>
Date: Sat, 23 Aug 2014 13:53:21 +0200 (CEST)
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Headers-End: 1XL9tE-0003zQ-7J
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Ivan Pustogarov <ivan.pustogarov@uni.lu>
Subject: Re: [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: Sat, 23 Aug 2014 11:54:03 -0000
Hi Mike,
thanks for your assessment.
Please find my replies in-line:
> >
> > 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.
> >
>
> You can't solve DoS by requiring all clients to do complicated work,
Since when? This has been a recognized approach since people called it
"hashcash" ([1] - before cryptocurrencies were even invented).
I hear your concerns, but even then, I would see the PoW-based
approach as an improvement to today's situations.
To be clear, I do not propose to have _all_ clients do complicated
work. Just those using an address which has been misbehaving. Right
now, they cannot connect at all, no matter how much resources they
dedicate towards doing so.
> all
> that means is that weak clients (like users mobile phones and tablets) are
> successfully DoSd whereas the attackers botnet of stolen computers sit
> there solving PoWs.
>
The way I had it in mind, well-behaved clients on an address used by
attackers would have more effort to connect because of the PoW, but
after that, they can stay connected. The attacker also has to put more
effort into connecting, and after sending malformed messages, gets
disconnected. So, the attacker would have to perform much more PoW
computations in order to keep up his attack.
> The correct way to solve DoS is by having work prioritisation and queueing
> mechanisms, then finding ways to distinguish "good" clients from "bad"
> clients. Doing this whilst preserving privacy is hard. Long term the only
> way to solve it may be to require clients to present some kind of cookie
> during resource exhaustion events that prove they've been around for a
> while, thus allowing them to jump the queue.
>
Exactly. Not every user may like to have a cookie by which an observer
might get the chance to even link his connection to his previous
connections, thereby allowing the discussed deanonymization technique
to get even more effective.
Maybe having both options would be even better: In case of an attack,
those able to solve the anti-DoS PoW can still connect (just maybe
slower). Those who wish to run a weak client can choose to sacrifice
privacy for connectivity and keep a cookie for connecting.
Best regards,
Isidor
[1] http://www.hashcash.org/papers/hashcash.pdf
|
