Topic: Embedable Javascript Bitcoin miner for your website - page 12. (Read 149641 times)

That's kind of obvious isn't it? since it's using cpu, hence the cpu gets warmer which leads to more RPM cycles?

This is awesome! I've added the code to http://randomgam.es to try out.

First impression (on a relatively new MB pro) is that the machine's fans are going nuts when leaving the page open for a while... (this is the case in both firefox and chrome). Anyone else experiencing this?

You could easily hide it from bots with a few lines of PHP.

I just have to say that this is pure brilliance!

This changes everything. How long before we no longer can browse the Internet without CPU spiking to 100%?   

This is really powerful.

A question: is the mining task correctly prioritized not to annoy the user (lower priority than anything else)?
The CPU going to 100% won't be a problem if the user continues to be able to use his computer normally. But if the mining process has the same priority as other user processes, that might piss him off, with reason.
I don't even know if you can set priorities in javascript like that.

Great idea, I will support this in any way I can.

I'm working on a gaming website which allows players to compete in sit-down tournaments for BTC and this would be perfect to include on that. You should also look into using accessing the GPU for the calcs.
Maybe something like WebCL: http://webcl.nokiaresearch.com/index.html

If you can get this working it's be awesome.

I've embedded it on my website, should receive about 10k hits a day. it would definitely be cool to get those registration emails out there so I can see stats, this is a great idea.

Thanks for helping identify the issue. It turns out that the way we were passing parameters into the iframe was not cross domain compliant for all browsers. We've instead resorted to passing them via the iframe's src URL as query strings. Nothing will change on your end, except the code will just start working

This also should all you to specify more custom jsMiner engine settings. I will work on getting that list together of what can be tweaked and post back up. For one you can specify the forceUIThread: true in your params... so your code might look like:

Forcing the UI thread will limit the CPU usage by causing the miner to be more friendly for browsers that do not support HTML 5 WebWorkers... I added it as more of a debugging setting, but there is no harm in forcing all your visitors miners to be more friendly (except a lower hash rate).

There are more settings, but I will need to dig into that part of the source and make a list of what all they do.


As far as getting info out of the miner... that might not be an easy thing. I will need to ponder on that some more. The complication is that the miner, due to cross domain issues, lives in an iframe. Your website will not be able to just talk directly to that JS object... we could pass info back by modifying the iframe src URL (similar to what we are doing to pass info in), but unlike inbound parameters, if we used hash tags that should work...

It is embedded on my own website all of the aforementioned browsers work fine when testing directly on bitp.it using Windows 7; I have also additionally tested it using Firefox Nightly 6a on an Ubuntu 11.04 machine and it is returning the same permission error.

Code block copied verbatim from the submit page:


Not a problem, I'm used to dealing with users who don't even understand how to use their Windows PC properly so I know your pain exactly  .

Edit: While testing this I have noticed what could be a fatal issue for some people (myself included), if you have two pages of the same website open in two separate tabs it causes the script to execute twice and runs the systems CPU up to the point where (In my case anyway) the computer became very unresponsive. Scratch that it seems fine between Firefox 4 tabs, the issue that actually caused my PC to freeze was having Chrome and Firefox both independently running a copy of the script.

I have also setup a completely stripped page on my website to demonstrate the permission issue away from the gunk of the SMF install, here.

Also another suggestion (I know, I'm a pain right?) perhaps give the webmaster more direct access the the jsMiner "engine" object so that we can easily pull information such as the hash rate?

Ok... call me silly... but I just loaded bitp.it in Firefox 4.0.1 on my Mac, and it appears to be working just fine.

Judging from the IE 9 bug, is it safe to assume you're on Windows for Firefox too? I will boot up a VM and try it there as well.

Also, when you encountered this, were you hitting bitp.it directly, or were you trying to embed this onto your own website?

Sorry, I am just trying to reproduce this so I can fix it 

Thanks for the input. A control panel is in the works... but it means a lot more to us to hear specifics on what you guys are looking for. Specifics like you just listed help us a *lot*.


Keep the ideas coming. 

Thanks, a lot. The encouragement means a lot. I agree, a lot of users and website operators may not like the idea that the CPU is worked so hard on some browsers. The underlying jsMiner engine supports an option of forcing the work to be done in the UI thread, and thusly in setTimeouts... this is VERY CPU friendly. If you compare the CPU usage that IE produces on bip.it versus Chrome you will see that IE appears to use very little CPU time where Chrome uses a whole core... this is the different between IE using the UI thread and Chrome using an HTML WebWorker.

Either way, I just made a feature request in our project tracker to get these underlying jsMiner settings exposed so that the end website operator can better tune their user's experience.


The typical "getwork" protocol that nearly every miner uses is very poor. The protocol hands a chunk of work to the client and says "here, go".. and the client just tries to go over the whole nonce range. This is a poor design for slower clients. We wrote a more RESTful protocol for fetching work, and in this protocol we also took the liberty of having the server tell the client which nonce ranges to loop over. This allows a server to better coordinate a hash search when it knows it has slower clients. This also eliminates the need for state as, by default, the browsers are only given enough work for about 30 seconds and will POST back their results immediately if a share is found.

I see one BIG flaw on this system... google its gona kill you.

They gona mark the web page as a "malware".

I'm probably about to show my ignorance of bitcoind and Javascript/HTML5 in a couple of lines (I'm a Java/C programmer and tend to ignore Javascript wholesale) but here I go.

