The captcha is considered solved if the browser finds N nonces (with 0 < N ≤ 10) where a SHA-256 hash starts with 20 bits set to 0 in less than 5 minutes.
A nonce is valid on average every 2 * * 20 hashes computations, which is about 1 million hashes.
A modern GPU can compute several billion SHA-256 hashes per second.
---
Since this protection is uncommon, it will protect against spam, until someone creates a dedicated bot to bypass this captcha.
Also, I suspect phone users will have a hard time getting through. My phone took 30s to validate the captcha used in the demo, which has the N variable set to 2.
> My phone took 30s to validate the captcha used in the demo
I tried it on my phone as well and I thought it did not work, because the progress bar did not move. I didn't even notice there was a progress bar.
The idea is great, but I would not use it for my apps, because I would expect a heavy loss of conversions.
Isn't there a mathematical puzzle which cannot be optimizer by GPU usage so that desktop and phones are on par? Maybe something like scrypt which takes less computation and more ram? I guess ram is also a very sparse resource for bots, no?
Is it just me, or is the fact that Bitcoin uses almost half a percent of the world's electricity completely insane!? It's unfathomable! Half a percent of the sum total of human energy expenditure! Just for some pointless hashing!
There are solutions to that, I wouldn't go so far as to say it's not possible. But I don't advocate for it or think it's in any way going to happen either.
There is no relation between the hashrate and the amount of transactions being mined. So to answer your question: That depends on a few dynamics, mostly the price of electricity compared to the price of a bitcoin given an amount of inflation (the blockreward).
In some cases more onchain transactions does mean more rewards for miners, as transactions will need to outbid with more fees for blockspace. How this relates to hashrate depends on things like the ratio of the block reward vs the block fees.
But in the context of "what if the the whole world uses bitcoin", the vast majority of transactions will not be onchain. But instead will be transacted via other more efficient layers (sidechains - like Liquid, or level 2 - like lightning).
Maybe, but what makes it less profitable than the use of electricity for anything else? Miners probably have far more capacity to pay high amounts for electricity than, say, someone who just wants to light their home or keep their refrigerator running, no?
After 3 minutes, this just crashed the browser on an old AOSP stock Android device I have. The last time I implemented something like this as a proof-of-work (first party) solution, it fell apart instantly when someone wrote a dedicated bot for it - 5 zeroes were found in sub-0.5s times in non-browser-JS.
> It works by requiring your computer to solve complex mathematical equations in the background. It's a quick process for legitimate users, but is slow and expensive for spammers.
It took my computer 47 seconds and spun my CPU to 100% in the process. This is in Safari on a 2015 MacBook Pro.
Sorry to say it but this is a hilariously bad idea. It's a captcha except it somehow takes longer and won't actually keep bots out once it becomes widespread, while also doing the same thing as those bitcoin mining scripts except nobody is actually getting paid.
Still though, props to anyone who tries to come up with a way to kill captchas.
> Completely Automated Public Turing test to tell Computers and Humans Apart
The scheme presented here proves that a certain amount of hashing work was done, but doesn't prove that a human did that work. Oddly enough, no human can complete this task by hand.
This concept has been proposed by Dwork and Naor in 1992 to fight email spam. [0]
[0] Dwork, Cynthia, and Moni Naor. "Pricing via processing or combatting junk mail." Annual International Cryptology Conference. Springer, Berlin, Heidelberg, 1992.
Okay, so you do PoW in browser on CPUs - but that's likely much slower than a simple C implementation of the same algorithm and miles slower than a GPU, or worse, if it becomes really popular, dedicated ASIC.
Not to mention with the current parameters it barely works on mobile devices so in practice it'd have to be weakened even farther.
If your spam target has any decent value, this simply won't work. Spammers will pay milliseconds while regular users pay minutes.
You could at least try to make some money on this by solving work on a mining pool, but I just can't see it being a good general strategy.
With WebGL, a website can run a program (shader) on the GPU [1]. Whether that's a good idea is another issue, but it's already available on current browsers.
ASICs would be harder, but supposedly some PoW algorithms are harder to optimize that way.
Seems like an implementation of puzzle protocol. I love puzzle protocols and use it on all my servers with external client connections but this is hardly suitable for mobile users as they will have disproportionally lower computing power than desktop users, this is why I don’t use it on my websites.
Ihatecaptchas too. I hate the way they work better in Chrome rather than Firefox. I think it is disgusting that Google uses it to promote their browser like that.
Trouble is, I don't think this is a better solution.
You can set the difficulty to be as low as 2 to 5 seconds on average phone. Spammer will find easier place to go unless your site is really that attractive
On the "are you mining crypto" question, my thought was: Why aren't they? wehatecaptchas paid API sevice could be free if the math problem being solved was profitable...
It is not practical, but your comment is not 100% true. They can for example act like mining pool. They can let you mine X coin, but can accept less difficulty to bypass captcha. They may/may not win from spammers, but from regular users they can for sure.
It's insanely inefficient and the price of the electricity you're burning is much less than the value of the crypto. So you're costing your users money, and you're only capturing a small amount of that money.
But surely it's more efficient to mine crypto than the 0 BTC you are mining by generating SHA-256 hashes and then throwing them away. You could do exactly the same computational work, but use it to generate a tiny bit of income.
I mean, the usual downside of cryptojacking is burning your CPU unnecessarily. But if the whole point of your service is to burn some CPU cycles doing math, you might as well make money off it.
> How's this work? (detailed) We send your browser a unique string. It must be "solved" within 5 minutes. You browser is told to hash that unique string over and over, each time adding a new number. Your browser starts at 1 and counts up. Doing this until the outputted hash starts with 5 zeros (this is the solution to the captcha and is needed to submit the form).
It can easily do it, the point is that doing this makes it more expensive to spam your site. Let's say normally, it takes 1 second to post, now it might take 10 secs. Now you're spending 10x as much to post a comment or form, etc
Wouldn't it be more effective to throttle on the server side? You could have the server just artificially take 10 seconds to respond to the request and get the same effect.
But somebody can also do the proof of work from multiple hosts (or parallelized on the same host, e.g. with GPU computation). How does a proof-of-work in this case actually do more than just throttling the server's responses?
Okay, but that's kinda like saying eating healthy is good because you get to deprive oneself of donuts: that is, I feel like it's mixing up the cost and benefit. The point of the work is (from what I'm understanding here) to make it less feasible for bots to flood a server with requests, but doing the throttling server-side would have the exact same effect more consistently (i.e. in a way that's not easily evaded by GPU/FPGA/ASIC acceleration and doesn't punish normal users).
okay. I think my compute instances could handle that. the way I pay for them (heroku) usually results in underutilized resources which could accommodate this level of computation.
A lot of "bot protection" systems have javascript proof of work (like cloudflare) which is just laughable. It has come to the point where you have to add a delay on proof of work solution since your bot solves it much faster than an average user would.
The anti bot bullshit needs to stop. Put some verification or hard captchas around sentive pages like login but don't fucking blanket everything under recaptchas and proof of work nonsens - your website turns into hot garbage that no one enjoys using.
Here in SEA captchas and anti-bot protections pretty much ruin the web in PC bangs. reCaptcha is the fucking worst and renders the web completely unusable. If I go play some video-games I play more of "find that storefront" than a video-game that I came to play. Some places are wising up and installing bunch of browser extensions to prevent/solve captchas automatically but those don't work for program embedded captchas.
Can you do this asynchronously? It does take a long time, but I only noticed because I clicked on something and waited for something to happen. If you start PoW on page load (perhaps save success result in localstorage) then probably even 30 seconds of processing isn't bad at all.
I just tried it. I noticed the CPU on my i9 MBP went from 65C (idle) to 99C for at least 20 seconds. The fan turned on. It felt like it was mining bitcoins in my browser. I'm not sure I like this solution due to how long it takes and how many resources it consumes, wasting battery life.
I’ve tweaked difficulty to be easier. Start the difficulty off at 1 and increase when necessary. It should be faster now as a result. It also starts the process on page load now so it’s (hopefully) done by the time somebody is done filling out the form.
It didn't work three times, then I realised the button shaped green thing with high contrast under 'click here to blah' wasn't the actual button and the low contrast paragraph was the button.
There have been other analyses of recaptcha before, but it is an incredibly detailed, complex piece of software.
"Old school" captchas (i.e. have a human do something that is difficult for a computer) are getting more and more useless because there aren't many quick, easy tasks left that almost all humans can do that few computers can do, and they are vulnerable to mechanical turk farms.
So Google's approach now is basically they know so much about your average user (especially your average Chrome user) that it is very difficult for a bot to affordably "replicate" this user behavior over time. The downside is, of course, that Google knows so much about you.
Any proof-of-work scenario like this is pretty much doomed to fail, because is will be slowest on consumer devices (i.e. phones) and fastest on dedicated bot farms with rows of GPUs/ASICs designed to solve the problems.
