bitHopper: Python Pool Hopper Proxy

[Clipse]

Weird... ozco.in reports 446976 shares but I seem to mine at eligius sometimes.

Also nothing was yet written to my stats file, maybe try to flush the writes every once in a while - or maybe I did something wrong...
Edit: no, just kill it with Ctrl+c and the stats magically appear. Seems like the writes don't get flushed to me.

Same problem i have, jumping to eligius mainly and other times bitpit or whatever other higher than the lowest available share block available.

[1713559581]

1713559581

[1713559581]

1713559581

[gno]

I must be missing something... I grabbed the latest git-  setup the accounts I have in password.py, commented out a couple of the pools in pools.py that I don't have accounts for and when I run it, I don't see any errors but it only seems to be mining to eligius.

This is what my run looks like:

Code:

[root@localhost c00w-bitHopper-8324470]# python bitHopper.py
[13:27:13] RPC request [] submitted to BTC Guild
[13:27:13] mtred :2319433
[13:27:13] Server change to eligius, telling client with LP
[13:27:13] pool.bitp.it :1315972
[13:27:13] btcguild :3773677
[13:27:13] RPC request [] submitted to eligius
[13:27:13] btcguild efficiency: 41.2121798097%
[13:27:13] LP Call su.mining.eligius.st:8337/LP
[13:27:13] bitp.it efficiency: 118.788564677%
[13:27:13] bitcoin.lc :5764834
[13:27:13] RPC request [] submitted to eligius
[13:27:15] RPC request [] submitted to eligius

... followed by ongoing eligius entries.

What am I missing?

[kbsbtc]

I must be missing something... I grabbed the latest git-  setup the accounts I have in password.py, commented out a couple of the pools in pools.py that I don't have accounts for and when I run it, I don't see any errors but it only seems to be mining to eligius.

This is what my run looks like:

Code:

[root@localhost c00w-bitHopper-8324470]# python bitHopper.py
[13:27:13] RPC request [] submitted to BTC Guild
[13:27:13] mtred :2319433
[13:27:13] Server change to eligius, telling client with LP
[13:27:13] pool.bitp.it :1315972
[13:27:13] btcguild :3773677
[13:27:13] RPC request [] submitted to eligius
[13:27:13] btcguild efficiency: 41.2121798097%
[13:27:13] LP Call su.mining.eligius.st:8337/LP
[13:27:13] bitp.it efficiency: 118.788564677%
[13:27:13] bitcoin.lc :5764834
[13:27:13] RPC request [] submitted to eligius
[13:27:15] RPC request [] submitted to eligius

... followed by ongoing eligius entries.

What am I missing?

I don't think you're missing anything. Same thing happens to me right now...grabbed the latest version of the git as of a few minutes ago and same thing.

[Clipse]

I must be missing something... I grabbed the latest git-  setup the accounts I have in password.py, commented out a couple of the pools in pools.py that I don't have accounts for and when I run it, I don't see any errors but it only seems to be mining to eligius.

This is what my run looks like:

Code:

[root@localhost c00w-bitHopper-8324470]# python bitHopper.py
[13:27:13] RPC request [] submitted to BTC Guild
[13:27:13] mtred :2319433
[13:27:13] Server change to eligius, telling client with LP
[13:27:13] pool.bitp.it :1315972
[13:27:13] btcguild :3773677
[13:27:13] RPC request [] submitted to eligius
[13:27:13] btcguild efficiency: 41.2121798097%
[13:27:13] LP Call su.mining.eligius.st:8337/LP
[13:27:13] bitp.it efficiency: 118.788564677%
[13:27:13] bitcoin.lc :5764834
[13:27:13] RPC request [] submitted to eligius
[13:27:15] RPC request [] submitted to eligius

... followed by ongoing eligius entries.

What am I missing?

I don't think you're missing anything. Same thing happens to me right now...grabbed the latest version of the git as of a few minutes ago and same thing.

same here, must be the recent changes <20mins ago cow made, version just before that didnt do this.

[Sukrim]

You're missing pools to hop into:
1 563 027.9961162 * 0.4 = 625 211.198

If all your pools have more than 625211 shares, there's no point in hopping anywhere but it's better to mine in a 0% PPS pool like eligius. (I still think it should rather be 0.435 though... )

Currently it seems that only ozco.in is hot, so you need to wait until/if it gets added to git or add it yourself.

[Clipse]

You're missing pools to hop into:
1 563 027.9961162 * 0.4 = 625 211.198

If all your pools have more than 625211 shares, there's no point in hopping anywhere but it's better to mine in a 0% PPS pool like eligius. (I still think it should rather be 0.435 though... )

Currently it seems that only ozco.in is hot, so you need to wait until/if it gets added to git or add it yourself.

Ah ok that explains it. In mean time I changed it to 0.435 as you suggested

[c00w]

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.

[Clipse]

mmm still incredibly high stales.

Im using latest version and after LP and running on btcguild atm its between 12-17% stales , I think alot of the stales came from the LP new block but still if I run on btcguild directly with same defined server I get <1% gauranteed stales.

Is this related to bithopper or something you are working on to resolve?

[c00w]

mmm still incredibly high stales.

Im using latest version and after LP and running on btcguild atm its between 12-17% stales , I think alot of the stales came from the LP new block but still if I run on btcguild directly with same defined server I get <1% gauranteed stales.

Is this related to bithopper or something you are working on to resolve?

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.

[c00w]

OP can you change something on thread title or first post to node when you make a major code update

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.

[Clipse]

Ok no --debug yet but can confirm atleast its LP related.

I am using phoenix 1.5 with phatk(same version i use directly giving <1% stales) but just for interest sake i used poclbm and poclbm with phatk, same issue with stales around LP.

Since I can clearly see its around LP it should be easy to replicate these stales for anyone , thus i dont think its specific to me that you would require a debug log just yet

[OCedHrt]

Does anyone know why im getting these API errors for bitclockers/bitpit ?

Code:

Error in user api for bitp
"[Failure instance: Traceback: <type 'exceptions.ZeroDivisionError'>: float division by zero\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:1076:gotResult\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:1063:_inlineCallbacks\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:361:callback\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:455:_startRunCallbacks\n--- <exception caught here> ---\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:542:_runCallbacks\n/home/miner1/bitHopper/stats.py:65:selectsharesResponse\n/home/miner1/bitHopper/stats.py:55:parse_bitp\n]"

Code:

"[Failure instance: Traceback: <type 'exceptions.ZeroDivisionError'>: float division by zero\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:1076:gotResult\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:1063:_inlineCallbacks\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:361:callback\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:455:_startRunCallbacks\n--- <exception caught here> ---\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:542:_runCallbacks\n/home/miner1/bitHopper/stats.py:65:selectsharesResponse\n/home/miner1/bitHopper/stats.py:39:parse_bitclockers\n]"

I'm getting the same thing....

Because you have no submitted shares for them.

[burp]

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.

What did they ban your account for? With funds?

[c00w]

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.

[bb]

Using phoenix and -u localhost:8337 I just get:


Unknown protocol:

Try throwing any credentials at it and see if it works

Doh, just forgot the http://.

[Clipse]

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.

I think you nailed the problem here 0% stales and counting.

EDIT: may have spoken to early or it could just be ozco.in that is staled to shit. While mining on btcguild the stales remained at 0% then it switched over to ozco.in and stales went to 10%

[flower1024]

is it possible for bitHopper to switch between pools very fast without producing stales?

if so, i think it could be better to decide pool target per submitted share:
one (simple) example for each client getwork request:

DIFF = 10000 (example)
btcguild =     1/100    = 0.01 (means btcguild has 100 shares right now)
bitpit =         1/3000  = 0.0003
bitclockers =  1/500    = 0.002
bitcoinslc =    1/10000 = 0.00001

BREAKEVEN = DIFF * 0.4 = 4000 (only switch between pools lower than break even)
RAND(0, (btcguild + bitpit + bitclockers))
0-0.01 -> btcguild
0.01-0.0103 -> bitpit
0.0103-0.0303 -> bitclockers

i want to implement this (and submit a pull request if it works of course). but i don't know if is feasible to switch that fast. i dont want to have much more stales

[c00w]

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

[flower1024]

i just read point 2)

are you saing it would be possible to submit the same share to multiple pools?

i am pretty sure you must deliever a share where the getwork came from.

i'll try the idea to switch pools fast tonight. lets see... my python skills still lack

[Sukrim]

If a server accepted valid shares of other servers that would be a bug in the server code, not an intended feature. Something to try out, but not something worth doing in the long run.

What could be more interesting would be to prefetch getworks - so you always already have one available once your miner requests a new one instead of having internet delays at each new request.

I got some json decoding errors at btcguild btw., but they mine so fast that it's hard to really debug it...