public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Isidor Zeuner <cryptocurrencies@quidecco.de>
To: Mike Hearn <mike@plan99.net>
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)
Date: Sat, 23 Aug 2014 13:53:21 +0200 (CEST)	[thread overview]
Message-ID: <20140823115321.AC158E07036@quidecco.de> (raw)
In-Reply-To: <CANEZrP1RzLmSB74xdFZbePAE9nxjR-_hSCGQhNH81vRKSji2AQ@mail.gmail.com>

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



  parent reply	other threads:[~2014-08-23 11:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-18 16:46 [Bitcoin-development] Outbound connections rotation Ivan Pustogarov
2014-08-18 17:19 ` Jeff Garzik
2014-08-18 17:21 ` Gregory Maxwell
2014-08-18 17:27   ` Mike Hearn
2014-08-18 17:35   ` Pieter Wuille
     [not found]   ` <CAPg+sBgzEMAQ03GTE2j82+K2B+Dia6T0z14ZYWsBQ8z8QSVoLg@mail.gmail.com>
     [not found]     ` <CAAS2fgRT8OQzUkneKwpjD15aLZDivT=hgBMTB63EjN8RBrp+RQ@mail.gmail.com>
2014-08-18 18:13       ` [Bitcoin-development] Fwd: " Gregory Maxwell
2014-08-18 18:38         ` Wladimir
2014-08-18 18:37   ` [Bitcoin-development] " Ivan Pustogarov
2014-08-18 19:37     ` Gregory Maxwell
2014-08-18 20:33       ` Ivan Pustogarov
2014-08-18 20:43         ` Gregory Maxwell
2014-08-18 21:02           ` Ivan Pustogarov
2014-08-18 23:20             ` Gregory Maxwell
2014-08-20 12:59 ` [Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation) Isidor Zeuner
2014-08-20 14:41   ` Mike Hearn
2014-08-23 11:53   ` Isidor Zeuner [this message]
2014-08-23 13:03     ` Mike Hearn
2014-11-13 22:52     ` Isidor Zeuner
2014-11-18 12:06       ` Mike Hearn
2014-11-27  3:29   ` Isidor Zeuner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140823115321.AC158E07036@quidecco.de \
    --to=cryptocurrencies@quidecco.de \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=ivan.pustogarov@uni.lu \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox