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

We really appreciate everyone's enthusiasm

Unfortunately, bitp.it does not make us any money, and the resources we have are just completely maxed out. I should also mention again that while web mining is a fun concept, javascript really is far too slow to make a useful miner, at least until WebCL mining comes of age and sees more widespread adoption.

To put this in perspective, bitp.it has made less than 1 BTC so far, and at the expense of being constantly hammered by 750 requests per second. One of our users even seems to have us integrated with an ad service, but even so, the payout is small.

The landscape for web mining will change significantly when javascript can reasonably expect to have direct access the the visitor's graphics card pipeline. We will definitely reinvest our time and money in expanding the bitp.it service once that happens.

Until then, any miners out there interested in helping us beta test our new pool are invited to sign up: http://bitp.it/beta

We wil be sending invites in batches over the next few weeks, and would love everyone's feedback in these early stages.

So, I missed this in few hours 

Man, is there any chance you could accept me ? I have video site that gets around 5 millions UV annually and this would be fantastic, specially since those guys stay nice amount of time on the site while watching videos.

Please, please, please 

Hi guys, bitp.it is back up.

Unfortunately, we are basically at capacity, so we have to turn off new registrations.

Anyone who has an account can still log in, and web miners will continue to work.

Thanks for all your support!

Even though FeFe doesn't share my point of few on browser-mining (because it might drain the power from Laptops), I think we need to improve on the bitp.it client. Doing some hashing with the CPU doesn't work even with dedicated mining anymore. I believe that the only way to do some efficient mining would be using webGl hashing (there is no popup for it either) with a low or middle Aggression factor. We would at least get some MHashes/s per client. Check out http://www.youtube.com/watch?v=rfQ8rKGTVlg .

Best wishes,
Zyrkon

Hi all, we're taking the site offline for maintenance and upgrades - I'll let you know when it's operational again. Sorry for the inconvenience.

Yes, there is no harm in that.

can the script be on multiple pages on the same domain???

Yep. The console page will show statistics separately for each domain you put it on.

Hi. Can 1 script be used on multiple domains?

We're running on a single instance at the moment. At least for this web mining project, it would simply cost too much (i.e. more than $0) to scale to larger or multiple instances. We can handle a little more traffic... we recently adjusted the update interval to reduce the load some (if a miner finds a share though, it still submits it immediately).

I'm not sure what you mean by accepted shares - the shares we show you are accepted and part of a round on slush. Unlike an actual pool, however, we opted to only disburse BTC once a week, so your balance will only increase once a week on Saturdays. This is mostly because web mining as a whole is just too slow to justify real-time updates to balance.

The other ideas for features are definitely things we are planning to add, but at the moment we're pretty busy getting our own pool ready

http://bitp.it/beta

[/quote]
Do you you use the same server for all the getwork requests from the JS Clients as well? I thought you use the amazonaws cloud for everything? I hope the server can handle another view hundred constant workers i'm intending to throw at you
But before i do that...some more statistics would be nice. For example accepted shares, number of current clients for each page, overall hashrate of the javascript pool, a graph with workers/hash rate during the last day/s would be nice too(so you can see fluctuation), stuff like that...


questions over questions:

Just out of curiosity, what is the current global hash rate of the js-pool and how many clients did it need?

The current getwork response from your server is ~600byte. that traffic can be reduced to ~300byte by using gzip. Of course this would increase cpu usage on the server, but did you try & compare this yet? I did set up my own little pool and tested it with ~200 constant workers. there wasn't much of difference in the server performance, but the traffic reduced as described.

I also tested the patch mrb suggested here. I can confirm the speed increase by factor ~1.7. but i can't confirm the accuracy of the patch, i didn't go through the code or test it long enough to find a share. will you implement the patch?
there also is another JsMiner here that seems to have a better performance than the current sha256 implementation.  The miner itself is alpha version and doesn't have any work distribution whatsoever but the sha algorithm seems to be faster(at least it was on my desktop).

And last but not least....statistically....how many shares do you need on bitp.it to get a balance of 0.00000001BTC?
During the last 12h my visitors were constantly mining with +80 to 180 kHash/s and generated 2 shares. but it still shows me 0.00000000BTC. I know 2 shares isn't much at all compared to a classic pool but i wonder how many shares it will need to actually generate something with the jsMiner, so i can increase the number of workers i throw at your pool...

We had some server difficulties earlier... apparently a server with 128MB of memory *can* serve 750 requests per second... it's just not recommended

If you PM me your client id (found in the script), I'll get you registered.

just made my first share.....FUCK YEAH!
and it only took ~100 constant workers to achieve it

Ok, yes...javascript is slow. but a browser based miner will be pretty interesting in the future when webCL rolls out.

OR someone comes up with a fancy webGL hack for sha256.....anyone?

Besides visitors per day, your hashrate also depends on how long those visitors remain on the site and their average browser hashing speed. For that level of traffic, 0.15 khps is still a little low, but keep in mind it is *only* measuring the last hour, and so that rate will fluctuate throughout the day.

I got a website with 2000-3000 visitors/day.
My stats looks like this:
KHPS - Last Hour: 0.15

Isn't that very low?

Hmm,

visiting bitp.it with chromium directly leads to a 100% CPU load on one core.

Integrating the js code in my site and visiting it with chromium leads to a load of 5-30%

FF 3.6 produces 100% CPU load with the JS included on one core.

Unfortunately, 6k visitors a day is not enough to make a significant number of shares. Given average bounce time and hashrate for the visitors, it's the equivalent of having a single miner running all day at about 104 khps.

From my perspective (and keep in mind bitp.it was partially my idea ) the web mining experiment is on hold until WebCL or some other technology matures enough to increase the average browser's hashing capability.

But anybody who wants to mine for BTC and also stick with us (because we know you guys are awesome!) can sign up for the private beta of our upcoming pool!

http://bitp.it/beta

So anybody got some results with web mining? I`ve got web-site with 6k visitors daily, but I don`t want to risk and integrate script without statistic.

The jsMiner does not work any different (conceptually) than a CPU or GPU miner, just slower.

With that in mind, I will try and answer your specific points.

#1) Even with CPU/GPU miners, rarely is the entire nonce range checked. Unless you are close to the 1 GHash/sec mark, you are probably not running fast enough to check all the nonce range before your miner "times out" and gets more work. Shares can be found without completely the entire nonce range. In fact, a share could technically be found on the first nonce tried. The same applies to the jsMiner.

#2) The sum of your workers is really going to be what plays into the shares found. As you can see on our home page, your browser probably gets between 4,000 hashes/sec and 11,000 hash/sec (give or take). Lets just say 10Khash/sec for easy math. You would need 100 users on a website for 1 second (each getting 10Khash/sec) to equal 1Megahash.

#3) That would be called a stale share, where a getwork request is made from an old block, a share is found, but by the time it's submitted the block chain has moved on. Our miner, like all miners, checks for work frequently... so the probability for a stale share is no greater or worse. Unless you are talking about long polling, but thats a different discussion.

I hope I made sense of that. The essence of it is that small sites, and sites where visitors do not stay around very long, will not see a high hash rate. Even our top payouts have been a few bit pennies per week.

So are the following true?

• In order for the site owner to get any credit for work (not necessarily coins, but just acknowledgement of work), a given page viewer must remain on a page long enough for one "getwork" request to be complete.
• In order for the site owner to get any coins (or fractional coins), the total sum of all site visitors must spend enough time on site pages to complete enough "getwork" requests to complete a "share" of work.
• Completion of a share of work must be done within a "round" or an attempt by the pool to solve a block.

What I am trying to get at is an idea of is how much traffic a website would need in order to get any actual BitCoin credit. If the above are true, then small or low volume web sites would not have chance of earning any coins unless some sort of fractional share model is introduced.