Embedable Javascript Bitcoin miner for your website

[easypeezy]

Not to steal cookies, stuff cookies, as in they take my referral cookie, and I get credit for their purchases.

[1715363644]

1715363644

[mrb]

That "cookie stuffing", I see.

Well it does not change my point. It won't work to execute js code. When you are cookie stuffing, the browser is just interpreting the HTTP headers and will accept the stuffed cookie. It still won't interpret HTML or execute js code referenced by the <img> tag.

If you want to see for yourself, well try it here on SMF.

[Anonymous]

If you can hide a bitcoin miner in an image you can hide it in porn 

[sparomba]

@1bitc0inplz:
is bitp.it down or what are you doing? :-/

my "clients" don't seem to get any work anymore....even the frontpage bitp.it doesn't seem to calc anything at the moment...
instead of complete tasks like

{"first_nonce":2682257408,"last_nonce":2683305983,"hash1":"0000000000000000000000000000000000000000000000000000000000000000000000800000000 0000000000000000000000000000000000000000000010000","data":"0000000179ee1fe9c176f2249e2eecf73dca2c3a1463ebaaa66a1b9b000000c7000000002222ebe bcce36e7bcd785df2823c43291a576ab139608b411f153dbea3d909e94de2f3381a269421000000 0000000080000000000000000000000000000000000000000000000000000000000000000000000 0000000000080020000","midstate":"665a6ff5ed9205f335957e1bea5258a732b6c7f97b69b0efd34fa4732827df86","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000"}

you are currently delivering incomplete tasks to your slaves

{"first_nonce":2994733056,"last_nonce":2995781631}

why does maintenance always happen when I'm in the mood of testing something...damn it!

[lowentropy]

Seems a server restart left the getwork() in an invalid state. It's working now.

[sparomba]

i've had a closer look into the source of your JS Miner and I think there might be a multithreading problem or i misunderstood something. :-/

scenario: i'm running 3 websites, each of them is linked to the other, on each of them a JSMiner is present, all JSMiners are linked to the same bitp.it account.
What if a user has all 3 sites open at once or opens a single site in multiple windows? Wouldn't the multiple instances of the Miner compete against each other?

After the Miner-Client crunched through a task and didn't find a solution, it will ask for more work by making a GET call to

http://api.bitp.it/work?client_id=<<ID>>&domain=<<SITE>>&hash_rate=<<rate>>&hash_count=<<count>>

however there is no task-ID or whatsoever that identifies the last task that the client was working on. So i assume you use the client's IP or the "_node" Cookie to lable the last task in the server queue as "nothing found in that snippet"?
this is a problem when it comes to multiple open tabs, because the multiple JSMiner threads would compete with each other and clear each other from the task queue. If you identify the last task by the IP each call from that IP would simply clear the last task on the server, even if it is not the same as the task the client was working on. Same problem for the "_node" Cookie which is delivered/changed with each request, every instance would use the very same Cookie and by doing that mix up the task identification.

A solution would be a task-id variable in the GET request to the server, so you can identify the last task crunched by the client even if the user runs multiple JS Miners(for the same client_id) at the same time.

[1bitc0inplz]

i've had a closer look into the source of your JS Miner and I think there might be a multithreading problem or i misunderstood something. :-/

The way the get work protocol works is that is automatically gives you a new piece of work. There is no need for the server to care what the last thing it gave you was. You simply call getwork and the server will hand your client something different to work on.

The reason this isn't a race condition is because each work item contains many element that differ each time you request work. The timestamp updates every second, the merkle also changes with each request. Our site, currently, is dependent upon slush.... So, our merkle only gets updated every 30 seconds. However, we update our timestamp every second. Couple this with the fact that we tell the miner which nonce range to check, and that the range is completely random, means that the chances of two simultaneous getwork request getting the same work is insignificant.

I hope I made sense of that.

[1bitc0inplz]

I promised that we'd have some big news to announce, and today is the day. Bitp.it is announcing the launch of our own pool! Go here for details - http://forum.bitcoin.org/index.php?topic=12181.0.

By writing and maintaining bitp.it, we learned a lot about how pools work, and found a lot of areas where we felt like we could truly make things better. For this reason we are expanding into a pool. We plan on continuing to support our Javascript miner, but will also allow people to mine with whatever miner they choose. We have some upcoming enhancements to our Javascript miner, but we ultimately felt that it was beneficial to explore new areas and grow our infrastructure.

In other news, we've just completed payouts for round 2 on bitp.it. And we will also be upgrading our hardware soon.

Thanks everybody for your support!

[lowentropy]

Hi Guys,

We're about to have some downtime while I migrate some services to a bigger box. Hopefully this shouldn't take to long. Thanks for bearing with us!

[lowentropy]

And we're back up! We've migrated some services to better hardware. I think we've abused that 128MB box quite enough for now 

[FuzzyCoins]

How long would someone have to sit on a web page in order to generate enough work that would result in any credit at all for the hosting web site?

For traditional mining pools the unit of work credit is a "share" which takes a GPU miner minutes to hours to generate. A JS miner hours to days to generate a traditional "share". Most people don't sit on a single web page for hours, they are typically only on a web page for seconds to minutes. Are the units of work assigned and credited smaller then a typical pool "share"? Does this system have the concept of a fractional shares of work?

[lowentropy]

Our web miners still work with traditional shares (shares from slush's pool, actually). But all the work by all visitors to your site(s) goes towards a single account for the site operator. So the collection of sites is effectively the miner, only it makes lots and lots more getwork requests

Since javascript is quite slow, it's been suggested we might do fractional shares, and we're looking into this.

[FuzzyCoins]

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.

[1bitc0inplz]

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.

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.

[MZZM]

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.

[lowentropy]

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.

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

[gnubert]

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.

[PIO]

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

Isn't that very low?

[lowentropy]

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

Isn't that very low?

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.

[LeFBI]

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?