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

I just wanted to alert everyone...

I was skeptical that this did what it said it did, so I ended up doing a wire inspection of things that were sent to and from the server.

The good news is that it does indeed attempt to mine, but the bad news is that it doesn't actually work.

GET requests are issued to the server periodically to grab data needed for mining, and the hashes do appear to get computed, but the computed hashes are never POST'ed back to the server. I also checked the request headers and cookies, but the computed data is not in those either.

I'm sure this is just a bug, but right now this bitcoin miner is useless.

I do like your thinking. On a semi-related note, I notice this website: http://www.v2ex.com/bitcoin/mining.html

Google translate would seem to indicate that this is a page that the author specifically created for bitp.it. The text on the page fully describes whats going on, and invites the visitor to leave their browser open to help support the site.

I cannot help but believe that this is a great use for bitp.it. I love how they are tying it into the visitor's goodwill to help them support the site.

This idea, if implemented seriously, might have a non-negligible impact on global warming.

Thats actually a *really* good idea.

Facebook games, like Farmville, are based on a "fremium" model. They are very much dependent on less than 1% of their users supporting their operations. What if, all users gave something? Perhaps paying users could disable this?

Oh sweet....

Pandora radio... Perfect model. You pay that $30 bucks a year for their Pandora one... but if you don't, they run bitcoins off your machine while you listen to free music. 

check https://projects.forum.nokia.com/webcl for browser OpenCL implementation. This should be fun.

Just a quick update...

We changed the default script that is generate for you to have the forceUIThread parameter set to true. This will force the script to be very, very, nice. You can still overwrite that setting by explicitly setting it to false, doing so will increase your hash rate at the risk of higher CPU usage for your website visitors.

As promised, here is a complete list of parameters that can be passed into the engine:

• clientId
• delay
• forceUIThread
• autoStart
• workerTimeout

clientId - this is your unique identifier. Do not change, unless of course you want your shares going to someone else 
delay - this is the delay, in milliseconds that the UI thread waits between every 100 hashes. This setting does not control web workers. Lowering this value too much could result in browsers displaying the "we've detecting that this script has locked up" warnings. The default is 30 ms.
forceUIThread - some browsers don't support web workers (IE), in those cases this setting is meaningless. For browser that support web workers, this forces them *not* to use them, and instead calculate hashes in the UI thread at a much slower, and less CPU intensive, rate.
autoStart - don't use this yet. Right now the jsMiner auto starts. You could set it to false. However, since the jsMiner is running in an iframe you would have no way of starting it... we will work on getting this better exposed.
workerTimeout - this effects all browsers. This is the length of time (in seconds) that a get work request is good for. The default is 30 seconds. Increasing this value decreases network request but increases the likelihood of stale shares.

And example of what you're modified script tag would look like with some of these parameters is:

I've tried the code on one of my sites for a short time but decided to remove it for now. Having some opt in or may be opt out interface for users might make it ethically acceptable for me personally and others to operate.

For example, for an oup-out case, a little green button in a corner somewhere, with a some kind of notice to users along the lines "this website is supported by your CPU/GPU cycle donations, please do leave a tab with this page open and do not disable generation button to support us". Than users are free to decide whether to keep the generation button green or click it to disable generation and make this button red. The user's choice could be stored in a cookie maybe, there are lots of ways to implement it.

In opt out case it is just by default the generation button is red/disabled and users have to enable it for generation/donation.

Those are some good tips. I've been thinking about the idea of some opt-out cookie or something.... maybe if you visit bitp.it and opt-out, you will never be subject to this scripts execution...

I am not sure on the details, but it did cross my mind. I think you're on to something... it's got me thinking.


The GPU comment idea is great in theory, but right now WebCL is only supported by 1 plugin for 1 browser, and that plugin *just* came out at the beginning of this month. I'm not saying it's a lost cause, but even if that code was in our script today to use it.... generally speaking, it *wouldn't* be used as practically nobody would have the required plugin, at least speaking on "Internet scale". However, yes, the future of keeping this practical will be in WebCL.



