From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XL9tT-0007lb-Ex for bitcoin-development@lists.sourceforge.net; Sat, 23 Aug 2014 11:54:03 +0000 X-ACL-Warn: Received: from [81.169.136.15] (helo=quidecco.de) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1XL9tE-0003zQ-7J for bitcoin-development@lists.sourceforge.net; Sat, 23 Aug 2014 11:54:03 +0000 Received: from localhost (localhost [127.0.0.1]) by quidecco.de (Postfix) with SMTP id AC158E07036; Sat, 23 Aug 2014 13:53:21 +0200 (CEST) From: Isidor Zeuner To: Mike Hearn Content-Type: text/plain; charset=UTF-8; format=flowed References: <20140820125901.CB71CE043A5@quidecco.de> In-Reply-To: Message-Id: <20140823115321.AC158E07036@quidecco.de> Date: Sat, 23 Aug 2014 13:53:21 +0200 (CEST) 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 RDNS_NONE Delivered to internal network by a host with no rDNS X-Headers-End: 1XL9tE-0003zQ-7J 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: Sat, 23 Aug 2014 11:54:03 -0000 Hi Mike, thanks for your assessment. Please find my replies in-line: > > > > 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, Since when? This has been a recognized approach since people called it "hashcash" ([1] - before cryptocurrencies were even invented). I hear your concerns, but even then, I would see the PoW-based approach as an improvement to today's situations. To be clear, I do not propose to have _all_ clients do complicated work. Just those using an address which has been misbehaving. Right now, they cannot connect at all, no matter how much resources they dedicate towards doing so. > 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 way I had it in mind, well-behaved clients on an address used by attackers would have more effort to connect because of the PoW, but after that, they can stay connected. The attacker also has to put more effort into connecting, and after sending malformed messages, gets disconnected. So, the attacker would have to perform much more PoW computations in order to keep up his attack. > 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. > 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. Maybe having both options would be even better: In case of an attack, those able to solve the anti-DoS PoW can still connect (just maybe slower). Those who wish to run a weak client can choose to sacrifice privacy for connectivity and keep a cookie for connecting. Best regards, Isidor [1] http://www.hashcash.org/papers/hashcash.pdf