*BTC Poolwatch* - no new dev for now

[organofcorti]

Was that a convoluted request to add triplemining? If so, I'll second that. But I don't think they do user apis, only pool stats.

No, actually, someone else requested it, he tried and the API was broken so he was going to e-mail the admins.  I was just providing potentially useful information.  That said, TripleMining provides API keys to users, so I should think they would have per-user stats.  However, those may not be at the same URL, I wouldn't know.

EDIT:  I guess one could find out easily enough since the API on the workers page is a link...  http://api.triplemining.com/json/<APIKEY>

yep - triple just added it yesterday - talk about coincidence!

[1715340976]

1715340976

[1715340976]

1715340976

[rearwheels]

Minor update to the "Pool Stats" page.

Added a show of count down to new difficulty

Code:

6d 08:06:40 to new difficulty: 1,826,161

[gnar1ta$]

Just wondering if there was an update on adding NoFeeMining.com??

Added nofeemining.com! 

thx
sent some coin

[organofcorti]

Minor update to the "Pool Stats" page.

Added a show of count down to new difficulty

Code:

6d 08:06:40 to new difficulty: 1,826,161

Nice addition rw!

btw, pool speed on eligius has a bug:

Eligius
[Speed:0 ByteH/s]
Confirmed Rewards: 0.31658895
[Estimated: 0.0]

[rearwheels]

Eligius pool speed fixed.

The only pool that does not return json.

[Clipse]

rearwheels would you be willing to add some basic earnings/accounting section.

Im thinking it would be nice to use btc poolwatch that allready combines the confirmed/unconfirmed and estimated earnings in one block for all listed pools however it would be even more usefull if we could select an earnings range or at the very least have 24hr earnings calculated for confirmed/unconfirmed/estimated earnings.

This way we could more easily figure out what we made in a 24hr cycle compared to expected returns based on hashrate. Users on more than one pool it starts to get tricky to keep accurate 24hr cycle track of earnings.

[The00Dustin]

rearwheels would you be willing to add some basic earnings/accounting section.

Im thinking it would be nice to use btc poolwatch that allready combines the confirmed/unconfirmed and estimated earnings in one block for all listed pools however it would be even more usefull if we could select an earnings range or at the very least have 24hr earnings calculated for confirmed/unconfirmed/estimated earnings.

This way we could more easily figure out what we made in a 24hr cycle compared to expected returns based on hashrate. Users on more than one pool it starts to get tricky to keep accurate 24hr cycle track of earnings.

Yours isn't the first request for a feature that would require the server to store our information and poll our data whether we are actually using the page or not.  It probably won't be the last either.  That said, if you had read through the thread, you would have learned that our API keys are stored ina  cookie on our computer and the data from the servers is only retrieved from the pools when we request it by loading the page.  Given those two constraints, there is no way he can tell you what you earned in the last 24 hours or what your overall average hash rate for the last 24 hours was.  Changing this design would be 1) a privacey concern and 2) potentially harmful to the pools due to the number of constant API requests coming in, so I doubt rearwheels is interested in doing such a thing.  However, if you could get your pool(s) to include that data in the data returned by the API i should imagine that he'd be happy to add it to his page and perform math on it where doing so would make sense.

[Clipse]

rearwheels would you be willing to add some basic earnings/accounting section.

Im thinking it would be nice to use btc poolwatch that allready combines the confirmed/unconfirmed and estimated earnings in one block for all listed pools however it would be even more usefull if we could select an earnings range or at the very least have 24hr earnings calculated for confirmed/unconfirmed/estimated earnings.

This way we could more easily figure out what we made in a 24hr cycle compared to expected returns based on hashrate. Users on more than one pool it starts to get tricky to keep accurate 24hr cycle track of earnings.