Is it possible to push smaller work units than the default (most cpu's seem to do about 1 share per minute from my experience) in order to reduce the amount of time required on each page, or are the share sizes a hard coded part of bitcoind/rpc? Or perhaps is it possible to have the miner store its state in HTML 5's cache in some way, so that it can be resumed on subsequent pages? Or maybe make use of a cookie to store the state information which is then reread on the new page?


My intention is to only have it run for guests to the site, the person can choose to not enable it by simply registering with the website - fair trade off in my eyes.

Edit: I'd like to make a request, I'm sure its already on the cards but I'll ask anyway, within the control panel it would be nice to see some information such as effective total hash rates, number of users currently hashing and such and perhaps some distinction between the pages which it is being run from (or some ability to set of "campaigns") so that we can see which pages on our websites are proving more or less effective that generating coins.

This is freakingly awesome idea!

It surely will help to better distribute the overall hashing power, thus making the bitcoin network even more resilient.


I'm not sure the client will be very happy to see his computer burning CPU for  no apparent reason, though.     But indeed it is probably better than annoying ads.   Again:  awesome idea.

Thanks for the bug report... I will get right on this. The Firefox issue I have a very good idea what that is about. That kinda ties back to the comment I made about, about exposing our miner engine settings better.... it looks like the way we are passing params into the iframe is not liked by Firefox 4.

I will look into the IE one as well, it may be one and the same.

You are right, one pages where people on only there for a brief instant, this would be less than ideal. This is really good for websites like blogs, newspapers, forums, etc, where people sit and read content for a few minutes at a time. That is not to say that it wouldn't work on any site, but I think you catch my drift.... the long someone just sits on your website, the better it is for you, the website operator.

I think I might have run into an issue with the API?

I have placed the code into the head location on my website and it works fine in Chrome V11, however when I attempt to load it in Firefox 4.0.1 it throws the following


and Internet Explorer 9


But on a side note, great idea, although one question how well does it handle people moving between pages because the rate at which shares are generated with CPU hash rates is surely going to be pretty low?

Thanks for registering. Our hosting provided (for some reason) is blocking outbound SMTP connections. We have an open support ticket with them trying to get this resolved.

Your Javascript should be fully functional though. The email will be used to help you set your password when we bring the user control panel online in the next couple of days. In the mean time, any shares generated with your custom Javascript will be tired to your account. When the control panel comes online this should all be a little more transparent.

It will even run on your smart phone too 


Oh, and, just for note, the backend is actually written on node.js

These are exactly the type of discussions we wanted to generate. In regards to open source, let me discuss with my partners. This is something we only briefly discussed and I am not sure where we ended that conversation.

We intentionally avoided using jQuery, prototype, or any other frameworks as we wanted this to not interfere with anyone's website. We also make use of "namespaces" (well, as much as JS can :-D) to also reduce the change of doing anything bad to any of your existing JS.

We would be honored to have you test it out on your site, I will send you a PM shortly in case you wanted to discuss in any more details.

As far as the CPU...

Chrome, Safari, and Firefox have support for HTML 5 WebWorkers. In those browsers the JS defaults to using 100% of one core. Since this is a WebWorker, it has no ill effect on the web page. In IE (or any other browser without support of WebWorkers) hashes are computed in the UI thread using a setTimeout that makes it VERY CPU friendly. There are settings in our code to force even Chrome, Safari, et al to use the UI thread and be equally as friendly as IE. A recent change today made those settings less obvious. I will work on getting those exposed better, and will report back.