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
206
207
208
209
|
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 <mh.in.england@gmail.com>) id 1XLAyo-0002UY-D8
for bitcoin-development@lists.sourceforge.net;
Sat, 23 Aug 2014 13:03:38 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.50 as permitted sender)
client-ip=209.85.219.50; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f50.google.com;
Received: from mail-oa0-f50.google.com ([209.85.219.50])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XLAyY-0000lS-8b
for bitcoin-development@lists.sourceforge.net;
Sat, 23 Aug 2014 13:03:38 +0000
Received: by mail-oa0-f50.google.com with SMTP id g18so9475172oah.37
for <bitcoin-development@lists.sourceforge.net>;
Sat, 23 Aug 2014 06:03:05 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.19.135 with SMTP id f7mr10704460obe.40.1408798985802;
Sat, 23 Aug 2014 06:03:05 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.82.34 with HTTP; Sat, 23 Aug 2014 06:03:05 -0700 (PDT)
In-Reply-To: <20140823115321.AC158E07036@quidecco.de>
References: <20140820125901.CB71CE043A5@quidecco.de>
<CANEZrP1RzLmSB74xdFZbePAE9nxjR-_hSCGQhNH81vRKSji2AQ@mail.gmail.com>
<20140823115321.AC158E07036@quidecco.de>
Date: Sat, 23 Aug 2014 15:03:05 +0200
X-Google-Sender-Auth: xQ-gDi8WRaxmT3q7U0RMjWqK1e8
Message-ID: <CANEZrP2rLUW2-SZXjEKMvgZVjjHwz-4TEHJoAaMd5=1N8R3G3Q@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Isidor Zeuner <cryptocurrencies@quidecco.de>
Content-Type: multipart/alternative; boundary=001a11c299661bded805014b93d9
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline
X-Headers-End: 1XLAyY-0000lS-8b
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 13:03:38 -0000
--001a11c299661bded805014b93d9
Content-Type: text/plain; charset=UTF-8
>
> 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.
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 :(
> 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.
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.
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.
> 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.
--001a11c299661bded805014b93d9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">Since when? This has been a recognized approach =
since people called it<br>
"hashcash" ([1] - before cryptocurrencies were even invented).<br=
></blockquote><div><br></div><div>I only know of one site that worked the w=
ay 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 sco=
ring the connections. The actual PoW part didn't work that great becaus=
e bots have much more patience than humans do.</div>
<div><br></div><div>Other sites also use proofs of work, but they're CA=
PTCHAs i.e. human PoWs. And unfortunately those don't work very well th=
ese days either :(</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To be clear, I do not propose to have _all_ clients do complicated<br>
work. Just those using an address which has been misbehaving.</blockquote><=
div><br></div><div>Yes, I understand, but then you're back to scoring c=
lients - the hard part - and the only question is do you slow down that cli=
ent 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 scal=
es naturally .... you don't have to define some notion of misbehaviour,=
you just prioritise amongst clients.=C2=A0</div>
<div><br></div><div>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 re=
quest to serve the block chain as a DoS attack! It couldn't serve the c=
hain 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 mist=
akes, or version skew during software upgrades. So it's very tricky to =
get this right.</div>
<div><br></div><div>That's important because one quite common way big s=
ites suffer DoS attacks is by accidentally having real users create a DoS &=
quot;attack" by e.g. pushing a bad software update, or by having sudde=
n and unexpected press-driven growth, etc. You really don't want to for=
ce users to sit around waiting and wasting battery. It's better to serv=
e as many requests as you can up to your absolute limit and try to ensure a=
s many of them as possible are good.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D""><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
Exactly. Not every user may like to have a cookie by which an observer<br><=
/blockquote></div>
might get the chance to even link his connection to his previous<br>
connections, thereby allowing the discussed deanonymization technique<br>
to get even more effective.<br></blockquote><div><br></div><div>I doubt it =
matters. Any DoS attack that's powerful enough to use up most of the ne=
tworks resources is probably being driven by a botnet of some kind, and <u>=
all</u> legitimate users will lose in an even fight against a botnet.</div>
<div><br></div><div>Cookies can be somewhat anonymized. For example a cooki=
e that is merely a signature over a timestamp of some kind (doesn't hav=
e to be an secp256k1 signature) can be normalised to the day or week. So yo=
u can prove you've been using Bitcoin for say 3 years but it doesn'=
t pin you down precisely.</div>
<div><br></div><div>This isn't perfect: =C2=A0attackers can and do &quo=
t;age" accounts before preparing for abuse. Proof of UTXO is another w=
ay 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 o=
f 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.=
</div>
</div></div></div>
--001a11c299661bded805014b93d9--
|
