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
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <cryptocurrencies@quidecco.de>) id 1Xp4XV-00070R-Eh
for bitcoin-development@lists.sourceforge.net;
Fri, 14 Nov 2014 00:15:02 +0000
X-ACL-Warn:
Received: from quidecco.de ([81.169.136.15])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Xp4XT-0006P6-A4
for bitcoin-development@lists.sourceforge.net;
Fri, 14 Nov 2014 00:15:01 +0000
Received: from localhost (localhost [127.0.0.1])
by quidecco.de (Postfix) with SMTP id 9DDF37C8853;
Thu, 13 Nov 2014 23:52:43 +0100 (CET)
From: Isidor Zeuner <cryptocurrencies@quidecco.de>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
References: <CANEZrP2rLUW2-SZXjEKMvgZVjjHwz-4TEHJoAaMd5=1N8R3G3Q@mail.gmail.com>
<20140823115321.AC158E07036@quidecco.de>
In-Reply-To: <CANEZrP2rLUW2-SZXjEKMvgZVjjHwz-4TEHJoAaMd5=1N8R3G3Q@mail.gmail.com>
Message-Id: <20141113225243.9DDF37C8853@quidecco.de>
Date: Thu, 13 Nov 2014 23:52:43 +0100 (CET)
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 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1Xp4XT-0006P6-A4
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: Fri, 14 Nov 2014 00:15:03 -0000
Hi Mike, hi Ivan, hi all,
>
> >
> > Since when? This has been a recognized approach since people called it
> > "hashcash" ([1] - before cryptocurrencies were even invented).
> >
>
> I only know of one site that worked the way you propose: TicketMaster, a
> long time ago. They used it as a less harsh form of blocking for IPs that
> they strongly suspected were bots, which is what you suggest indeed. But
> 99% of the hard work of that system was in scoring the connections. The
> actual PoW part didn't work that great because bots have much more patience
> than humans do.
>
I think the proposal back then was targeted at e-mail
delivery. Interestingly, one of today's most common approaches
against unsolicited e-mails, DKIM, can also be considered as being a
relative to PoW if we consider that bulk mailer operators don't
like it because of the CPU burden it creates. But with e-mail, people
tend to see it even as an advantage to also have identification of the
participants, so it's no surprise that pure PoW approaches did not
achieve importance.
With cryptocurrencies, it's different. Combating DoS without
creating additional ways to identify users is something where many
interested users can be found.
Humans may have less patience than an attacker who just wants to
achieve his DoS objective in a batch processing manner. But humans
also don't care if their patience is put to the test by having to
wait until one Tor exit node is finally unbanned, or by waiting for
the connection PoW to finish because it temporarily got harder due to
an attack.
No doubt that a dedicated attacker can have an (even big) advantage
resource-wise. But this is no different between the case where both
computing power and the number of Tor exit nodes are the resource to
compete on, and the case where it's just the resource of Tor exit
nodes that gets exhausted. But by giving users the choice of proving
their dedication through a connecting PoW challenge, I would expect
users having more possibilities of finding their way through a
DoS-imposed partial outage. After all, the possibly powerful attacker
has to invest his resources into making all access routes to the
network unusable, while for well-behaved users, every single access
route that still works is useful. Therefore, I think it makes sense to
add more degrees of freedom.
> Other sites also use proofs of work, but they're CAPTCHAs i.e. human PoWs.
> And unfortunately those don't work very well these days either :(
>
None of these measures are perfect. But I think we can achieve a
solution that is good enough. Hopefully without integrating a
centralized captcha provider ;)
>
> > To be clear, I do not propose to have _all_ clients do complicated
> > work. Just those using an address which has been misbehaving.
>
>
> Yes, I understand, but then you're back to scoring clients - the hard part
> - and the only question is do you slow down that client by sticking them at
> the bottom of a work queue or by requiring them to solve a difficult PoW.
> The best approach is the first one because that scales naturally .... you
> don't have to define some notion of misbehaviour, you just prioritise
> amongst clients.
>
On the one hand, I think that to some extent, the work queue based
throttling just moves the problem from making it hard to connect
towards making it hard to do something useful with your connection.
But as I touched above, I see the merit that comes from the PoW-based
approach in allowing well-behaving users to explore multiple axes of
putting effort into connecting. Expanding on this approach, I think
that the work queue based approach and PoW could be combined, leading
to three measures the nodes can use for throttling misbehaving
clients:
* scaling up connection PoW
* throttling the connection on the work queue
* throttling the IP on the work queue
The challenging part would be to properly tune the extent of the three
measures in order to throttle attackers' messages with minimum
impact to well-behaving users.
> The current notion of "misbehaviour" is only somewhat useful. It's easy to
> classify reasonable behaviour as harmful and shoot yourself in the foot. We
> managed this at least once back in 2010 when we actually released a version
> of Bitcoin that interpreted a normal request to serve the block chain as a
> DoS attack! It couldn't serve the chain at all! Additionally many things
> that can be interpreted as an attack like sending a message with a bad
> signature can also be caused just by mistakes, or version skew during
> software upgrades. So it's very tricky to get this right.
>
Sure, but that's a different topic. It may not be even realistic
to have a model which can be reduced to deciding between purposeful
misbehaviour and regular usage. But an attacker who wants to cut off
IPs from the network will always use whatever misbehaviour that leads
to maximum penalty, meaning that it is a decision between not
penalizing at all, or doing so.
> That's important because one quite common way big sites suffer DoS attacks
> is by accidentally having real users create a DoS "attack" by e.g. pushing
> a bad software update, or by having sudden and unexpected press-driven
> growth, etc. You really don't want to force users to sit around waiting and
> wasting battery. It's better to serve as many requests as you can up to
> your absolute limit and try to ensure as many of them as possible are good.
>
I'd say, better have a few Tor-based users realize that they
should look for a fixed update because their client has to do PoW for
connecting, rather than having all Tor-based users locked out.
Still, users should be notified that something is unusual.
>
> > 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.
> >
>
> I doubt it matters. Any DoS attack that's powerful enough to use up most of
> the networks resources is probably being driven by a botnet of some kind,
> and *all* legitimate users will lose in an even fight against a botnet.
>
> Cookies can be somewhat anonymized. For example a cookie that is merely a
> signature over a timestamp of some kind (doesn't have to be an secp256k1
> signature) can be normalised to the day or week. So you can prove you've
> been using Bitcoin for say 3 years but it doesn't pin you down precisely.
>
> This isn't perfect: attackers can and do "age" accounts before preparing
> for abuse. Proof of UTXO is another way to rank users. If you're richer
> you're presumably more important for the network to process than poor
> people. However you end up back at a CPU imbalance. PoW can possibly play a
> role here to even it out: the cost of submitting a UTXO proof should be at
> least equal to the cost of verifying the signature, but that is a PoW small
> enough that users would not notice.
>
Both cookies and Proof of UTXO sound like interesting approaches, but
I still see additional possibilities to deduce information about the
user identity here. They could be a nice addition for a better
approach to handle DoS attacks, but I would disagree when it comes to
only providing possibly privacy-weakening approaches.
I'm looking forward to your comments.
Best regards,
Isidor
|
