Richard Clayton is a Cambridge computer security researcher who has written on spam, proof-of-work, hardware security modules, and censorship.
Commenters repeatedly cite his 2004 paper showing proof-of-work doesn't stop spam, and his work on key extraction from the IBM 4758.
There doesn't appear to be any discussion on your website or on GitHub about why, to be blunt, this is even a good idea in the first place.
A classic 2004 paper, "Proof-of-Work" Proves Not to Work [0], explained that the fundamental problem with proof-of-work bot filters is that attackers will always be able to solve the cryptographic puzzle faster than legitimate users. A touch of security-through-obscurity can help at the margins, but you chose Blake2b, which is used by cryptocurrencies like Zcash, Siacoin, and Nano [1], and as a result there are optimized GPU algorithms (first Google result [2]) and FPGA designs (one of the top Google results [3]). Have you run the numbers on any of those?
The closest to any discussion of these numbers that I saw was a mention on your website that it may take up to 20s on mobile; for comparison, the much-hated image CAPTCHA takes about 6-12s on average for native English speakers, and 7-14s for non-native speakers [4].
In another comment you bring up the idea of starting with a lower difficulty, and increasing it with repeated requests from the same IP address (IPv4, I assume). Unfortunately, access to unique IPv4 addresses is highly correlated with access to more compute power: laptops and desktops in developed countries are most likely to be in a household with a unique IPv4 address, whereas mobile devices on 4G internet and households in developing countries are more likely to be behind Carrier-Grade NAT [5], where thousands or…
Ben Laurie posted a link to this paper in response to Satoshi's posting his first version of Bitcoin[1], with this comment:
> Richard Clayton and I claim that PoW doesn't work:
> http://www.cl.cam.ac.uk/~rnc1/proofwork.pdf
It's in the context of a discussion about why PoW-based tokes are a bad idea in terms of burning CPUs and their carbon footprint. The generous interpretation is that he was claiming that this discussion was moot because the bigger issue was that PoW wouldn't actually work as a feature of Bitcoin.
The less generous (but probably accurate) interpretation is that he posted that without reading either the Bitcoin whitepaper itself or the abstract of the whitepaper. IIUC his paper is about how PoW applied to email would either break a lot of the desirable features or the difficulty would be too low to prevent spam.
I'm not sure why this bothers me enough to post about it on HN-- I'd actually prefer it to be true and Bitcoin fanbase never to have existed. Nevertheless, his paper wasn't really relevant to that discussion and I'm not sure why he posted it there.
1: https://www.mail-archive.com/cryptography@metzdowd.com/msg10225.html
Edit: clarification
In the UK, BT (The biggest ISP) introduced CleanFeed[0] and "strongly encouraged" (read forced) to be used by the government. It was claimed that it would only ever be used for blocking child sexual abuse imagery.
Recently a judge has ruled that BT must use the same system to block a website used to share links. [1]
The list of blacklist sites itself can only be edited by a small group (iirc 4 people) of unelected and unaccountable people at the IWF[2]
Cleanfeed is also pretty flawed, doesn't work with HTTPS, can be interrogated to get a list of blocked content (using TTLs) and misleadingly returns 404 for blocked content.
[0] http://en.wikipedia.org/wiki/Cleanfeed_%28content_blocking_system%29
[1] http://arstechnica.com/tech-policy/news/2011/07/british-telecom-ordered-to-blacklist-usenet-search-engine.ars
[2] http://www.iwf.org.uk/
[3] http://www.cl.cam.ac.uk/~rnc1/cleanfeed.pdf
There's this paper from 2004: "Proof-of-Work Proves Not to Work": https://www.cl.cam.ac.uk/~rnc1/proofwork.pdf
The conclusion back then was that it's impossible to make a threshold that is both low enough and high enough.
You need some other mechanism that can distinguish bad traffic from good (even if imperfectly), and then adjust the threshold based on it. See, for instance, "Proof of Work can Work": https://sites.cs.ucsb.edu/~rich/class/cs293b-cloud/papers/lui-pow.pdf
Customer requests are redirected by ISPs to the transparent proxy on an IP:port basis. DNS is not poisoned; using a different DNS will not affect how it works.
http://www.cl.cam.ac.uk/~rnc1/cleanfeed.pdf
I personally use a cheap VPS located in the US to get around IP geolocation (e.g. occasional Youtube videos, Hulu etc.), and it can also circumvent this, though I have never had cause to - my Be Pro account does not block filesonic.com, for example.
Sounds a bit like a simplified "Chaffing and Winnowing"[1], where the chaff identification is pre-shared through your custom compression parameters.
There was a HN story[2] on Chaffinch[2], which is where I came across teh idea.
[1] https://en.wikipedia.org/wiki/Chaffing_and_winnowing
[2] https://news.ycombinator.com/item?id=14408757
[3] https://www.cl.cam.ac.uk/~rnc1/Chaffinch.html#Chaffing