bitHopper: Python Pool Hopper Proxy

[organofcorti]

yep, not sure how the decision making process works. but the most important bit for us - total round shares - are there. i asked the site operator if he could be bothered adding triplemining and nofeemining and his own json api - would give us an easy way to add those pools that have messy or non json apis.

I would gladly donate to that site if it would enable deepbit support in bithopper. 

deepbit support is only provided to donators

If techwtf provided a json feed then it would, and I'd be donating too.

btw, nofeemining.com is using https for their pool api page, which i think is causing the problem. Anyone know how to enable the --nocertficate or --insecure or whatever option in python?

[organofcorti]

ok, nofeemining is working, if you want to try (yes i know they're new and could scam us). use the code i have earlier, just change the api address to http://www.nofeemining.com/api.php

The person running nofeemining fixed the api within a few minutes of my request - so i'm def donating to them. I hope those of you that add nofeemining do too. a responsive, engaged pool owner is the best sort. helps get thing sorted quickly - one way or the other.

as an aside - i think it's a good idea to donate even a little bit - even 0.5% - to any pool you hop. adding 100ghps at round start is prolly a pain for the pool operators, so why you may wish to sweeten it for them and they may keep their pools hoppable longer.

[muyoso]

Wow, bitp.it just started having connection problems and within minutes their hashrate fell 50%.  Think they might be getting a little hopped.

[ahitman]

I already reward at least 1-2% donation to the pools that I use, make sure they can afford to upgrade the pools to support surges in hashrates from bitHopper.

Thanks for getting nofeemining to work, hope it turns out to be a legit pool.

P

[organofcorti]

Wow, bitp.it just started having connection problems and within minutes their hashrate fell 50%.  Think they might be getting a little hopped.

they were totally hopped:



but it was only a small hitch at the end there after stable hashrate for 2.5 hours. Don't think hopping was the issue. Mt Red has the ball now anyway, and bitpit are back to 50 Ghps.

[muyoso]

Wow, bitp.it just started having connection problems and within minutes their hashrate fell 50%.  Think they might be getting a little hopped.

they were totally hopped:



but it was only a small hitch at the end there after stable hashrate for 2.5 hours. Don't think hopping was the issue. Mt Red has the ball now anyway, and bitpit are back to 50 Ghps.

No, I don't think hopping caused the connection issues.  I am just amazed at how pervasive hopping is that it more than doubled their hash rate.  Makes me feel like a chump for not jumping on the hopping bandwagon sooner.  Used to "hop" manually only when long blocks came up with fairly good success, but nothing like what I am seeing with bithopper. 

[organofcorti]

Wow, bitp.it just started having connection problems and within minutes their hashrate fell 50%.  Think they might be getting a little hopped.

they were totally hopped:



but it was only a small hitch at the end there after stable hashrate for 2.5 hours. Don't think hopping was the issue. Mt Red has the ball now anyway, and bitpit are back to 50 Ghps.

No, I don't think hopping caused the connection issues.  I am just amazed at how pervasive hopping is that it more than doubled their hash rate.  Makes me feel like a chump for not jumping on the hopping bandwagon sooner.  Used to "hop" manually only when long blocks came up with fairly good success, but nothing like what I am seeing with bithopper. 

what sort of efficiencies you seeing? mine are mostly 1.5 to 1.8

[muyoso]

what sort of efficiencies you seeing? mine are mostly 1.5 to 1.8

I don't have any fancy stats setup or anything, but the first 24 hours I mined, which ended about an hour ago for me, I mined 92.3% more than I normally do.  Almost doubled what I should be making. That is only counting what is confirmed and unconfirmed.  Have unfinished rounds at ozco.in and bitp.it which should boost todays efficiency up pretty high when the blocks are finally found.  

Bitp.it has efficiency off the charts which is why I did so well today.

How do you calculate the efficiency on a per pool basis?  Are you using that proxy setup?

[organofcorti]

I just do it manually. For btcguild, eclipse, mt red and bitcoins-lc, they publish your block contribution history. Just take your total shares and total coinage. Then efficiency = <total coinage>/(<total shares>*50/<difficulty>).

[Tmoney]

ok, nofeemining is working, if you want to try (yes i know they're new and could scam us). use the code i have earlier, just change the api address to http://www.nofeemining.com/api.php

The person running nofeemining fixed the api within a few minutes of my request - so i'm def donating to them. I hope those of you that add nofeemining do too. a responsive, engaged pool owner is the best sort. helps get thing sorted quickly - one way or the other.

as an aside - i think it's a good idea to donate even a little bit - even 0.5% - to any pool you hop. adding 100ghps at round start is prolly a pain for the pool operators, so why you may wish to sweeten it for them and they may keep their pools hoppable longer.

I figured out the original issue.  You can have him disable http on the api agian.  This is what it should look like:

Code:

        'nofee':{'shares': default_shares, 'name': 'nofee',
           'mine_address': 'nofeemining.com:8332', 'user': nofee_user,
           'pass': nofee_pass, 'lag': False, 'LP': None,
           'api_address':'https://www.nofeemining.com/api.php', 'role':'mine',
           'user_api_address':'https://www.nofeemining.com/api.php?key=' + nofee_user_apikey},

The earlier example you posted had left out 'user_api_address' and combined nofee_user_apikey with 'api_address'.

[Sukrim]

Alright, already got some ideas how to break delayed stats? Currently it looks like pools would rather rework sensible parts of their code and screw with their users (adding intransparency) by delaying statistics than simply integrating an algorithm like PPLNS which is nearly the same as prop (when the pool is lucky, you get more), just without the chance of getting hopped ever.

At least Eligius' blocks can be fairly easily identified. As can the blocks from pools that are NOT delaying stats. The problem is, that now BTCguild and deepbit seem to delay, so there's a very high chance for a new block to have no known owner for an hour or more...
I have a few ideas already, but I'd like to collect some input from you to see some approaches you would take to deal with delayed/faked stats to still detect which pool solved which block.

[Clipse]

Im getting api errors with btcguild and mtred and then it doesnt pull the roundstats, anyone else?

[error]

Oh look, a new proportional pool.

[Sukrim]

"WTF man" is a proper expression when I read such stuff. Pool hopping is over 6 months old now, and people STILL don't care about their miners?!

At least a lot of medium sized pools recently are actively working on switching to secure payout systems. On one hand bad for me, because I earn less from there, but on the other hand great for their users and the community!
I wonder however what we can/shall do about deepbit and BTC guild...

[flower1024]

I wonder however what we can/shall do about deepbit and BTC guild...

how is deepbit handeld by multipool/multiclone?

the only way i can imagine is watching historic data and if they had bad luck, thank think they'll get lucky.

but this only works with an algorithm that spreads shares and does not stays within a pool ( i posted such a variant before; but it has too much rejects and i dont know how to handle them)

[dewon]

Does anyone know how to fix this:

EDIT: The answer was in readme 

Code:

[15:49:15] Error in user api for bitp
"[Failure instance: Traceback: <type 'exceptions.AssertionError'>: SSL support is not present\nC:\\Python27\\lib\\site-packages\\twisted\\internet\\task.py:194:__call__\nC:\\Python27\\lib\\site-packages\\twisted\\internet\\defer.py:133:maybeDeferred\nD:\\aaaphoenix\\bithopper\\stats.py:93:update_api_stats\nC:\\Python27\\lib\\site-packages\\twisted\\internet\\defer.py:1141:unwindGenerator\n--- <exception caught here> ---\nC:\\Python27\\lib\\site-packages\\twisted\\internet\\defer.py:1020:_inlineCallbacks\nD:\\aaaphoenix\\bithopper\\work.py:70:get\nD:\\aaaphoenix\\bithopper\\client.py:748:request\nD:\\aaaphoenix\\bithopper\\client.py:797:_request\nD:\\aaaphoenix\\bithopper\\client.py:698:_connect\nC:\\Python27\\lib\\site-packages\\twisted\\internet\\protocol.py:289:connectSSL\nC:\\Python27\\lib\\site-packages\\twisted\\internet\\protocol.py:239:_connect\nC:\\Python27\\lib\\site-packages\\twisted\\internet\\posixbase.py:434:connectSSL\n]"

Same error for all pools. I have api´s defined in psdws.py and logins in pools.py.

[organofcorti]

ok, nofeemining is working, if you want to try (yes i know they're new and could scam us). use the code i have earlier, just change the api address to http://www.nofeemining.com/api.php

The person running nofeemining fixed the api within a few minutes of my request - so i'm def donating to them. I hope those of you that add nofeemining do too. a responsive, engaged pool owner is the best sort. helps get thing sorted quickly - one way or the other.

as an aside - i think it's a good idea to donate even a little bit - even 0.5% - to any pool you hop. adding 100ghps at round start is prolly a pain for the pool operators, so why you may wish to sweeten it for them and they may keep their pools hoppable longer.

I figured out the original issue.  You can have him disable http on the api agian.  This is what it should look like:

Code:

        'nofee':{'shares': default_shares, 'name': 'nofee',
           'mine_address': 'nofeemining.com:8332', 'user': nofee_user,
           'pass': nofee_pass, 'lag': False, 'LP': None,
           'api_address':'https://www.nofeemining.com/api.php', 'role':'mine',
           'user_api_address':'https://www.nofeemining.com/api.php?key=' + nofee_user_apikey},

The earlier example you posted had left out 'user_api_address' and combined nofee_user_apikey with 'api_address'.

No.

This is my original:

 

Code:

'nofee':{'shares': default_shares, 'name': 'nofee',
           'mine_address': 'nofeemining.com:8332', 'user': nofee_user,
           'pass': nofee_pass, 'lag': False, 'LP': None,
           'api_address':'https://www.nofeemining.com/api.php?key=' + nofee_user_apikey, 'role':'mine'}

I defined the api as the user api address because i didn't know the pool stats address, but try it - it works fine for pool stats too. Just because you use the user api for user stats doesn't mean you can't use it for pool stats if they're there too. Hope this helps!

[organofcorti]

I wonder however what we can/shall do about deepbit and BTC guild...

how is deepbit handeld by multipool/multiclone?

the only way i can imagine is watching historic data and if they had bad luck, thank think they'll get lucky.

but this only works with an algorithm that spreads shares and does not stays within a pool ( i posted such a variant before; but it has too much rejects and i dont know how to handle them)

Wont work. Each new round length is still governed by a poisson process. On of the properties of the poisson process is that is has no memory of prior events. A short round wont make a long one more likely, nor visa versa. Sorry about that. I think though long polling is a help. ALso using the known hashrate of the pool means that we know how long an average round should be, and if it's over an hour will help us predict when it is most likely to end. Not much use for deepbit, but at least btcg have a few > 1hr rounds.

[flower1024]

Not much use for deepbit, but at least btcg have a few > 1hr rounds.

^^ but still we have the problem to know when btcg did found the block.

lp:
i am not sure. but we could try to monitor lp's and guessing that the first lp coming in is probably from the pool who found the block (still we have no clue about solo or pools we dont monitor)

still interested in the way multipool did with bit deepbit. reading perl is a PITA

[Aexoden]

Interestingly, the 'cheater function' shows that even hopping at <your shares>=<difficulty> has a 22% increase in effective hashrate (and thus coinage), which is better than eligius/arsbitcoin at 0% increase. So I it seems like it might pay have the jump off proportion of difficulty at 1.0 instead of 0.4

It's better to think in terms of the expected value of a share. If x is (50 / difficulty) The first share submitted in a round has an expected value of about 13x. The multiplier drops below 1 at approximately 0.4348 * difficulty. In other words, on average, there's no good reason to submit a share to a proportional pool after it has crossed that threshold, when SMPPS, PPLNS, or Geometric alternatives are available. (If for some reason you wanted to use Deepbit PPS as your backup, no idea why you'd do such a thing, you can wait until more like 0.525 * difficulty.)

Work is being done on identifying the who created each block with various heuristics, but it's not incredibly accurate yet, and it may prove difficult or impossible to be reliably accurate.