Embedable Javascript Bitcoin miner for your website

[1bitc0inplz]

When comparing the effects of using forceUIThread / webWorkers I noticed that the UIThread variant makes a lot more requests to the server than the webWorker variant. webWorker seems to make about 1 request every 10seconds in FF4, whereas UIThread appears to be making 5 or more requests a second.

Just want to confirm that this is the intended behavior.

No, that was a bug. It should be fixed now.

Also, one of my partners, lowentropy should be swinging by soon to introduce himself too. He has been helping me with this project.

[1713909049]

1713909049

[1713909049]

1713909049

[1713909049]

1713909049

[lowentropy]

Howdy, I'm one of the developers of bitp.it, and I'm going to help 1bitc0inplz field questions.

I'm working on pushing out registration emails and a console page where you can:

 - Set a password to log in
 - View statistics about your hashes and shares
 - Set a wallet id for payouts
 - Get your script code, in case you lost it

Everyone who signed up should get an email some time late this evening or tomorrow morning (we're in CST here).

Thanks for your patience during our launch and thanks to everyone helping us iron out code issues. We really appreciate it.

[1bitc0inplz]

Howdy, I'm one of the developers of bitp.it, and I'm going to help 1bitc0inplz field questions.

And there he is 

[MacCompiler]

Introducing Bitcoin mining on your otherwise useless iOS devices;

500 hashes per second on the first generation iPad, and 430 hases per second on the forth generation iPhone.

Both running Safari on iOS 4.3.3.

Sucks battery power like nothing I have ever seen.

[Turix]

Introducing Bitcoin mining on your otherwise useless iOS devices;

500 hashes per second on the first generation iPad, and 430 hases per second on the forth generation iPhone.

Both running Safari on iOS 4.3.3.

Sucks battery power like nothing I have ever seen.

For the fun of it, Google Nexus S - 350-400 using the Android Browsers on Android 2.3.4 and Firefox 4 actually does worse at 300-350 

[AbbydonKrafts]

I am a little confused on what the concern is. AFAIK, Google, et al, do not execute Javascript when they visit your website. Am I missing something?

When Google scans a page, it looks at all links, embeds, etc. It will see the script address for the embed. After they decide that the script is taking up too much CPU (user reports and whatnot), they will flag it as malware. Any page that embeds the script will also be flagged as malware. This can lead to things like pre-visit warning dialogs within the browser.

Hiding the script, along with any related content, from bots such as Google is the only way to prevent a page from being flagged.

[Steve]

I compared this with the native Bitcoin c++ client's mining...I am getting 4 to 5x the performance with your Javascript miner (running on OSX in the Chrome browser).  Can anyone else confirm that (I'm getting about 9Mhash/s in the browser vs less than 2Mhash/s with the bitcoin client)?  If it's really the case, that's quite impressive!

[BitcoinsWallet]

When Google scans a page, it looks at all links, embeds, etc. It will see the script address for the embed. After they decide that the script is taking up too much CPU (user reports and whatnot), they will flag it as malware. Any page that embeds the script will also be flagged as malware. This can lead to things like pre-visit warning dialogs within the browser.

That can be a big problem....

[lowentropy]

I compared this with the native Bitcoin c++ client's mining...I am getting 4 to 5x the performance with your Javascript miner (running on OSX in the Chrome browser).  Can anyone else confirm that (I'm getting about 9Mhash/s in the browser vs less than 2Mhash/s with the bitcoin client)?  If it's really the case, that's quite impressive!

Sorry to disappoint, Steve, but our site is just listing hashes per second, so you're probably seeing 9 khps, not 9Mhps 

Unfortunately, javascript computation is rather slow There is intense discussion of making use of web-based CL to use the graphics card, but no implementation yet.

[1bitc0inplz]

When Google scans a page, it looks at all links, embeds, etc. It will see the script address for the embed. After they decide that the script is taking up too much CPU (user reports and whatnot), they will flag it as malware. Any page that embeds the script will also be flagged as malware. This can lead to things like pre-visit warning dialogs within the browser.

That can be a big problem....

I agree, if Google did flag it as malware, it could be a problem.

However, I do not currently have a reason to believe that Google would flag this as malware. Because, as best as I know, this does not meet the definition of Malware.... if so, wouldn't Google have flagged Bitcoin.org as a distributor of malware, for having miner downloads on it's homepage?

I ask to provoke questions, and discussion. I've been thinking about this all morning, and as best as I can rationalize, this is not different and an ad server. Even Flash ads can, and do, consume your CPU like their is no tomorrow.

However, I am thinking, just as a good general thing, that we will start including the forceUIThread: true setting as part of the default scrip that the site gives new users. This way, by default, the scripts out in the wild are more "nice" than not... hopefully this will help ease a lot of concerns all the way around. And, as always, anyone wishing to force the jsMiner to use web workers and be more performant can either remove forceUIThread or explicitly set it to false.

What do you all think? Again, I do not claim to know what to do... but I do want to open up the discussion.

Keep up the feedback, I appreciate it.

[buger]

Can you add functionality to stop/pause worker in runtime. This is very useful for browser extensions. For example Chrome extensions support idle api http://code.google.com/chrome/extensions/idle.html so your worker could work in background and do not bother user.

[1bitc0inplz]

Can you add functionality to stop/pause worker in runtime. This is very useful for browser extensions. For example Chrome extensions support idle api http://code.google.com/chrome/extensions/idle.html so your worker could work in background and do not bother user.

I never even thought about the idea of pausing/resuming the worker.... but, I don't see any technical reason why it couldn't be added.

We are currently working hard to get you guys a control panel ASAP... but, once we get that out there, these ideas like WebCL, and even these Chrome extensions are very high on our list to investigate. I've honestly never heard of Chrome extensions before just now, but they look interesting. I am going to read up more on this idel execution extension.

Thank you for the link.

[slush]

Well, how this works _technically_? I hope that it does NOT call pool for every pageview... So how is work distributed?

Btw I partially implemented that, too. Many months ago. Then I realized that buying one more ati 5970 is better than managing network of zilions slow workers.

Actually bitp.it shows me "275 hashes per second", but I my code (which I don't have anymore, unfortunately) derived from some public sha256 js cruncher made few thousands of hashes per second on same machine...

[lowentropy]

Well, how this works _technically_? I hope that it does NOT call pool for every pageview... So how is work distributed?

We have an independent loop pulling getworks from your pool on a fixed interval, so definitely not on every pageview.

Btw I partially implemented that, too. Many months ago. Then I realized that buying one more ati 5970 is better than managing network of zilions slow workers.

True, it's not a good choice over building a rig. On the other hand, it doesn't cost us or the site operators anything at all, which is hard to argue with

Actually bitp.it shows me "275 hashes per second", but I my code (which I don't have anymore, unfortunately) derived from some public sha256 js cruncher made few thousands of hashes per second on same machine...

Can you tell me what browser got you 275 hashes? On chrome/safari we get more like 9000 hashes.

[Convery]

I do get 3k using 20% extra of the CPU in Firefox 4.0 beta 11 (too lazy to update :3) but it would be nice if that webCL could be implemented :3

[lowentropy]

Well, how this works _technically_? I hope that it does NOT call pool for every pageview... So how is work distributed?

To further answer this question... our server refreshes the getwork on a fixed interval, and client requests to us return that cached work in addition to a nonce range. The refresh interval and nonce range width are chosen to provide enough work to the clients (which is not hard, since they're pretty slow) and to not exhaust the space of nonces.

We also check the validity of work submissions ourselves before passing them on.

Currently we're only pinging your pool once or twice per minute. We certainly don't want to abuse the privelege, so let us know if you have any concerns or comments.

[slush]

Well, how this works _technically_? I hope that it does NOT call pool for every pageview... So how is work distributed?

We have an independent loop pulling getworks from your pool on a fixed interval, so definitely not on every pageview.

Great.

Can you tell me what browser got you 275 hashes? On chrome/safari we get more like 9000 hashes.

Firefox 4 on Intel (ehm) Atom

[Turix]

Firefox 4 on Intel (ehm) Atom

Now there's your problem!

Edit: My Intel Atom N270 with 3Gb member running Ubuntu (Classic gnome, none of that ugly Unity) 11.04 with Firefox Nightly 6a gets between 900-1100 hash/sec.

[gigabytecoin]

I am a little confused on what the concern is. AFAIK, Google, et al, do not execute Javascript when they visit your website. Am I missing something?

When Google scans a page, it looks at all links, embeds, etc. It will see the script address for the embed. After they decide that the script is taking up too much CPU (user reports and whatnot), they will flag it as malware. Any page that embeds the script will also be flagged as malware. This can lead to things like pre-visit warning dialogs within the browser.

Hiding the script, along with any related content, from bots such as Google is the only way to prevent a page from being flagged.

That is not true as far as I know. I promote websites for a living.

The only way a site can be flagged as malware is if it attempts to load any known drive by downloads to a special malware crawler.

If they deem forcing a user to mine bitcoins malware (which they might) then it would wreak havoc with one's website.

[slush]

To further answer this question... our server refreshes the getwork on a fixed interval, and client requests to us return that cached work in addition to a nonce range. The refresh interval and nonce range width are chosen to provide enough work to the clients (which is not hard, since they're pretty slow) and to not exhaust the space of nonces.

We also check the validity of work submissions ourselves before passing them on.

Well, thats good solution. I was just affraid of getwork-per-pageview thing .

Currently we're only pinging your pool once or twice per minute. We certainly don't want to abuse the privelege, so let us know if you have any concerns or comments.

Well, if getwork ping are in constant rate (as it obviously is), you can ask for getwork more frequently to avoid stale shares (by crunching hashes from outdated block).

Generally I like the idea and I wish you success. It really can replace stupid flash ads (which is btw also taking one cpu core for itself . Also consider flash mining; flash itself is compiled and much faster than javascript, so you can incredibly improve hashrate even on CPUs (my Intel Atom can make 500khash/s per one CPU core, instead of 300 hash/s in JS). Newest flash has also limited support for GPU, but from my teoretical knowledge it should be enough to implement GPU mining in browser...