Topic: *BTC Poolwatch* - no new dev for now - page 4. (Read 33505 times)
Seems pretty handy if you use multiple pools though!
Hey rearwheels,
site down atm. Getting this error:
No data received
Unable to load the webpage because the server sent no data.
Here are some suggestions:
Reload this webpage later.
Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data.
Being without btc-poolwatch is like running blind!
site down atm. Getting this error:
No data received
Unable to load the webpage because the server sent no data.
Here are some suggestions:
Reload this webpage later.
Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data.
Being without btc-poolwatch is like running blind!
Server is back up.
I hope it's not because some miners got rigs at the same data center and caused the power issue.
Crap, the server is down.
http://status.namecheap.com/?p=5218
I actually signed up for godaddy and ran into problems and got a refund within 14 days of sign up.
Lightning does strike twice.
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...
Great idea. If only have I have CD rom drives....
Anyway, I'm skipping this reset thing, since I have very good up time on my machines now. (7 days and counting)
cannot find the api for eligius...can anyone point it out?
Hashrate
http://eligius.st/~luke-jr/raw/combined/hashrate.txt
User stats
http://eligius.st/~luke-jr/hashrate.php?addr=
Balance
http://eligius.st/~luke-jr/raw/5/balances.json
Last block balance
http://eligius.st/~luke-jr/raw/5/blocks/latest.json
Goto http://eligius.st/~luke-jr/ for everything you need.
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.
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.
i dont know much about cookies...but can it save the time of your last visit, and the confirmed/unconfirmed? and when you come back the site tells us since your last visit, at 12:06 pm on monday you made X coins?
In a way, that's possible, but if you have automatic payout, your second visit will have less confirmed payout than the earlier, so the delta does not make sense, similiarly for unconfirmed payouts.
cannot find the api for eligius...can anyone point it out?
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.
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.
i dont know much about cookies...but can it save the time of your last visit, and the confirmed/unconfirmed? and when you come back the site tells us since your last visit, at 12:06 pm on monday you made X coins?
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...
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.
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.
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.
Apologies, server is down.
Actually I'm looking to build one of these as a next project after btc-poolwatch.
http://linuxfocus.org/English/July2002/article239.shtml
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
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
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.
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
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,
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
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]
Jump to: