1) Stale Share?
He's talking about stales not rejects.
I stopped bitHopper from changing servers with getworks that contain shares. That should help a bit. And  fixed a bunch of LP issues. I am still see some artificially high stale share counts. Let me play with it a bit. I don't know where they are coming from currently though.

1) Only mining eligius?
I disabled bitcoins.lc a while ago because they are banning pool hoppers.
Since none of the pools have sharecounts < difficulty * .40 it won't hop to any of them and uses the two backup pools: eligius and arstechnica.

1) bithopper switching pools quickly?

Its is feasible. The lag is the network connection not the server. Stale shares should also be going down a lot hopefully since I ironed out a lot of LP bugs.

2) Random idea
I'm actually tempted to write the code to submit each share to every server... Seems like it'd make it possible to get more credit. But it would also probably increase stales a lot since some servers won't accept random shares but only the shares they gave you the getwork for.

4) High stales with oczo.in?
I think oczo.in is getting a little overloaded. Might be our fault

1) account banning?
Pool Hopping. Go figure. I had some funds. I have no idea how much. I was trying to log in and check.

2) Errors in LP?
I think I fixed some. I might be using the wrong agent. Let me check. And a debug log or any log helps because then I can clearly see the error. And then I can try and check my logs for it. I have a flaky DNS resolver though so my reject rates are higher than they should be so sometimes I see errors and think it is because of that.

EDIT: And I used the wrong agent... So the latest revision has that fixed as well. Probably why LP wasn't working.

3) zero division errors?
Bad code on my part. Its fixed in the latest revision.

You mean everyone doesn't run git log!
Sure. I'll throw it in the first post When a big change is made. There shouldn't be too many more besides database integration.

I'm not sure. LP was screwed up until a recent commit due to the code reorganization. It should be fixed now.

Can you update to the latest version and if the issue is still apparent:
1) open an issue on github (or just repost here)
2) run bitHopper.py --debug and give me a link to the logs
3) Tell me what miner you are using so I can duplicate it on my test machine.

1) Where have you been?
For some reason my browser wasn't updating the forums so like 2 pages of posts showed up in 1 minute.

2) Lp Error?
I think they are ironed out now. And the code is less of a complete disaster.

3) ozco.in?
I'll add it. I just wasted two hours of my life trying to reset my bitcoins.lc account before they told me they banned it.

4) Lots of eligius?
Well it only hops onto pools as Sukrim said at shares < diff * .40.
I'm getting lots of arstechnica.

5) Why oh why did you rewrite the code and cause all these errors?
Because it makes it a lot cleaner to read the code and try and comprehend it.

6) Stats?
Yeah I added some basic ones. They are messed up in a number of ways including difficulty changes, old shares, old dropped shares, and plenty of other errors. I'm going to rewrite the system to use a sqlite database and we'll see whats up.

7) Database not another dependancy!
I'm going to make it strictly optional and try and rig it so it is only include if you pass a --stats command or something similar.

8)Connecting to pools with high share counts when it shouldn't?
If both the backups lag out it will jump on mining pools again with high share counts. Now that there are two backups it should do it less.

Run python bitHopper.py.

Pool.py is now only for the pool functions.

Its hash rate when the block is found. And my efficiency is about 76%. If yours is higher or you want to use it go right ahead. I'm disabling it because I'd rather mine on eligius.

It looks like bitclockers is using a payment scheme based on hashing rate not number of shares. I'm disabling it for now. And I got its efficiency statistics written.

EDIT: bitp is coded as well.

Hi,

Statsdump is a sort of median step. It had a bug which should be fixed. On server change it dumps shares, server, and difficulty.

I'm trying to rig something up with btcguild. Then mtred then we'll see.
EDIT: btcguild rigged. Add your api key to passwords.py or you will get my stats.
-c00w

Efficiency can mean a number of things. A lot of people use it as hashes/getwork request.

In terms of payouts yes. Expected payout = shares/difficulty * 50 for normal mining. Payout per share = 50/difficulty.

I would probably just display the efficiency as actual/estimated * 100.

Well in terms of revenue it should mathematically be 28% more if you are hopping all the time. Earlier someone said they got ~20% more. At the worst case you'll get the same revenue you'd get normally and be stuck mining at eligius all day.

Stats are slowly in the process of going up. There is a stat dump file which records shares, difficulty, and server.

I originally wanted the stats to be integrated into the server but I might just write a program which allows you to enter you rewards from each server and calculates its efficiency.

EDIT: I did some quick calculations on btcguild and I have 9362 shares. I expected to get 0.299 btc for those shares. I got 0.384 for those shares. So I got about 28% more that I should have. Which is actually pretty amazing.

1) Arsbitcoin as the second backup?
Sweet. I'll add it.

EDIT: The website is broken and I can't login. So I haven't added it. Will try later on a windows machine.

2) Refactor code?
Yeah. I want to do it. I was going to move everything thats not explicitly pool related out of pool.py and into bithopper.py and lp.py

3) Pool share count?
I can reenable it.

4) dumping the stats to a file?
Yeah I was going to try and make an sqlite database and then well LP errors and crazy cycling.

EDIT: I added it as --statsdump

5) Triplemining?
Well it seems like a little bit of a ponzi scheme. I have no issues hopping them however.

1)Minecoin?
They are already out of the rotation.

2) Crashes on that line?
Removed it. Not needed. I'm unsure why it was sucking so much work though... I did up the timer for the stalls to half a second a piece. It looks like your miner is timing out too quickly. I got these sorts of stalls with poclbm. Phoenix stalls less although it will try and double submit shares.

EDIT: Actually I think it is a server side LP issue. Which I think I just fixed. I accidentally had error'd LP calls call the lp handler

3) Invalid username/password taking out a pool?
Yeah it already does this assuming the pool won't accept the work. Sometimes it does. its a little dicey. I'm going to try and add an option for going --skip Name1, Name2, etc... as well as a --list to help tell people which servers are installed.

EDIT: Enabled and in the repository. Note the format for disable should have no spaces.
Oh and I used --disable not --skip

And I reordered the code again to try and stop tripping eligius's DDOS settings. To whoever sent me some bitcoins: Thank you very much.

I hope I'll do some stats soon but I'm spending too much time tracking down bugs. Its on the list. I swear.

Fixed disabling of the wrong pool. Also I think I fixed the RPC cycling bugs. Found a new bug in the client side long polling of certain miners which are unable to handle a LP call returning an error JSON RPC call.

Stats are in the work. Short term efficiency stats are next on the list. I'm probably going to run with sqlite or mongodb at first if a database is required. However I think I can get away without one for a bit.

Huh. I was actually going to add btcmine as the second backup pool but I can't register on it since registration is closed.

k. Which pools produce more rejected shares? there is an error in phoenix where it times out and double submits the same share.

In terms of DDOS the software will recognize when it can't connect, mark the pool as lagged and move on. It will try and delag the pool though.