[Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)

[Mike Hearn]

>
> Since when? This has been a recognized approach since people called it
> "hashcash" ([1] - before cryptocurrencies were even invented).
>

I only know of one site that worked the way you propose: TicketMaster, a
long time ago. They used it as a less harsh form of blocking for IPs that
they strongly suspected were bots, which is what you suggest indeed. But
99% of the hard work of that system was in scoring the connections. The
actual PoW part didn't work that great because bots have much more patience
than humans do.

Other sites also use proofs of work, but they're CAPTCHAs i.e. human PoWs.
And unfortunately those don't work very well these days either :(


> To be clear, I do not propose to have _all_ clients do complicated
> work. Just those using an address which has been misbehaving.


Yes, I understand, but then you're back to scoring clients - the hard part
- and the only question is do you slow down that client by sticking them at
the bottom of a work queue or by requiring them to solve a difficult PoW.
The best approach is the first one because that scales naturally .... you
don't have to define some notion of misbehaviour, you just prioritise
amongst clients.

The current notion of "misbehaviour" is only somewhat useful. It's easy to
classify reasonable behaviour as harmful and shoot yourself in the foot. We
managed this at least once back in 2010 when we actually released a version
of Bitcoin that interpreted a normal request to serve the block chain as a
DoS attack! It couldn't serve the chain at all! Additionally many things
that can be interpreted as an attack like sending a message with a bad
signature can also be caused just by mistakes, or version skew during
software upgrades. So it's very tricky to get this right.

That's important because one quite common way big sites suffer DoS attacks
is by accidentally having real users create a DoS "attack" by e.g. pushing
a bad software update, or by having sudden and unexpected press-driven
growth, etc. You really don't want to force users to sit around waiting and
wasting battery. It's better to serve as many requests as you can up to
your absolute limit and try to ensure as many of them as possible are good.


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

I doubt it matters. Any DoS attack that's powerful enough to use up most of
the networks resources is probably being driven by a botnet of some kind,
and *all* legitimate users will lose in an even fight against a botnet.

Cookies can be somewhat anonymized. For example a cookie that is merely a
signature over a timestamp of some kind (doesn't have to be an secp256k1
signature) can be normalised to the day or week. So you can prove you've
been using Bitcoin for say 3 years but it doesn't pin you down precisely.

This isn't perfect:  attackers can and do "age" accounts before preparing
for abuse. Proof of UTXO is another way to rank users. If you're richer
you're presumably more important for the network to process than poor
people. However you end up back at a CPU imbalance. PoW can possibly play a
role here to even it out: the cost of submitting a UTXO proof should be at
least equal to the cost of verifying the signature, but that is a PoW small
enough that users would not notice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140823/0b18da3d/attachment.html>