From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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> <20141113225243.9DDF37C8853@quidecco.de> From: Mike Hearn Date: Tue, 18 Nov 2014 12:06:17 +0000 Message-ID: To: Isidor Zeuner 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 , Ivan Pustogarov 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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.

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.
=C2=A0
humans= =C2=A0also 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 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

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.
=C2=A0
<= 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 :(

I'd say, better have a= few Tor-based users realize that they
should look for a fixed update be= cause their client has to do PoW for
connecting, rather than having all = Tor-based users locked out.

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.

Still, us= ers 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 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

=C2=A0 =C2=A0"The wizzle sprocket is kaput - keep = working? YES NO"
and then everyone pre= sses yes.

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.

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.
--089e0160b7cc36fcab050820ec24--