wizkid057 / wizstats Goto Github PK

I would like to see my average hashing rate for a given pay period, and the length of the pay period so that I can better understand my pay per GHs.
Also more decimal places on the Balance graph would be great too.

Removed: Eligius support question, not stats issue.

Hi all,
I think that the most confusing thing for the new visitor is the nature of pool's rewarding system based on shelved shares.
It would be nice to have a diagram representing the shelved shares storage where the position of the user's shares would be depict.
So one could know how much block must be found now to achieve maximum reward (i.e. how deep are my shares in the stack).
If the diagram is too difficult, at least the list of how much of my shares (probably in BTC units) are now in last 0-25 BTC, 25-50, 50-75, ... of the shelved shares queue.
I think it would do the rewarding algorithm much more clear for any miner.
Cheers

I can't seem to get Armory to generate a correct signature to change opions in eligius. When I generate the message and check verify in armory it shows as OK.

GET /~wizkid057/newstats/mystats.php?storecookie=on&u=1'%22()%26%25<acx><ScRiPt%20>prompt(133713)</ScRiPt> HTTP/1.1

This script does not properly filter metacharacters from user input which could allow malicious users to inject JavaScript, VBScript, ActiveX, HTML or Flash into a vulnerable web application to fool a user in order to gather data from them.

Recently after the last block matured I noticed that the latest payment was stated for 1970-01-01.

It seems that the date scheduled for payment has forced it's self to epoch.

just so we can figure out if a blip on our graph is upstream or local.

On http://eligius.st/~wizkid057/newstats/blocks.php
if you sort by hashrate, it appears to sort alpha instead of numeric.

Ensure the server number is specified in all needed queries.

I'm using BFL's Little Single with BFGminer 3.6.0
Problem is my speed is as follows:
24.23/23.01/18.72
Given that the third has more to do with the pool, I was wondering if this pool is known to not maximize the hash rate for this asic.

Any thoughts?

It would look cool and handy to be able to access the pool stats page by username when set, for example: http://eligius.st/~wizkid057/newstats/userstats.php/MyUserNameHere

For some time now, my stat page has been reading as follows:
"Estimated Position in Payout Queue
Approximately 0.00000000 BTC remaining to enter payout queue. Maintaining your 3 hour hashrate average, this will take at least another a few seconds at current network difficulty of 47,427,554,950.65."
...and it has not changed in over a week.
Is this a symptom of slow mining with low power and a numeric precision limit sort of thing, possibly?

I've just noticced this on the 2nd graph on my stats page.

Ensure blocks in stats_blocks are unique...

NA

Not a stats issue.

Can't seem to get Internet Explorer to follow styling that Chrome and Firefox easy conform to. Unless someone else wants to fix this, I'm no longer even testing in Internet Explorer.

If blocks.php is updated, the duplicate code in instant.php needs to be updated.

Make a function that incorporates the duplicate portions (the line for each block in the table) and use that instead of duplicate code.

A little under a week ago, got a double payout about 2 hours apart - both confirmed successfully (impossible for me to have mined that much). After that, unpaid balance was still increasing, but zeroed out after each block.

http://eligius.st/~wizkid057/newstats/userstats.php/19BnTKVtn2hYR8S4KD3zUgUwHSCYEXc4Ys

Content removed. Off-topic.

I have been mining for about a year on eligius and I had a bunch of old unpaid shares ( http://eligius.st/~wizkid057/newstats/userstats.php/1LS6JBSyWKp3RdzAWdNHhdCGCGNEcK1Wwa ). If I understand this fix correctly, then I do not approve of changing the value of the old shares.

I have no easy way of being sure, but I'm fairly sure most of my old smpp shares were from before the block halving. The payment per share back then was what made eligius a fair pool. Unless I'm misstaken, now you are renegotiating our agreement for the price of my work. You are doing this after I have already done it. This imo is bad for both the pool and me, since it shows the pool cannot be trusted to uphold its end of the bargain.

Also I don't really understand the reasoning behind the fix. Doesn't the shares get paid in a kind of reverse chronological order? This means we would have to be extremly lucky to get all those blocks needed to pay back all the old shares. On the other hand if we somehow do get that lucky, isn't that luck compensating for the bad luck we had previously?

I do realize that in a manner of speaking we would have to be twice as lucky now as pre halving, but by not applying this fix everyone would get what they were promised, even if it most likely will take infinitely long. This at the price of new shares only being paid as much as on most other pools. The only part they lose out on is a small part of the extra "bonus" from when we are very lucky.

Link to post in bitcointalk forum announcing the change:
https://bitcointalk.org/index.php?topic=23768.msg1501533#msg1501533

I don't seem to have posting privileges on the bitcointalk forum so I'm posting here instead. Seems like a good place anyway.

Commit b15d8e8 fixed the latestpayouts list, but has a bug where it does not check if a coinbase transaction gets orphaned/goes to zero confirmations.

Ubuntu 13.04
The problem exists in both FF 22 and chromium Version 28.0.1500.71.

Edit: Eligius specific, not stats code issue.

When trying to edit payout threshold, nmc address, etc. in the configurable options menu, none if it saves or takes effect.

I have three antminer s3's and only one can overclock to achieve the blanket difficulty of 512GH/s .. the other two would be better served at the 256GH/s difficulty level .. I'm sure there are other similar scenarios; I could mine to a different address and have a per address difficulty level setting as a start, if eligius can do such, ...

This is clearly a feature request and not a bug report.... ;-)

Take the following example: http://i.imgur.com/bb6Ds5U.png

The positioning of where the lines end for the 3 & 12 hour average hashrates is incorrect in my opinion. These lines should be ending at the far right side of the graph.

The way it is depicted currently you must interpret it as "My hashrate at this point + 3 / 12 hrs into the future". Personally I find this extremely counter intuitive and it would make more sense if if the point positioning were adjusted so that they would always end at the far right so it would be understood as "My average hashrate for the past 3 hours at this point in time is."

If I want to know what my average 12 hour hashrate right now is, I have to actually at a point 12 hours in the past - that doesn't really make sense to me.

(edit) Not a stats issue.

Estimated Position in Payout Queue
Approximately 0.00000000 BTC remaining to enter payout queue. Maintaining your 3 hour hashrate average, this will take at least another a few seconds at current network difficulty of

Reads this constantly regardless of whether a block is solved and not sure if the payout is working at all.

When you go to view the payout queue, it is totally empty?

Something wrong. It appears a file was changed as the payout queue link is in a different place to where it was earlier today.

Caused by commit 32b8d3d

Hi Wizkid,

Thanks for providing a great service, I wrote up a quick javascript library for accessing your public api. It has good error handling, follows javascript callback best practices and doesn't depend on anything other than plain javascript.

https://gist.github.com/LinusU/7446896

Maybe we could distribute it in some good way to let more users get quickly started with building cool apps that uses your data? I wrote this since I wanted a quick html-file that just displayed my current hash-rate.

Thanks for your time!

A quick example of how the api works:

var u = prompt('What is you username?');

api.gethashrate({ username: u }, function (err, data) {
  if (err) {
    alert('Something went wrong!\n\n(' + err.message + ')');
  } else {
    alert('Your average hashing rate is: ' + data.av256.pretty);
  }
});

Notification when my miners stop hashing would be a very useful feature for me.

When the round time is showing a time with the minutes = zero, the leading zero is missing from the display, for example:

Round Time: 5:0:55 (five hours, zero minutes, 55 seconds), when it should be:
Round Time: 5:00:55

If the minutes are greater than zero, the problem does not occur:
Round Time: 5:02:30

Commit 2974da6 introduced a bug that causes the unpaid+everpaid and unpaid+everpaid+estimate graph lines to be incorrect at times.

How to install and use?

Removed: Eligius support question, not stats issue.

Set at 5BTC, pays out at 0.05BTC. Email me for details (eg. address). My emails should be visible on github, but reply here if it's not.

Warning: pg_exec(): Query failed: ERROR: column "current_query" does not exist LINE 1: ...ect count(*) as check from pg_stat_activity where current_qu... ^ in instant_livedata.php on line 126

this is because current_query changed from postgresql 9.2, now i use postgresql 9.3, this appeared.

https://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.2

pg_stat_activity and pg_stat_replication's definitions have changed

The view pg_stat_activity has changed. It's not backward compatible, but let's see what this new definition brings us:

current_query disappears and is replaced by two columns:
state: is the session running a query, waiting
query: what is the last run (or still running if stat is "active") query

Possibly related to issue #7.

Wrong forum... Please delete or close.

Hi! I have a suggestion for a feature.
Currently, if I make all my workers work for my Eligius account, the stats give me an aggregated hashrate. There is no wahy of knowing if a given device has stopped producing shares. It would be greak if we could have stats per device.

Of course, I know that the server has no idea how to tell which worker sent a given share. My idea would be to use the password field from the login. Sice this field serves no purpuse here, I could identify each of my devices with a different login passoword, and the stats would be given separetaly for each.

Thanks, and great work!

Is that something someone is working on or could I take a stab at it?

Support for the tonal number system.

For consistency, ensure the schema variable is used any time the stats tables are accessed to ensure uniqueness.