41–50 of 52 posts
Earlier quoted context omitted.
They were mining Monero, not Bitcoin.
CPU mining XMR is similarly not efficient compared to GPU
The idea was absurd from the outset. A few minutes of mobile CPU mining in a browser is a nearly worthless pittance.
This is a big question for me too! Especially since they didn't seem to have any major reason to burn a lot of cash or to run out of money! Was it maybe a lawsuit, fraud or regulatory issue? I would LOVE to know.
their own statement: The drop in hash rate (over 50%) after the last Monero hard fork hit us hard. So did the “crash“ of the crypto currency market with the value of XMR depreciating over 85% within a year. This and the announced hard fork and algorithm update of the Monero network on March 9 has lead us to the conclusion that we need to discontinue Coinhive. https://coinhive.com/blog/en/discontinuation-of-coinhive (…
Earlier quoted context omitted.
Hope this helps illustrate the point: That $250,000 every month amount was made at the cost of way more than $250,000 worth of electricity.
But it wasn't coinhive or coinhive's users who were paying for it. Website visitors carried the cost...
We wouldn't have as much web content as we do today if it weren't for web advertising. (Just another form of payment).
The idea was absurd from the outset. A few minutes of mobile CPU mining in a browser is a nearly worthless pittance.
A better strategy, then, would be to completely dissociate the idea from ads, and simply make it easy for content creators to ask users if they’d like to support their content via in-browser mining. Make it unobtrusive for viewers and both frictionless and highly configurable for creators. The goal should not be to maximize the number of viewers who consent, but to keep the potential loss in viewership and/or good will very close to zero. Let content creators decide how aggressively they want to pitch the idea to their viewers, with the default being about as aggressive as a small link off to the side soliciting donations.
The result would likely be an extremely high ratio of new widget installations to marginal unit of revenue, but it also wouldn’t totally crash and burn.
Earlier quoted context omitted.
There is no such thing as ASIC-proof. You can make an ASIC for any deterministic algorithm. "ASIC-resistance", in this context, only means that ASICs can be held to a low multiple of CPU/GPU efficiency. So ASICs can be 10x as efficient as a CPU/GPU, but not 10k-1m times as efficient like they can on something like SHA. Unfortunately, profit trends towards zero (towards cost of production) until prices change, so havi…
There is no such thing as ASIC-proof. You can make an ASIC for any deterministic algorithm. True. Although you could probably design an algorithm which requires so many of the capabilities of a CPU, like a fast 64-bit FPU and a lot of cache, that the transistor count of an ASIC would approach that of a general-purpose CPU produced in much greater volume. This would make special-purpose hardware not cost effective.
https://github.com/ifdefelse/ProgPOW
The problem is that you still are only taking an infinitely small chunk of the space of all possible Turing algorithms. For example we are not considering any program that lasts longer than say 12 cache hits and 20 math operations (proposed numbers). That means you don't need as much hardware to implement an ASIC as you would a general-purpose processor.
Such algorithms can never possibly contemplate the full space of Turing programs unless you solve the halting problem (because we can't trust participants to give us a fairly chosen algorithm, and presumably we don't want to select a hashing stage that never terminates). This approach will always consider a tiny, fixed area of the problem space and will thus always be amenable to acceleration from specialized hardware.
Remember that old chestnut, "anybody can come up with a crypto algorithm that they themselves cannot break"? You can add a corollary to that: "anyone can come up with a hashing algorithm that they themselves cannot design an ASIC for".
We've been through this over and over again. I remember when Ethereum was supposed to be impossible to accelerate with ASICs. I remember when Monero and ZCash were supposed to be impossible to accelerate. But when you put hundreds of millions of dollars of free money on the line, very smart people get creative.
The idea of ASIC resistance can be summarized as making specialized hardware no more efficient than general hardware. And that's simply an impossible task. Specialized hardware will always be at least somewhat more efficient than general hardware. Maybe not hugely, but it doesn't need to be hugely more efficient, 5-10x more efficient is more than enough to shift control over to ASIC insiders.
On top of that, ASICs pose massive advantages for deployment even apart from efficiency advantages. One box that you plug a power cable and ethernet cable into replaces two mining rigs with finicky, delicate riser cables and a dozen GPUs precariously strung from wire shelves. ASICs don't crash anywhere near as much either. Literally just having the same efficiency but being 10x as easy to deploy is still a massive win.
You can still rotate algorithms every 6 months, but the clock starts ticking when you propose an algorithm. It took four months from the last switchover before Monero had ASICs on the network again. Presumably they were designing as soon as the algorithm was proposed, and taping out as soon as the switchover was announced.
ASICs are inevitable, and it may be better to simply accept democratic control of ASICs rather than insiders with control of them. If you switch every couple months you disincentivize ASIC holders from releasing them to the public (and revealing their existence), instead they will hold them private so they don't trigger an algorithm change. Which is exactly the centralization that you're supposedly trying to avoid.
Spamming the adblockers to whitelist them (and their authedmine alternative) definitely didn't help https://github.com/easylist/easylist/issues/712
While I agree that they didn't handle it well, I'm mixed on this. While I think putting a miner on a site covertly is unethical, I also think blocking something that's not an ad in an ad-blocker is equally unethical. I think a miner like this could provide an interesting way for people to monetize their content, as long as it's opt-in, but blocking a non-ad like this just totally deflates the argument that ad-blocker…
> uBlock Origin is NOT an "ad blocker": it is a wide-spectrum blocker -- which happens to be able to function as a mere "ad blocker". The default behavior of uBlock Origin when newly installed is to block ads, trackers and malware sites
Any third party scripts tend to fall under "trackers" (stuff like typekit, disqus often gets blocked by default as well), something that just burns your CPU in the background without approval could be classified as malware.
I'm not sure how it's a perfect alternative. It seems worse on almost every dimension. You're stuck between running this miner covertly (scummy) or asking for permission (who is going to click yes?). How much of Coinhive's income comes from users who are unknowingly running the code? It seems like a move towards more user-hostility, not less. The one time I saw an actual fit for the end user was an online game that w…
I'm not sure how it's a perfect alternative. It seems worse on almost every dimension. You're stuck between running this miner covertly (scummy) or asking for permission (who is going to click yes?). How much of Coinhive's income comes from users who are unknowingly running the code? It seems like a move towards more user-hostility, not less. The one time I saw an actual fit for the end user was an online game that w…
Coinhive is now, for me at least, always associated with scammers.