Topic: bitHopper: Python Pool Hopper Proxy - page 199. (Read 355823 times)
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.
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?!
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?!
What is the deal with commit 22535ca0778280861f9ba5616194aa8cf2ded4b3?
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.
Bitpit are golden so far, I'd add them.
http://mining.mainframe.nl/ claims they use a hopper-proof algorithm. Might not be so useful to hop there.
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!
Quote
Pool Hashrate: 1.55 GH/s
Pool Workers: 9
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!
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.
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.
Just use a no-sql backend if possible please to make porting more easy later on.
Huh. I was actually going to add btcmine as the second backup pool but I can't register on it since registration is closed.
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
it is just for me - btcguild, as Germany servers gone, US are too far
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.
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
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.
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.
requesting easy way to remove some pools
Google App Engine Eh? Maybe. Stats are first. Then a webpage to show them.
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.
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.
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.
Its fixed now. I think I should attach timestamps to the non debug calls also.
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.
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.
Quote
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.
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!
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!
Jump to: