bitHopper: Python Pool Hopper Proxy

[bigbeerjr]

In case you haven't noticed I got Server Side LP working. And now my rejection rate is 0%. Which is pretty sweet.

I just did a pull and check out this hotness.

~/bitHopper $ ./pool.py
Trying to delag
Calling sharesResponse for btcg
btcguild :5835582
LP Triggering clients on server change to eclipsemc
LP Client Side Reset
Loading the request failed
LP RPC request [] From eclipsemc.com
Calling sharesResponse for mtred
mtred :22972
LP Call pacrim.eclipsemc.com:8337/LP
Calling sharesResponse for bitclockers
bitclockers :47959
Calling sharesResponse for mineco
mineco :2059918
Calling sharesResponse for bclc
bitcoin.lc :2382709
Calling sharesResponse for eclipsemc
eclipsemc :494116
LP Triggering clients on server change to mtred
LP Client Side Reset
reading request content failed
Loading the request failed
LP RPC request [] From mtred
LP Client Side Reset
Loading the request failed
LP RPC request [] From mtred
LP Client Side Reset
Loading the request failed
LP RPC request [] From mtred
LP Client Side Reset
Loading the request failed
LP RPC request [] From mtred
Error in json decoding, Server probably down

LP Triggering clients on server change to bitclockers
Error in json decoding, Server probably down

LP Triggering clients on server change to eclipsemc
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
Error in json decoding, Server probably down

LP Triggering clients on server change to eligius
Error in json decoding, Server probably down

MINECO SELECTED THIS SHOULD NEVER HAPPEN
LP Triggering clients on server change to mineco
RPC request [] From mineco.in
LP Call mineco.in:3000/LP

and after that I'm submitting shares to mineco!

Restarting has helped for a little bit, and then:

LP triggered from server bitclockers
LP Triggering clients on server change to mtred
LP Client Side Reset
Loading the request failed
LP RPC request [] From mtred
LP Client Side Reset
Loading the request failed
LP RPC request [] From mtred
LP Client Side Reset
reading request content failed
Loading the request failed
LP RPC request [] From mtred
LP Client Side Reset
reading request content failed
Loading the request failed
LP RPC request [] From mtred
LP Client Side Reset
Loading the request failed
LP RPC request [] From mtred
LP Client Side Reset
reading request content failed
Loading the request failed
LP RPC request [] From mtred
LP Client Side Reset
reading request content failed
Loading the request failed
LP RPC request [] From mtred
LP Client Side Reset
Loading the request failed
LP RPC request [] From mtred
LP Client Side Reset
Loading the request failed
LP RPC request [] From mtred
LP Client Side Reset
Loading the request failed
LP RPC request [] From mtred
LP Client Side Reset
Loading the request failed
LP RPC request [] From mtred
Error in json decoding, Server probably down

LP Triggering clients on server change to bitclockers
Error in json decoding, Server probably down

LP Triggering clients on server change to eclipsemc
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
Error in json decoding, Server probably down

LP Triggering clients on server change to eligius
Error in json decoding, Server probably down

MINECO SELECTED THIS SHOULD NEVER HAPPEN
LP Triggering clients on server change to mineco
Error in json decoding, Server probably down

LP Triggering clients on server change to bclc
Error in json decoding, Server probably down

LP Triggering clients on server change to btcg
Error in json decoding, Server probably down

LP Triggering clients on server change to eligius
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
Error in json decoding, Server probably down

Error in json decoding, Server probably down

Error in json decoding, Server probably down

caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
Error in json decoding, Server probably down

caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
Calling sharesResponse for btcg
btcguild :6133250
Calling sharesResponse for mtred
mtred :96698
Calling sharesResponse for bitclockers
bitclockers :75968
Calling sharesResponse for mineco
mineco :2088709
Calling sharesResponse for bclc
bitcoin.lc :2472519
LP triggered from server eligius
LP triggering clients manually
LP Client Side Reset
reading request content failed
Loading the request failed
LP RPC request [] From eligius
LP Client Side Reset
Loading the request failed
LP RPC request [] From eligius
LP Client Side Reset
reading request content failed
Loading the request failed
LP RPC request [] From eligius
LP Client Side Reset
Loading the request failed
LP RPC request [] From eligius
LP Client Side Reset
reading request content failed
Loading the request failed
LP RPC request [] From eligius
LP Client Side Reset
reading request content failed
Loading the request failed
LP RPC request [] From eligius
LP Client Side Reset
reading request content failed
Loading the request failed
LP RPC request [] From eligius
LP Client Side Reset
reading request content failed
Loading the request failed
LP RPC request [] From eligius
LP Client Side Reset
reading request content failed
Loading the request failed
LP RPC request [] From eligius
LP Client Side Reset
Loading the request failed
LP RPC request [] From eligius
LP Client Side Reset
Loading the request failed
LP RPC request [] From eligius
LP Client Side Reset
Loading the request failed
LP RPC request [] From eligius
LP Client Side Reset
Loading the request failed
LP RPC request [] From eligius
LP Client Side Reset
Loading the request failed
LP RPC request [] From eligius
Calling sharesResponse for mtred
mtred :96698
Calling sharesResponse for bitclockers
bitclockers :75968
LP Call su.mining.eligius.st:8337/LP
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
Calling sharesResponse for mineco
mineco :2088709
Calling sharesResponse for bclc
bitcoin.lc :2477036
Calling sharesResponse for btcg
btcguild :6133250
Calling sharesResponse for eclipsemc
eclipsemc :507240
Calling sharesResponse for eclipsemc

and now I'm on eligius....

[organofcorti]

In case you haven't noticed I got Server Side LP working. And now my rejection rate is 0%. Which is pretty sweet.

I just did a pull and check out this hotness.

Username and passwords are correct and in the passwords file?

[c00w]

In case you haven't noticed I got Server Side LP working. And now my rejection rate is 0%. Which is pretty sweet.

I just did a pull and check out this hotness

I understand that you feel quite frustrated as you throw another layer in between you and your pool and it spews oodles of output and stops giving work. I try and make this software do everything it can to get your work submitted. In this case however it spewed loads of output for two reasons. 1) It literally tried every server in the book in order to get a getwork and failed. 2) I left a little bit too much LP debugging in because I had just released it and was worrying that it would die.
And after spewing output it did come back up which is the point of bitHopper.
-c00w

Answers:
1) Pastebin?
Yes I like pastbin for large files. I like opening an issue on github even better.

2) More details?
Your internet probably died for a brief second. It then chewed through every server before defaulting to an extreme corner case I never expected. It will select mineco if literally all the other servers fail. I fixed that now though. However the LP shouldn't have been retried more than once for each server. Let me doublecheck that code.

Edit: 3) More details?
On looking through the logs I realized that some of my debug messages don't make any sense. What happened in your case is most of that spewing was your miner submitting incorrect LP request. Probably because it always submits them and it got extra desperate when it had no work. But I'm rewriting most of my debug output to make this clearer and the normal output to hide it.

Nothing went wrong with the server side LP code. How many miners are you running though? Thats a lot of clients being triggered on a server change.

[anty]

I just checked out the last commit and after some time it stops giving work while outputting loads of lines like these:

Code:

RPC request [] submitted to eligius
Caught, jsonrpc_call insides
User timeout caused connection failure.
Caught, jsonrpc_call insides
User timeout caused connection failure.
Caught, jsonrpc_call insides
User timeout caused connection failure.
Caught, jsonrpc_call insides
User timeout caused connection failure.
Caught, jsonrpc_call insides
User timeout caused connection failure.
RPC request [] submitted to eligius
Caught, jsonrpc_call insides
User timeout caused connection failure.
Caught, jsonrpc_call insides
User timeout caused connection failure.
RPC request [] submitted to eligius
Caught, jsonrpc_call insides
User timeout caused connection failure.
RPC request [] submitted to eligius
RPC request [] submitted to eligius
Caught, jsonrpc_call insides
User timeout caused connection failure.

[GoMaD]

last exception:

Code:

caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
Caught, jsonrpc_call insides
User timeout caused connection failure.
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
Caught, jsonrpc_call insides
User timeout caused connection failure.
Unhandled error in Deferred:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 789, in runUntilCurrent
    call.func(*call.args, **call.kw)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/task.py", line 194, in __call__
    d = defer.maybeDeferred(self.f, *self.a, **self.kw)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 133, in maybeDeferred
    result = f(*args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1141, in unwindGenerator
    return _inlineCallbacks(None, f(*args, **kwargs), Deferred())
--- <exception caught here> ---
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1020, in _inlineCallbacks
    result = g.send(result)
  File "pool.py", line 296, in delag_server
    data = yield work.jsonrpc_call(json_agent, server, set_lp)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1141, in unwindGenerator
    return _inlineCallbacks(None, f(*args, **kwargs), Deferred())
exceptions.TypeError: jsonrpc_call() takes exactly 4 arguments (3 given)

writing screen session into logfile now, so next time i hopefully can give better crash info 

Edit: 420 shares 0 stales!

[phelix]

this prog is superb because it forces pool operators to finally take action against pool hopping.

Because I am too lazy to install it for now I will simply not use pools any more that are supported by this prog.   

[paraipan]

this prog is superb because it forces pool operators to finally take action against pool hopping.

Because I am too lazy to install it for now I will simply not use pools any more that are supported by this prog.  

yeah, maybe you´re right, actually there is no harm done because the calculating work is done by the "jumpers". Many pool operators appreciate any help they can get, although doesn´t stay till the end, and will not take any action against them.

edit: by the way, you are free to launch your own pool, using pushpool with any front-end, to study the "problem" from a pool operator point of view

[koopa]

Hi,

I am getting the following errors each time I start bithopper, or when it switches pools:

Code:

Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
  File "C:\path\to\bithopper\pool.py", line 383, in <module>
    main()
  File "C:\path\to\bithopper\pool.py", line 377, in main
    update_call.start(117)
  File "C:\Python27\lib\site-packages\twisted\internet\task.py", line 163, in start
    self()
  File "C:\Python27\lib\site-packages\twisted\internet\task.py", line 194, in __
call__
    d = defer.maybeDeferred(self.f, *self.a, **self.kw)
--- <exception caught here> ---
  File "C:\Python27\lib\site-packages\twisted\internet\defer.py", line 133, in m
aybeDeferred
    result = f(*args, **kw)
  File "C:\path\to\bithopper\pool.py", line 253, in update_servers
    d = getPage(info['api_address'])
  File "C:\Python27\lib\site-packages\twisted\web\client.py", line 547, in getPage
    *args, **kwargs).deferred
  File "C:\Python27\lib\site-packages\twisted\web\client.py", line 525, in _make
GetterFactory
    from twisted.internet import ssl
  File "C:\Python27\lib\site-packages\twisted\internet\ssl.py", line 42, in <mod
ule>
    from OpenSSL import SSL
exceptions.ImportError: No module named OpenSSL
Trying to delag

I'm running bithopper on windows xp, with the latest phoenix miner. I'm not exactly sure if these errors are effecting the performance of bithopper, as it continues to rum seemingly unaffected.

Is this bad?

Yes. You need to install the python OpenSSL libraries on windows. https://launchpad.net/pyopenssl. I'm adding it to the readme.

Great, thanks c00w. The latest version seems to be working just fine now having installed openSSL. Not sure what was going on before but what i thought was pool hopping clearly wasn't  

My mini guide to getting this working on Windows XP has been updated: http://forum.bitcoin.org/index.php?topic=26866.msg351354#msg351354

[Sukrim]

So, what about some more advanced modes?

There are servers delaying statistics (especially deepbit), actually a lot of servers already do this already - how to deal with these?

Also it might be the case that statistics can be faked. Should we try to detect at least some obvious cases (negative amount of shares, fixed amount of shares...) and more obscure ones (statistical analysis of blocks solved in the past, calculating hashrate for this + averaging, then checking plausibility of current hashrate + shares reported)?

As far as I get it, the single most important thing to know with high confidence is the current amount of shares in any pool at each point of time. To estimate it, you need to know a hash rate and a point in time when the round started. Hash rates can be aproximated quite well after some time but I'm not sure how to detect (if everything is delayed for some time) if a new round started.
Weirdly, you know this actually globally REALLY fast, but as far as I looked, pools seem to generate a new address for each generated amount by default, which makes it hard to guess which one this belongs to until payouts (to you or known/trusted adresses) are being made from that block that are traceable to a generation.

