<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Since when? This has been a recognized approach since people called it<br>

&quot;hashcash&quot; ([1] - before cryptocurrencies were even invented).<br></blockquote><div><br></div><div>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&#39;t work that great because bots have much more patience than humans do.</div>
<div><br></div><div>Other sites also use proofs of work, but they&#39;re CAPTCHAs i.e. human PoWs. And unfortunately those don&#39;t work very well these days either :(</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To be clear, I do not propose to have _all_ clients do complicated<br>
work. Just those using an address which has been misbehaving.</blockquote><div><br></div><div>Yes, I understand, but then you&#39;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&#39;t have to define some notion of misbehaviour, you just prioritise amongst clients. </div>
<div><br></div><div>The current notion of &quot;misbehaviour&quot; is only somewhat useful. It&#39;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&#39;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&#39;s very tricky to get this right.</div>
<div><br></div><div>That&#39;s important because one quite common way big sites suffer DoS attacks is by accidentally having real users create a DoS &quot;attack&quot; by e.g. pushing a bad software update, or by having sudden and unexpected press-driven growth, etc. You really don&#39;t want to force users to sit around waiting and wasting battery. It&#39;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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Exactly. Not every user may like to have a cookie by which an observer<br></blockquote></div>
might get the chance to even link his connection to his previous<br>
connections, thereby allowing the discussed deanonymization technique<br>
to get even more effective.<br></blockquote><div><br></div><div>I doubt it matters. Any DoS attack that&#39;s powerful enough to use up most of the networks resources is probably being driven by a botnet of some kind, and <u>all</u> legitimate users will lose in an even fight against a botnet.</div>
<div><br></div><div>Cookies can be somewhat anonymized. For example a cookie that is merely a signature over a timestamp of some kind (doesn&#39;t have to be an secp256k1 signature) can be normalised to the day or week. So you can prove you&#39;ve been using Bitcoin for say 3 years but it doesn&#39;t pin you down precisely.</div>
<div><br></div><div>This isn&#39;t perfect:  attackers can and do &quot;age&quot; accounts before preparing for abuse. Proof of UTXO is another way to rank users. If you&#39;re richer you&#39;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.</div>
</div></div></div>