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
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1XqhYA-0003EH-IR
for bitcoin-development@lists.sourceforge.net;
Tue, 18 Nov 2014 12:06:26 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.46 as permitted sender)
client-ip=209.85.215.46; envelope-from=mh.in.england@gmail.com;
helo=mail-la0-f46.google.com;
Received: from mail-la0-f46.google.com ([209.85.215.46])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XqhY8-0005Fl-Tf
for bitcoin-development@lists.sourceforge.net;
Tue, 18 Nov 2014 12:06:26 +0000
Received: by mail-la0-f46.google.com with SMTP id gd6so4148307lab.5
for <bitcoin-development@lists.sourceforge.net>;
Tue, 18 Nov 2014 04:06:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=mime-version:references:from:date:message-id:subject:to:cc
:content-type;
bh=iC5vKmy1f3q78GD4U2oqw7fGT80oPTTvdl6QjKNMpTk=;
b=Wn1ocaYJ8DlpKU5+P/psb4TDw372kLTt0ZwJwebhrKzSfF8yIY++2oh8n4MUFjbT9z
C25/L/P/WZE1UK1Ud5qvrAT9sCZ1+R2hp7hHBCOgjbXdQ2DMjznBI+nsqx363yZ+0Npn
rol2Wg5IYQOTrFDQOyh7yp+yPFv0eSV2K9EPAmOOaoG9pQprsrH7D9igK5ydot+pAn3A
B6L5NwklB0LbeAukL/ui+4kySiHTM1ZHg4ZkQtRWo11gBk+8mKHOORSweGo4IIpc1nlU
yPyBAMsKYrubh1giXJg2DgYeImXUA9QawaMMAQUczSPdK70DZVJvRpTbhLOk0t45tGtp
q6QA==
X-Received: by 10.152.28.131 with SMTP id b3mr34529959lah.12.1416312378552;
Tue, 18 Nov 2014 04:06:18 -0800 (PST)
MIME-Version: 1.0
References: <20140823115321.AC158E07036@quidecco.de>
<CANEZrP2rLUW2-SZXjEKMvgZVjjHwz-4TEHJoAaMd5=1N8R3G3Q@mail.gmail.com>
<20141113225243.9DDF37C8853@quidecco.de>
From: Mike Hearn <mike@plan99.net>
Date: Tue, 18 Nov 2014 12:06:17 +0000
Message-ID: <CANEZrP31T6s4Rqy38XAPoZqsSTesCj71UqBMOiRM6pnqQ_mueA@mail.gmail.com>
To: Isidor Zeuner <cryptocurrencies@quidecco.de>
Content-Type: multipart/alternative; boundary=089e0160b7cc36fcab050820ec24
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
X-Headers-End: 1XqhY8-0005Fl-Tf
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: Tue, 18 Nov 2014 12:06:26 -0000
--089e0160b7cc36fcab050820ec24
Content-Type: text/plain; charset=UTF-8
DKIM is hardly a PoW; signing is cheap and gets cheaper all the time. I
used to work in the email business and big bulk mailers all spent far more
CPU time on other aspects of their business, the overhead of DKIM is
irrelevant.
PoW didn't work in the anti spam world because it (amongst other problems)
mixes up bulk mail and spam, which are not the same thing. Very common
conceptual error though.
> 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.
>
They don't? This is news to me. Humans always care. One of the surest ways
to hurt your online business is to have a slow website because lots of
users will give up rather than tolerate a few seconds of latency. At Google
we actually had formulas that could relate a change in web search latency
to revenue impact.
So humans very much care! I actually doubt that any reasonable mobile
wallet will use the new Tor support bitcoinj by default, for example,
because it imposes quite some startup cost when the downloaded consensus
isn't fresh, and slow startup is painful. It could be optimised but nobody
has done that. For long running desktop wallets where startup time can be
amortised over hours or days, I guess it makes more sense.
I agree that PoW tokens might make sense as a last resort if nodes can't
even put a connection at the bottom of a priority queue and you're right
that it may be a useful tool in a shared toolbox. However if we reach the
point where users are all being PoWd then we're already pretty hosed and
it's probably close to game over :(
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.
>
I think Tor is a separate issue. If an attacker wants to either force all
users off Tor, or force them via a handful of exits, then this attack is
quite detectable already and wallets could already decide to simply give up
on Tor at that point automatically. No PoW needed. Well, ideally, nodes
would disconnect a banned IP with some kind of notice saying why it was
banned, but that's a small improvement.
Still, users should be notified that something is unusual.
>
If we're talking mainstream success then users by and large do not care
about technical mumbo jumbo like peer to peer networks or Tor ("that's the
thing drug dealers and pedos use???"). They just want the damn thing to
work reliably. So notifying them is unhelpful - it's not actionable. They
would just see a message like
"The wizzle sprocket is kaput - keep working? YES NO"
and then everyone presses yes.
Stuff like Tor plays well in the crypto community but it's very hard to
actually switch on by default, because it needs to have absolutely no cost
at all, otherwise you'll just annoy the vast majority who don't want to pay
for very abstract and hard to quantify privacy benefits.
So I think it's worth considering the DoS problem and Tor somewhat
separately, even though they're related. The solution to a crafty
privacy-attacking DoS that tries to make exits useless is don't use Tor at
all. The solution to "the entire Bitcoin network is under attack" is much
harder. It's unclear to me we can ever solve it convincingly - banks don't
connect together using private networks in which anonymity is forbidden
because they're stupid. They do it because it solves DoS attacks in one
solid move and they feel it's worth the high cost.
--089e0160b7cc36fcab050820ec24
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div style=3D"line-height:19.7999992370605px">DKIM is hardly a PoW; signing=
is cheap and gets cheaper all the time. I used to work in the email busine=
ss and big bulk mailers all spent far more CPU time on other aspects of the=
ir business, the overhead of DKIM is irrelevant.</div><div style=3D"line-he=
ight:19.7999992370605px"><br></div><div style=3D"line-height:19.79999923706=
05px">PoW didn't work in the anti spam world because it (amongst other =
problems) mixes up bulk mail and spam, which are not the same thing. Very c=
ommon conceptual error though.</div><div style=3D"line-height:19.7999992370=
605px">=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex;line-height:19.7999992370605px">humans=
=C2=A0also don't care if their patience is put to the test by having to=
<br>wait until one Tor exit node is finally unbanned, or by waiting for<br>=
the connection PoW to finish because it temporarily got harder due to<br>an=
attack.<br></blockquote><div style=3D"line-height:19.7999992370605px"><br>=
</div><div style=3D"line-height:19.7999992370605px">They don't? This is=
news to me. Humans always care. One of the surest ways to hurt your online=
business is to have a slow website because lots of users will give up rath=
er than tolerate a few seconds of latency. At Google we actually had formul=
as that could relate a change in web search latency to revenue impact.=C2=
=A0</div><div style=3D"line-height:19.7999992370605px"><br></div><div style=
=3D"line-height:19.7999992370605px">So humans very much care! I actually do=
ubt that any reasonable mobile wallet will use the new Tor support bitcoinj=
by default, for example, because it imposes quite some startup cost when t=
he downloaded consensus isn't fresh, and slow startup is painful. It co=
uld be optimised but nobody has done that. For long running desktop wallets=
where startup time can be amortised over hours or days, I guess it makes m=
ore sense.</div><div style=3D"line-height:19.7999992370605px">=C2=A0</div><=
div style=3D"line-height:19.7999992370605px">I agree that PoW tokens might =
make sense as a last resort if nodes can't even put a connection at the=
bottom of a priority queue and you're right that it may be a useful to=
ol in a shared toolbox. However if we reach the point where users are all b=
eing PoWd then we're already pretty hosed and it's probably close t=
o game over :(</div><div style=3D"line-height:19.7999992370605px"><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);=
padding-left:1ex;line-height:19.7999992370605px">I'd say, better have a=
few Tor-based users realize that they<br>should look for a fixed update be=
cause their client has to do PoW for<br>connecting, rather than having all =
Tor-based users locked out.<br></blockquote><div style=3D"line-height:19.79=
99992370605px"><br></div><div style=3D"line-height:19.7999992370605px">I th=
ink Tor is a separate issue. If an attacker wants to either force all users=
off Tor, or force them via a handful of exits, then this attack is quite d=
etectable already and wallets could already decide to simply give up on Tor=
at that point automatically. No PoW needed. Well, ideally, nodes would dis=
connect a banned IP with some kind of notice saying why it was banned, but =
that's a small improvement.</div><div style=3D"line-height:19.799999237=
0605px"><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:=
rgb(204,204,204);padding-left:1ex;line-height:19.7999992370605px">Still, us=
ers should be notified that something is unusual.<br></blockquote><div styl=
e=3D"line-height:19.7999992370605px"><br></div><div style=3D"line-height:19=
.7999992370605px">If we're talking mainstream success then users by and=
large do not care about technical mumbo jumbo like peer to peer networks o=
r Tor ("that's the thing drug dealers and pedos use???"). The=
y just want the damn thing to work reliably. So notifying them is unhelpful=
- it's not actionable. They would just see a message like</div><div st=
yle=3D"line-height:19.7999992370605px"><br></div><div style=3D"line-height:=
19.7999992370605px">=C2=A0 =C2=A0"The wizzle sprocket is kaput - keep =
working? YES NO"</div><div style=3D"line-height:19.7999992370605px"><b=
r></div><div style=3D"line-height:19.7999992370605px">and then everyone pre=
sses yes.</div><div style=3D"line-height:19.7999992370605px"><br></div><div=
style=3D"line-height:19.7999992370605px">Stuff like Tor plays well in the =
crypto community but it's very hard to actually switch on by default, b=
ecause it needs to have absolutely no cost at all, otherwise you'll jus=
t annoy the vast majority who don't want to pay for very abstract and h=
ard to quantify privacy benefits.</div><div style=3D"line-height:19.7999992=
370605px"><br></div><div style=3D"line-height:19.7999992370605px">So I thin=
k it's worth considering the DoS problem and Tor somewhat separately, e=
ven though they're related. The solution to a crafty privacy-attacking =
DoS that tries to make exits useless is don't use Tor at all. The solut=
ion to "the entire Bitcoin network is under attack" is much harde=
r. It's unclear to me we can ever solve it convincingly - banks don'=
;t connect together using private networks in which anonymity is forbidden =
because they're stupid. They do it because it solves DoS attacks in one=
solid move and they feel it's worth the high cost.</div>
--089e0160b7cc36fcab050820ec24--
|