A possible way would be to look at long polls (theoretically the first long poll should be from the pool that solved a block), connecting to the bitcoinds at the pool servers to get new blocks as fast as possible (and the first one from whom you get a new block is also more likely the one solving it).

What needs to be done anyways would be a website (google app engine or so) that records the block numbers of blocks that this pool has solved for each pool. Would also be important for other statistics like the ones on bitcoinwatch...
With these numbers then you could get the time it took to solve the blocks and so some hashrate estimations.
This could/should be even done as a plugin/extension to the alternative block explorer (recording for each block if it was mined by a known pool or is it still unknown who mined it)

Any more ideas to not rely on statistics by the servers themselves and still getting meaningful results? Might also be useful to not slow pools down - I bet the constant API calls hurt miners there far more (stale shares) than any hopping atm!

[organofcorti]

So, what about some more advanced modes?

Whoa there, Nellie! That's a huge amount of work.

I have no wish to be a wet blanket, but I think before you start down this road you might want to look at results first.

If we can get stats working on this - just enough to tell you what efficiency you're getting (coinage/expected coinage for a block based on the shares accepted from you) then you'll get a better idea of how many pools obfuscate their data. If you don't see many pools with less than 1.0 efficiency, then it's not an issue. Get rid of them and get a new pool. Plenty more pools in the ...er waterpark?

Anyway, it'll be a while before all pools do this and if they're sensible they'll go for a provably unhoppable solution of which there are already a few.

But if you have the time and inclination - go for it! You'll still need the stats to assess whether or not your solution works though.

[bigbeerjr]

Answers:
1) Pastebin?
Yes I like pastbin for large files. I like opening an issue on github even better.

My bad, next time I'll open a ticket.

2) More details?
Your internet probably died for a brief second. It then chewed through every server before defaulting to an extreme corner case I never expected. It will select mineco if literally all the other servers fail. I fixed that now though. However the LP shouldn't have been retried more than once for each server. Let me doublecheck that code.

Edit: 3) More details?
On looking through the logs I realized that some of my debug messages don't make any sense. What happened in your case is most of that spewing was your miner submitting incorrect LP request. Probably because it always submits them and it got extra desperate when it had no work. But I'm rewriting most of my debug output to make this clearer and the normal output to hide it.

Nothing went wrong with the server side LP code. How many miners are you running though? Thats a lot of clients being triggered on a server change.

Network connection was good throughout the rest of my network, maybe I just enabled too many miners at the same time. At this point I am unable to reproduce so I don't expect much to happen on your end. I have 7 pointing to bithopper.

[c00w]

There is actually another bug which could have caused this. It looks like I screwed up the delag call and didn't notice. So calls could fail slowly one after each other lagging out each pool in turn. And then you'd get the massive failover which happened to you.

Its fixed now. I think I should attach timestamps to the non debug calls also.

[Sukrim]

Alright, different suggestion:

Let's get this thing ready for Google App Engine! For small miners this would be much better/convenient than hosting it locally and with the free quotas it should still be possible to have this for free.

[c00w]

Google App Engine Eh? Maybe. Stats are first. Then a webpage to show them.

[jkminkov]

requesting easy way to remove some pools

[c00w]

If you are not adverse to source just add 'info':'' to the info for the pool in servers.

I'll add a command line option later tonight.

Is there a specific pool you don't want to use because its become hopper proof? Or is it just a case of a lot of pools and you don't want to make all of the accounts.

[jkminkov]

some pools produce more rejected shares and I preffer not to use them and sometimes if pool is DDOS-ed it'd be wise to turn it off for a while

[c00w]

some pools produce more rejected shares and I preffer not to use them and sometimes if pool is DDOS-ed it'd be wise to turn it off for a while

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.

[jkminkov]

it is just for me - btcguild, as Germany servers gone, US are too far

[nebiki]

it is just for me - btcguild, as Germany servers gone, US are too far

btcguild had issues with stale shares on their german servers, too. that's why i've switched to btcmine. 4% -> 0.7%. pm me when you get low stales on btcguild so i can switch back. thanks