Yours isn't the first request for a feature that would require the server to store our information and poll our data whether we are actually using the page or not.  It probably won't be the last either.  That said, if you had read through the thread, you would have learned that our API keys are stored ina  cookie on our computer and the data from the servers is only retrieved from the pools when we request it by loading the page.  Given those two constraints, there is no way he can tell you what you earned in the last 24 hours or what your overall average hash rate for the last 24 hours was.  Changing this design would be 1) a privacey concern and 2) potentially harmful to the pools due to the number of constant API requests coming in, so I doubt rearwheels is interested in doing such a thing.  However, if you could get your pool(s) to include that data in the data returned by the API i should imagine that he'd be happy to add it to his page and perform math on it where doing so would make sense.

Thanks for assuming I wasnt aware of how btc poolwatch cache the stats in a cookie, unfortunately I was.

My request would obviously suggest an accounts section / users actually logging in. This is part of the request for such a feature and I cant imagine it not being possible to implement.

The question would be would they want to add such features, I guess not. This isnt the end of the world as I have other means to go about this, it would just have been an easier approach to get the same thing done.

[The00Dustin]

Clipse,
I'm not part of the BTC-Poolwatch project, so don't consider it 100% apparent that they wouldn't want to add such features.  I was simply supplying reasons why it isn't feasible with the current setup and why it wouldn't necessarily be a great idea to do such a thing on a mass scale anyway (even an open-source tool for individuals to do this could end up taking down a pool the same way a DDoS attack could if it started spreading like wildfire, much like hoppers sometimes bring down a pool by monitoring it heavily while not even hashing at it).
Dustin

[organofcorti]

Clipse,
I'm not part of the BTC-Poolwatch project, so don't consider it 100% apparent that they wouldn't want to add such features.  I was simply supplying reasons why it isn't feasible with the current setup and why it wouldn't necessarily be a great idea to do such a thing on a mass scale anyway (even an open-source tool for individuals to do this could end up taking down a pool the same way a DDoS attack could if it started spreading like wildfire, much like hoppers sometimes bring down a pool by monitoring it heavily while not even hashing at it).
Dustin

Sorry - I couldn't let this go. Hopper proxies (and non-hopper proxies) only monitor webpages if there is no json feed. We have emailed pools that don't supply feed data in json and recommended one. Most proxies only update website data once every couple of minutes, and I would have been doing that manually. If a pool isn't ready for hoppers, it isn't ready for fulltime miners either.

[/rant]

[rearwheels]

Yours isn't the first request for a feature that would require the server to store our information and poll our data whether we are actually using the page or not.  It probably won't be the last either.  That said, if you had read through the thread, you would have learned that our API keys are stored ina  cookie on our computer and the data from the servers is only retrieved from the pools when we request it by loading the page.  Given those two constraints, there is no way he can tell you what you earned in the last 24 hours or what your overall average hash rate for the last 24 hours was.  Changing this design would be 1) a privacey concern and 2) potentially harmful to the pools due to the number of constant API requests coming in, so I doubt rearwheels is interested in doing such a thing.  However, if you could get your pool(s) to include that data in the data returned by the API i should imagine that he'd be happy to add it to his page and perform math on it where doing so would make sense.

What he said.

Thanks Dustin.

[Clipse]

Yours isn't the first request for a feature that would require the server to store our information and poll our data whether we are actually using the page or not.  It probably won't be the last either.  That said, if you had read through the thread, you would have learned that our API keys are stored ina  cookie on our computer and the data from the servers is only retrieved from the pools when we request it by loading the page.  Given those two constraints, there is no way he can tell you what you earned in the last 24 hours or what your overall average hash rate for the last 24 hours was.  Changing this design would be 1) a privacey concern and 2) potentially harmful to the pools due to the number of constant API requests coming in, so I doubt rearwheels is interested in doing such a thing.  However, if you could get your pool(s) to include that data in the data returned by the API i should imagine that he'd be happy to add it to his page and perform math on it where doing so would make sense.

What he said.

Thanks Dustin.

Ok, that leaves something for me to do

[rearwheels]

Thanks for assuming I wasnt aware of how btc poolwatch cache the stats in a cookie, unfortunately I was.

My request would obviously suggest an accounts section / users actually logging in. This is part of the request for such a feature and I cant imagine it not being possible to implement.

The question would be would they want to add such features, I guess not. This isnt the end of the world as I have other means to go about this, it would just have been an easier approach to get the same thing done.

Hi Clipse,

It is certainly possible to implement what you've mentioned. It's just that when I first set out on this project, I only wanted to be able to keep tabs on my miners on multiple pools at one glance. I was using this for my own use with hardcoded API tokens since I was the only user.

Later I made some modifications so that every one here can get to use it. And using only cookies to store user's information reduces the implementation time and effort tremendously (as opposed to getting users to register and login). That's 2 hours coding something simple vs 2 days coding plus testing plus hitting forget password and checking emails, etc.

One thing I've been thinking of implementing, is to have a user token (32 char random characters, similar to the API token) that will be unique to each user. This user token will be tied to all your pools' API tokens. So a user will remain anonymous, and this will be a step closer to implementing what you've mentioned.

However, I don't have a timeline for this as I only work on this in between rebooting my rig, upgrading catalyst versions and re-balancing the GPUs on each rigs.

[Clipse]

Thanks for assuming I wasnt aware of how btc poolwatch cache the stats in a cookie, unfortunately I was.

My request would obviously suggest an accounts section / users actually logging in. This is part of the request for such a feature and I cant imagine it not being possible to implement.

The question would be would they want to add such features, I guess not. This isnt the end of the world as I have other means to go about this, it would just have been an easier approach to get the same thing done.

Hi Clipse,

It is certainly possible to implement what you've mentioned. It's just that when I first set out on this project, I only wanted to be able to keep tabs on my miners on multiple pools at one glance. I was using this for my own use with hardcoded API tokens since I was the only user.

Later I made some modifications so that every one here can get to use it. And using only cookies to store user's information reduces the implementation time and effort tremendously (as opposed to getting users to register and login). That's 2 hours coding something simple vs 2 days coding plus testing plus hitting forget password and checking emails, etc.

One thing I've been thinking of implementing, is to have a user token (32 char random characters, similar to the API token) that will be unique to each user. This user token will be tied to all your pools' API tokens. So a user will remain anonymous, and this will be a step closer to implementing what you've mentioned.

However, I don't have a timeline for this as I only work on this in between rebooting my rig, upgrading catalyst versions and re-balancing the GPUs on each rigs.

I hear ya, its hard enough at times to manage your own mining farm and then still get requests like mine

[organofcorti]

However, I don't have a timeline for this as I only work on this in between rebooting my rig, upgrading catalyst versions and re-balancing the GPUs on each rigs.

I really enjoy the fact that I actually understood you're talking about there. I'm not sure anyone outside the forum would though  

[rearwheels]

Actually I'm looking to build one of these as a next project after btc-poolwatch.

http://linuxfocus.org/English/July2002/article239.shtml

[rearwheels]

Apologies, server is down.

[rearwheels]

Server is back up...after a freaking 20hr+ down time.

I've sourced for a new webhoster and will move the server/code over next week.

[rearwheels]

Hi guys,

I'm migrating to the new server. The DNS will take up to 48 hours to propagate.

No action is necessary on your part.

The server is now in US instead of Asia, so it should be faster for most of you.

"Software Engineering 101: Keeping fingers crossed after hitting enter."

*edit: pointed to the wrong DNS server. Have updated and thus you may experience a slight downtime due to the name servers pointing to the wrong dns I gave. Damn murphy's law.

[max in montreal]

Actually I'm looking to build one of these as a next project after btc-poolwatch.

http://linuxfocus.org/English/July2002/article239.shtml

I read somewhere once that a guy placed 2 pc close enough that he reset one pc by opening the cd tray of ther other...