Performance and bloat in browsers are a huge problem and having this constantly running in the background (without consent) is an absolute nightmare.
Two of the three ways I could see on the page to use it involve delaying the user slightly (while doing a proof of work) after a checkbox or link is clicked. Not constantly running in the background. The one that does constantly run requires clicking a play button, which seems "opt-in" to me.
They also have some revenue numbers on there. Though no details on the traffic other than it peeked at 2,000 simultaneous users so that's hard to quantify with the data.
One big question actually is if you use the captcha system, is it actually effective at proving you are human?
Also, the short link one is a little stealthy. But overall it only delayed my experience by a couple seconds so I probably wouldn't care unless it happened very often.
In what way is it better than your expectations?
(For me, it behaved as expected: immediately maxed my CPU load and spun up the fan)
As far as performance. It didn't do enough to spin up my fan. My CPU only went to 30% (inclusive of all the other apps I have running (using Chrome on OS X).
I was under the impression most browser limit how much CPU the Javascript thread can use because of the good old days when writing a tight infinitely loop in Javascript could freeze someone's computer.
Why not just build a system that allows customers to buy and sell CPU resources, in a similar way to how a ad network allows customers to buy and sell ads?
Any estimtes?
Coinhive says their formula is:
(<solved_hashes>/<global_difficulty>) * <block_reward> * 0.7
and then goes on to give an example of:
(<solved_hashes>/29275633095) * 6.51 XMR * 0.7 = 0.000156 XMR per 1M hashes
Does this mean the original formula (XMR gain) is actually per million solved hashes (instead of per solved hash)? If so, it seems like a million hashes would only give you 0.0000000001556584613 XMR ($0.00000001519798996).
If that payout formula is actually per hash (and if so, why do they say "per million hashes" in the example?), you'd end up with a much more reasonable 0.0001556584613 XMR ($0.015 at $97.64-monero).
Am I just reading their site stupidly wrong (and/or do I just have a gross misunderstanding of how this all works)?
I will report back in a few days
1. How is this attempt different from HashCash, aside from using Monero?
2. What are you going to do if and when people develop counter strategies to bypass having to do the work?
I've never heard of either service, so I checked out both. One big difference between the two is that I knew pretty quickly what Coinhive was and how to use it, but I could never figure out what the heck HashCash does. I suspect if I clicked on one of their many "buy access to the API" links I may get more info, but that's not very cool.
But having an equivalent using GPU in application like games may be profitable.
>If true, the miner will always use the asm.js implementation of the hashing algorithm. If false, the miner will use the faster WebAssembly version if supported and otherwise fall back to asm.js. The default is false.
Use of Monero (XMR) is an interesting choice. Monero is quickly being adopted as the coin of choice on dark net markets due to its builtin anonymity features. But dedicated third party-services such as escrow, multi-sig, etc have not kept pace with user demand. There seems to be an open window of opportunity for Monero centric contracts and payments.
This is definitely an interesting POC and makes an interesting case for why XMR might be ideally suited technically for web microtransactions. With the obvious caveats about hijacking browser performance being opt-in only that others have pointed out of course. Keep going!
I wonder if you can change the hash rate to something more understandable, such as USD/hr?
coin-hive/Monero would solve a lot of issues with simple MD5/SHA1 implementations like mine (like bot GPU's blowing through any kind of hashcash challenge).
Definitely a no-no for computers older than 3 years.
www.thoughtsandprayers.io
The issue I see with it, mobile (I tried) is around 10x less. So while it works for desktop, for mobile it would be challenging to use this, on top of draining battery etc.
However, this is probably one of the rare unique ideas how to monetize users presence on the site, and as such I welcome it and look forward to see how it will develop.
In Chrome I didn't notice that tab being out of focus decreases load, so it would work for as long as the site is open.
At the current exchange rate, that's about $3.78/month.
This is also the direction I wanted to see BAT to go in- getting rid of paywalls and ads in exchange for a basic return to the publisher and user based on duration spent on the site along with interaction.
