are you sure you switched to the api method suggested by mrsam?
for me its working.

and he already announced HERE that he will fake stats when accessed through the https site (which i am fine with and which i can understand)

you could use my service (at least for a double check)

http://www.k1024.de/servers.json

more pools will follow (also namecoin pools)

i will announce it official next week on sunday. its beta stage right now

i'll add namecoin pools (and other smaller pools) to this http://www.k1024.de/servers.json tomorrow

i am trying with an pool hopping service.
atm its free - if i get any problems regarding traffic i'll come back to you

http://www.k1024.de/servers.json

my vserver (which rans bithopper) prints out this json file every ten seconds. this file is immediatly uploaded to an ftp-server (which you can access using the link above).

so at least: my hopper stays somewhat secure.

tomorrow i'll add hashrate and another round share counter (parsed through regex) - so pool stats-faking is little bit more detectable.

the format is as follows:

BTW: if you are interested in joining this project please pm me. i have a job, so i can't watch the pool whole days. maybe four people from different timezones would be nice

wouldn't work with latest c00w, but anyway:

json IS capable of [] - its just an array. index 1 is round shares
(for me json.loads works)

would you accept a service which has (sometimes) wrong stats?
we would need a group of trusty people

after all wrong stats means less money

i was already thinking about that.

the problem is this site is big target. it could easily be put offline.
atm i have my poolhopper running at a vserver and its publishing its stats per json.

but i am afraid of publishing this address.

also it would be easier for pools to fake stats explicity for that service.

i would do it for btc. but this could get into a fulltime job very fast.

you could have placed a json file on your server which updates thrrough a cron-job.

buty anyway: good look with pplns

would be glad if you tell us before you'll switch.

to get triple working again:
open work.py
function: get
    header = {'User-Agent': ['Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0'],'Content-Type': ['application/x-www-form-urlencoded'] }
    d = agent.request('GET', url, Headers(header), None)

(this is from an old version, but should not be very hard to adapt)

it has an expected value of one in a (very) long term view (if you really hop in/out randomly).


he just misunderstand the system and thought N/2 shares means round_shares.
but n/2 shares means difficulty/2 shares - and with that pplns is just not hoppable. the window is to big

(please correct me if i am wrong)

very nice idea!
what about just placing a command line in pools.conf which gets executed every time round-shares are updated?

that way we could completly decouple bithopper from pools - and even change them without an restart.

shell command could return sth like "poolhashrate,roundshares,false|true" (false|true: is the api lagging)
which could easily be parsed by python

as i think he speaks about my mod:
no pplns is not hoppable. the window ist just to big.
atm i am trying to hop slush @300% difficulty and stays until block is found; but i know already that this won't work (due to bitcoin poison process)
^^ i just want to learn it mysql the hard way

change in pool.py:

re.search(r"<td><!-- 1000 -->[0-9]*</td>", statpage).group(0)[17:-5]

use a firewall and tunnel this port through ssh.
works fine for me (i am using my hopper on a vserver)

you are right. hopper on top of a miner is better.
but if you have more than one miner the actual pool selection (and stats grabbing) should be one a single place.

and: a proxy is very much more flexible.
 - you can use any miner you want
 - you can tweak ports (i have to mine through port 80)
 - single place for share/reject/speed counter and idle warnings (which are not easy to integrate in a miner; because the whole pc could have gone to hell)

so (for me) a hopping proxy is better than a miner integration - as (with integration) i would use a proxy anyway

if he would, he had to wait for the result of the getwork - time for your gpu to cool down
as (probably) you don't want that its better to prefetch some.

its a getwork request from your miner to get something to do
its forwarded to the selected pool (eg arsbitoin

i think there is something wrong with stat data from bcpool.

it says: 18h round with 185330 shares @160gh?
i dont believe that. i think he could be dividing his shares by ten.

only found round shares in json - not on the site.

any ideas?

how fast does your db grow?
i tried to keep track of shares with couchdb, but i threw it at away after i realized that after only ten minutes it was about 3 mb.

hi @all.

i got an interesting mail (my answer is included):

Hello,

Am 18.07.2011 19:15, schrieb ?:
> Hello,
>
> If I understand this correctly, I think your addition will lower the variance of returns slightly, but not have any affect on the expected returns.

I think it will have an affect.

example 1: two pools found a block next to each other with the same speed. original bithopper will stick with the one with the lower shares. that could be good or worse.

if it's good you earn much more; if its bad you loose the half.

example 2:
a pool with a very high hashrate finds a block righte before a small pool.

original bithopper will switch to the small one. it would be better to try to submit shares to the fast pool and - after that - continue with the small one.

^^ thats my impression. please correct me if i am wrong

I'm at work right now, but I would like to discuss it further either in here or on the forums (I still don't have proper non-newbie privledges necessary to post in the thread).
>
> IMO, it adds unnecessary complexity for a small decrease in variance. Can we please add it with a switch, such as --time-slicing=[yes|no] ?

^^ bithopper itself is not from me.
so if you don't want that slicing right now, just stick with the original version.

if it gets merged (i hope so), i prefer a switch too (i would even suggest pluggable modules through c00w's planned website - so if you're watching you can change the strategy on the fly)

>
> If two pools are both at X% and both are standard proportional pools, the expected return on shares is equal. Due to time-lag in pulling stats, one should choose the pool with a lower hashrate for highest return (although if hoppers are a large portion of the hashrate, this is unstable and will cause the hashrate, #workers, and optimal pool to oscillate unstably).
>

my recent version (see attachment; as i got ill i was not able to publish it right now. especially the "ghash pool bonus" is not well tested (i should write a program to simulate pool stats)) has a few improvements:

 - bonus for BIG pools (i now; you don't like that. but big pools goes to 40% diff very fast, so i think its a good idea to catch up)
 - tries to stay longer at one pool (means: if after a ten minute round the same pool got a new time slice it stays there)
 - tries to start the longest (means most profitable) slice as soon as a new block is found, a pool lags or another slice finished

thank you for you thoughts. i just think we need a long-time sim here - and i am still planning to work on a bitcoin patch to better detect btc guild / deepbit blocks

> Cheers
>


as i said: i got ill
i just managed to continue the work the pool-ghash adaption.

you can get it here:

(i promise i will make a git push; but with that headache..BBRRRRR)

link: www.k1024.de/dev.zip (this time its a zip; i just like changes

cheers


LOL just recognized it was a github comment...my headache ...

anyway: please tell me what you think about it