bitHopper: Python Pool Hopper Proxy

[c00w]

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

[1713564867]

1713564867

[Sukrim]

As stats/website would most likely require a database that's why I suggested google app engine!
Just use a no-sql backend if possible please to make porting more easy later on.

[c00w]

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.

[Sukrim]

http://mining.mainframe.nl/ claims they use a hopper-proof algorithm. Might not be so useful to hop there.

Pool Hashrate: 1.55 GH/s
Pool Workers: 9

The above might be a reason why noone hopped there so far!

I think just deleting the respective line from "selectsharesResponse(response, args):" should be enough, right?
[Edit: it is, but throws errors (and continues) - I also commented the section in the "servers" dictionary]

Thanks for considering the database backend!

[organofcorti]

don't bother adding btcmine. They have AntiHopperTechnology added. With multipool the efficiency for 90000 shares with btcmine was 0.785.  

Bitpit are golden so far, I'd add them.

[bigbeerjr]

What is the deal with commit 22535ca0778280861f9ba5616194aa8cf2ded4b3?

[Sukrim]

Namecoin should by the way also be possible...

There are however just a few considerations:
You can estimate the "worth" of 1 NMC as the ratio between BTC difficulty and NMC difficulty. However this is not an exact measure, only what would be expected, and Namecoins are currently "undersold" on the Namecoin exchange.

A better estimate would be an average value, for example from http://www.nmcwatch.com/ (would be a simple regex). This would lead to increased queries though.

@bigbeer: seems to me he/she disabled the wrong pool, hm?!

[c00w]

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.

[paraipan]

keep up the good work man, bitcoins coming your way   (when I get them)

[c00w]

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.

[organofcorti]

@ c00w: Does entering an invalid or empty username/password combo cause problems?

The reason I ask is that atm if a user doesn't like a pool or the pool starts withholding rewards, giving too many stales, or starts using an antihopping algo users have to go into going to pool.py in starts commenting out lines It might be easier for users to simply delete the username and password to turn a pool 'off'.

An advantage for you (c00w) is that you wouldn't have to worry about finding out which pools are good or not, adding them or deleting them. You could just add the top (say) 15 pools, don't worry about whether they use antihopping or not and let everyone take their pick. The only extra work for you would be figuring out the pool's api.

Then, if the stats show a pool is crapping out, the user can just delete the relevant username and password. Or maybe comment them out.

tl;dr
1. c00w adds top 15 pools and their api.
2. Users enter the username/passwords/api (if necessary) only of pools they actually want to use.
3. Username/passwords/api can be added or deleted later on.

I think this would reduce duplication of effort for both you and users.

What do you think?

[enmaku]

Getting the following a lot:

Code:

Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
  File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 361, in c
allback
    self._startRunCallbacks(result)
  File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 455, in _
startRunCallbacks
    self._runCallbacks()
  File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 542, in _
runCallbacks
    current.result = callback(current.result, *args, **kw)
  File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 1076, in
gotResult
    _inlineCallbacks(r, g, deferred)
--- <exception caught here> ---
  File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 1020, in
_inlineCallbacks
    result = g.send(result)
  File "D:\bitHopper\work.py", line 140, in jsonrpc_getwork
    request.finish()
  File "D:\Python27\lib\site-packages\twisted\web\http.py", line 866, in finish
    "Request.finish called on a request after its connection was lost; "
exceptions.RuntimeError: Request.finish called on a request after its connection
 was lost; use Request.notifyFinish to keep track of this.

Doesn't seem to crash or anything, it recovers quickly, just thought I'd notify you
Edit: Scratch that, it is now happening so often that I'm getting more errors than actual traffic and an unreasonable amount of hashing power is falling to my backup pool, I've switched back to a previous build that still seems to work just fine, but whatever this is, it's BAD.

[zapeta]

Just FYI, Mineco.in has implemented a Pay Per Last N Shares reward scheme.  I'm guessing their change in payment scheme would require some adjustment of the pool hopper.

[c00w]

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

[zapeta]

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

Sorry, I misread Mineco as minecoin in the password file!  My apologies.

[organofcorti]

Code:

print "You just disabled the backup pool. I hope you know what you are doing"

*That* made me grin. The snarkier the better!

[enmaku]

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

Updated, it appears to be running and I haven't seen another error yet. I'm keeping my eyes open and fingers crossed though

Thanks! (damn you work fast)

[nob]

First things first, Thanks for BitHopper!

Second: Thought about ArsBitcoin as second Backup Pool? Like Eligius thery are using SMPPS. I mined on Ars when Eligius had problems, and had 0 Downtimes.

[enmaku]

Yet another wall of errors and half my hashrate is going to my backup pool (running at -f60 priority in case the proxy fails) 

Code:

Request.finish called on a request after its connection was lost; use Request.no
tifyFinish to keep track of this.
[00:09:22] RPC request [] submitted to bitclockers.com
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.no
tifyFinish to keep track of this.
Caught, jsonrpc_call insides
TCP connection timed out: 10060: A connection attempt failed because the connect
ed party did not properly respond after a period of time, or established connect
ion failed because connected host has failed to respond..

[organofcorti]

As far as fail over goes, try using the new poclbm. It haa built in failover to whatever your back up pool its at whatever -f you have for your main pool. Even if poclbm isn't as fast for you as whatever you're using, it might be worthwhile until bitHopper is working properly for you.