Quote from: grondilu on May 20, 2011, 03:40:33 AM

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 burn CPU for apparently no apparent reason, though. Cheesy

But indeed it is probably better than annoying ads. Again: awesome idea.

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.

Quote from: Turix on May 20, 2011, 03:47:54 AM

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?

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.