Hacker News Reader

>With cryptocurrencies, PoW works because the "good guys" (miners) and the "bad guys" (double spenders) have equal access to computing power: If the difficulty increases, both can simply add more mining hardware and stay in the game. If the "bad guys" threaten to get an advantage, the system can always increase the difficulty without risking to lock out the "good guys".

No Bitcoin PoW works because of economics and game theory; it is rational if group of people invested a lot of resources into mining and building consensus that they will stick to that consensus in order to preserve their wealth.

Read what Satoshi said in the Incentive section of the Bitcoin Whitepaper: "If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth."

Unless the attacker's whole purpose is to destroy the value of Bitcoin because of some other non-economic reason, e.g. ideological reasons, national security, state self-preservation, ...

That's a pretty dogma but nothing more. Unfortunately, humans aren't rational in the homo oeconomicus sense. There are all kinds of motivations a person or an organisation could have to manipulate the network that have nothing to do with making money.

I mean, even in the regular, non-crypto economy there are lots of products that are sold at a loss for strategic reasons.

But you're right, that explanation wasn't quite correct. My point was that cryptocurrencies rely on the assumption that all legitimate users taken together have more computing power than a typical malicious user. That assumption is supported by game theory and made use of with dynamic difficulty adjustment.

However for a PoW captcha, the assumption does not hold: The captcha has to be solvable by WASM on a smartphone, otherwise it would lock out legitimate users. And that is a pretty low bar for an attacker to meet, computation-wise.

> Correct me if I'm wrong, but wouldn't this keep the endpoint accessible for any bot/script that is willing to "invest the work"? E.g. if I only plan to query the endpoint a few times per day, the captcha won't be an obstacle.

Isn't this already the case with other captchas where you can pay people to solve them for you? You could easily build a programmatic solution for that. If you're willing to "invest the work", nothing can really stop people automatically.

If nothing can really stop people anyway, then what's the point of all this?

But I think the problem is that a PoW captcha can be cracked significantly more easily than a regular captcha:

For a regular captcha, a spammer would have to deal with brittle image analysis software or find people willing to do extremely boring, borderline illegal work for pennies.

For a PoW captcha, they have to load the page in Selenium and... that's it. All that's left is a slight bump in the power bill.

> If nothing can really stop people anyway, then what's the point of all this?

Barriers to entry. Different services will require different levels of security. This might be enough for a simple poll app.

But a barrier for whom?

If you're a script kiddy who knows how Selenium works, you can crack this.

What this does for resource-poor attackers is implement some wasteful form of rate-limiting. But then, why not just use actual rate-limiting?

> If nothing can really stop people anyway, then what's the point of all this?

It works, the thing is that "working" in that case is to increase the cost of doing this. Solving 1000 captchas costs $2 https://anti-captcha.com/.

The difference here is that people that have no money can automate selenium on their own computer and defeat a PoW captcha. But for people that have to pay for either servers or a captcha solving service, there is no difference.

surely if you "query the endpoint a few times per day" the captcha indeed shouldn't be an obstacle to that. I thought the idea is to prevent ddos and spam, and not to distinguish between an actual human and bot. like it shouldn't prevent non-harmful scripts like web scraping etc. as long as you don't overtax the servers.

No, the purpose of captchas has always been to distinguish bot users, no matter what kind of bot. If you don't mind bots but just want to protect against overuse, you can simply set up rate-limiting and be done.

I could be wrong, but wouldn't this system "front-load" rather than "back-load" the rate limiting? That is to say: if you rate limit requests globally, it affects all users if one user attempts to spam. On the other hand, this system slows each individual user down without affecting others directly.

Good point. I'm no expert, but I believe rate limiting systems typically use buckets that are partitioned by IP address or network segment or something similar. If there were just a single global bucket, an attacker could exploit the rate-limiter itself to cause a DoS, which is clearly not what the site wants.

But yeah, this seems like a way to archive something similar with potentially less complexity. (If you're willing to tolerate the wastefulness, which is still not cool in the age of climate change).

A challenge could be correctly invalidating a nonce. You don't want an attacker to reuse a previously solved puzzle for multiple requests - on the other hand, it's difficult to set up a good "time to live" for a nonce as you can't know in advance how much time a user would need to solve this nonce.

So I guess some global state to track recently "spent" nonces would be necessary.