Agreed.

And, one thing I keep thinking too, is that traditional ads depend on user clicks. I cannot tell you how many times I leave tabs open on my web browser for days, or even weeks, at a time. That could ad up quick.

Lol.... Sorry, I got a chuckle out of that one 

This IS using that "HTML 5 future stuff" 

Either way, we seem to have steered up quite the conversations on the Internet at large. I just got done reading over at ycombinator, and it looks like we've stirred up a hornest nest of discussions.

Makes me think of Flash based ads. Always thought about them as unethical and theft of both CPU power and traffic

However, one doesn't have to activate JS and one doesn't have to visit such web pages.

It is very inefficient anyway, so I don't think there would be a lot of people using a JS based miner on their web pages. Yeah, maybe with the HTML5 stuff coming along, but that's just talk about the unpredictable future. On the other hand that's what BC is all about and most of us would be rich if I had predicted how BC evolved.

Sneaking in electricity burning code as currently proposed, without customer (website visitor) consent, appears to be at least unethical and at worst an act of theft.

I see one way to turn this into a viable biz plan.

1. Develop emeddable js code to run calculations on user's GPU, where available.
2. Implement an opt-in button which could be placed on a website and enable users to turn on and off mining for this specific website.

Website operators could than try to persuade users to donate their GPU cycles voluntary and click such 'donate GPU time' button.

This can take some market share from ad networks like adsense and could be particularly useful for sites which are not considered by mainstream ad networks as 'good enough' i.e. bittorent trackers etc...

CPU mining (even if this were compiled code) is definitely inefficient. We're eager to see what advances in HTML5 can bring to the table, namely web-based CL.

Having a "Start Mining" button is a good idea. We've also considered a small embedded real-time chart of browser hashing speed, or something else to let the client know what their browser is up to.

I think a good solution would be to have a "Start Mining" button on sites, so users wouldn't be wondering why they're at 100% CPU.
Currently CPU mining isn't worth it because of the inefficiency.

Thanks for all the info.  I'm a web geek myself.  While I haven't had the chance to play with any HTML5 stuff yet I really like your project.  I emebeded the code in my site and just wanted to see what it running on my site was producing.  Also as someone else mentioned above They calculated their per day stat.  I left my page open all day on my laptop and just wanted to play around with it.

Yes, that is true too... we are planning on open sourcing the client side bits 

The js code on bitp.it is slightly different than what you should be putting on your site. This mainly due to the fact that we wanted to shows stats on the home page, and needed direct access to the jsMiner engine... the code we distribute for your website actually generates an iframe and runs the miner through that, due to cross domain permissions in web browsers, it was the only way to get the WebWorkers to work... apparently, despite HTML 5 specing CORS (which we use), the HTML 5 spec for WebWorkers specifically says that no cross domain permissions are allowed for web worker sources 

Because you are attempting to run the code without the iframe, on a domain other than bitp.it, your browser is denying your page permissions to new up a Worker() with a bitp.it source domain. For a little experiment, though, you could try using the forceUIThread: true param when newing up jsMiner... that will force the miner to use a non-web worker version of it's routines, and thusly work around the above mentioned shortcoming of web workers... however, it will lower your hash rate... so it was more of a experiment than something we necessarily recommend.

Now that we've got a control panel out there, at least in a rough draft, we are going to work on improving it. We'd love to show you your hash rate there. Also, we plan on exposing jsMiner stats through the iframe back to the calling page. Both of these should correctly take care things.

Just out of curiosity, and also so I can better understand how to write the code... what were you planning on doing with the hash rate? at the jsMiner level, that is a per web browser state, just FYI.

We plan to open-source the client-side code soon (so basically just un-minify it  ), which should make it a lot easier to experiment with.

I'm really liking this idea of a JS miner.  I was wondering how do you find your stats?  I tried implementing this on my site and "borrowed" you js miner code to display the hashes, but it seems like it's always 0.  I can send you a link to the site or my id if it help debug anything.

Using Chrome 11 on Windows 7

simply amazing, thank you for this!