From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XK74Y-0001ly-B9 for bitcoin-development@lists.sourceforge.net; Wed, 20 Aug 2014 14:41:10 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.53 as permitted sender) client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f53.google.com; Received: from mail-oa0-f53.google.com ([209.85.219.53]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XK74W-0001yc-Ir for bitcoin-development@lists.sourceforge.net; Wed, 20 Aug 2014 14:41:10 +0000 Received: by mail-oa0-f53.google.com with SMTP id j17so6451999oag.40 for ; Wed, 20 Aug 2014 07:41:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.52.5 with SMTP id p5mr48841988oeo.55.1408545663172; Wed, 20 Aug 2014 07:41:03 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.97.132 with HTTP; Wed, 20 Aug 2014 07:41:03 -0700 (PDT) In-Reply-To: <20140820125901.CB71CE043A5@quidecco.de> References: <20140818164543.GB31175@localhost.localdomain> <20140820125901.CB71CE043A5@quidecco.de> Date: Wed, 20 Aug 2014 16:41:03 +0200 X-Google-Sender-Auth: MOx8mIeDmj6KGow_Un7LlkWIYOs Message-ID: From: Mike Hearn To: Isidor Zeuner Content-Type: multipart/alternative; boundary=001a11332c8ee746630501109728 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 X-Headers-End: 1XK74W-0001yc-Ir 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: Wed, 20 Aug 2014 14:41:10 -0000 --001a11332c8ee746630501109728 Content-Type: text/plain; charset=UTF-8 > > 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, 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 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. --001a11332c8ee746630501109728 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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,= 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 correct way to solve DoS is by having work prioriti= sation and queueing mechanisms, then finding ways to distinguish "good= " clients from "bad" clients. Doing this whilst preserving p= rivacy is hard. Long term the only way to solve it may be to require client= s to present some kind of cookie during resource exhaustion events that pro= ve they've been around for a while, thus allowing them to jump the queu= e.
--001a11332c8ee746630501109728--