(thanks to mperth's stats at http://mksv.ath.cx/bit/stats.php)
Topic: bitHopper: Python Pool Hopper Proxy - page 192. (Read 355689 times)
I dont think I need to comment - except ... been 'hopped much, Mt Red?
(thanks to mperth's stats at http://mksv.ath.cx/bit/stats.php)
(thanks to mperth's stats at http://mksv.ath.cx/bit/stats.php)
Quote from: flower1024
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
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 now have a working implementation. i just starts a new server select whenever your client founds a share
its based on an old version with lp disabled completly - but (for me) its more stable.
(no password.py, no stats...) i don't know if i iwill upgrade the code. depends if i can go > 48hours without error
please remeber to change your pool accounts in pool.py!
here: www.k1024.de/dev.zip
I just noticed it switching from bitpit(that is still <100k shares) to arsbitcoin thats >800k shares..
Surely it shouldnt have switched at all ? It did switch back to bitpit after a few minutes, just curious why it would be doing this since it could overtime count for alot of wasted work on wrong pools.
Surely it shouldnt have switched at all ? It did switch back to bitpit after a few minutes, just curious why it would be doing this since it could overtime count for alot of wasted work on wrong pools.
I suspect there will always be people running proportional pools and doing nothing about pool hoppers. There's just too much demand (from miners) for proportional payouts, and not enough interest (again from miners) in stopping pool hoppers.
you are right, I have 4*5870 @ x8s moved when btcguild went down and will move them back to btcguild if they change proportional to something else
1) Bitclockers reenable?
Change their role in the servers dictionary in pool.py from info to mine
2) Stats?
Well I'm rewriting it now to use a database. And to show stats for all the servers we mine.
Mine are 133% for btcguild.
Around 800% for bitp.it. I withdrew some money and because their api doesn't tell me that its a rough estimate from what I remember.
Change their role in the servers dictionary in pool.py from info to mine
2) Stats?
Well I'm rewriting it now to use a database. And to show stats for all the servers we mine.
Mine are 133% for btcguild.
Around 800% for bitp.it. I withdrew some money and because their api doesn't tell me that its a rough estimate from what I remember.
Also, how do we re-enable bitclockers?
I suspect there will always be people running proportional pools and doing nothing about pool hoppers. There's just too much demand (from miners) for proportional payouts, and not enough interest (again from miners) in stopping pool hoppers.
I agree that this is the case right now and will be if there's no intervention. So ... now we have stats, why don't we start posting our efficiencies? Am I right in assuming the stats are based on all shares and coins received, not just for the current round?
Then it would be great to see how other people are doing efficiency wise, and even better to show on the front a of this thread what efficiencies we are getting, and to really drive the point home, how many extra coins that was for the hopper. Or, how many fewer coins the normal members of the pool got, assuming a particular total hopper hashrate (which is not so hard to find given the stats pages some prop pools have - just watch the drop off some of them have after 40% difficulty).
I'm not home so I can't start this off, but anyone want to post their stats so far?
I suspect there will always be people running proportional pools and doing nothing about pool hoppers. There's just too much demand (from miners) for proportional payouts, and not enough interest (again from miners) in stopping pool hoppers.
x8s currently voting (in german) on pool hopping countermeasures http://forum.bitcoin.org/index.php?topic=28848.msg362984#msg362984
I wouldn't bother adding them until they've decided what to do.
I think as a group we are definitely having a positive effect. Unfortunately, not everyone is going for changes from proportional reward systems - they're just trying to make it harder to figure out when rounds have started, or are banning suspected hoppers. These countermeasures are not impossible to overcome and just encourage an arms race in development.
When you consider this thread has been open for 7 days and is now 14 pages long, I'd say we have enough interested parties to make a responsive adversary. The only way pool hoppers will be permanently stopped is by the pool members pressuring the pool owners to come up with a non-proportional reward system that doesn't reward hopping.
Seeing this thread bounce to the top lots of times a day might be just what is needed.
I wouldn't bother adding them until they've decided what to do.
I think as a group we are definitely having a positive effect. Unfortunately, not everyone is going for changes from proportional reward systems - they're just trying to make it harder to figure out when rounds have started, or are banning suspected hoppers. These countermeasures are not impossible to overcome and just encourage an arms race in development.
When you consider this thread has been open for 7 days and is now 14 pages long, I'd say we have enough interested parties to make a responsive adversary. The only way pool hoppers will be permanently stopped is by the pool members pressuring the pool owners to come up with a non-proportional reward system that doesn't reward hopping.
Seeing this thread bounce to the top lots of times a day might be just what is needed.
Nah my ozco.in issues cleared up mostly with recent LP adjustments made by coow.
I am used to 400ms to btcguild and that still gave me <1% stales, packetloss would be the only devil and not so much latency.
I am used to 400ms to btcguild and that still gave me <1% stales, packetloss would be the only devil and not so much latency.
Quote
Rejects = stales , unless I missed some arbitrary details about how these 2 differ.
Stale shares have already been accepted and are not always credited [edit] as shares by a pool. Rejected shares are corrupted, not from the pools getwork [edit], or otherwise just plain wrong and are never accepted.
Quote
Yep, seems its ozco.in causing those 8-10% stales, new block on btcguild giving me normal ~0.5% stales.
Ozco.in is an Australian pool. They're great guys, and very responsive. However, being an Australian pool means that most of you are going to have pings of 200 to 400 ms, which is going to mean a few more stales than normal. I'm only a few thousand km away and I have 3% stales due to a tortuous path between me and western australia. If you're not in Australasia I wouldn't mine at Ozco.in if your stales are consistently high and you have a high ping there.
Just started to get these kinda errors:
Not sure whats causing it, or why its only happening on random miners connected to my bithopper server.
Code:
User timeout caused connection failure.
Caught, jsonrpc_call insides
User timeout caused connection failure.
Caught, jsonrpc_call insides
User timeout caused connection failure.
[00:46:20] RPC request [] submitted to eligius
[00:46:21] RPC request [] submitted to eligius
Not sure whats causing it, or why its only happening on random miners connected to my bithopper server.
They probably closed json stats on pools, I don´t get my stats either.
Just started to get these kinda errors:
Not sure whats causing it, or why its only happening on random miners connected to my bithopper server.
Code:
User timeout caused connection failure.
Caught, jsonrpc_call insides
User timeout caused connection failure.
Caught, jsonrpc_call insides
User timeout caused connection failure.
[00:46:20] RPC request [] submitted to eligius
[00:46:21] RPC request [] submitted to eligius
Not sure whats causing it, or why its only happening on random miners connected to my bithopper server.
You just nailed the stale share problem c00w, it´s the DNS servers. I had the google ones (8.8.8.8 and 8.8.4.4) and changed to my provider dns´s. Stale shares 5% from 25% in one hour, you rock 
About the ethical problem I really think we are helping pools to build up shares a little faster at start and keep up with the other pools, like filling a bucket of water faster at start and slowly pouring at the end. The hopper method keeps us, the miners, informed too when a pool it´s attacked,DOS´ed or down.
btw: stale=rejected (same thing) edit: not the same thing like I thought, sorry. Organofcorti explains it
About the ethical problem I really think we are helping pools to build up shares a little faster at start and keep up with the other pools, like filling a bucket of water faster at start and slowly pouring at the end. The hopper method keeps us, the miners, informed too when a pool it´s attacked,DOS´ed or down.
btw: stale=rejected (same thing) edit: not the same thing like I thought, sorry. Organofcorti explains it
Oh. Hmmm. My stale shares were quite high. But my rejects are at roughly oh 3.5%. And I'm having some network issues.
I thought most servers would accept stales but mark them as stales for you information.
I thought most servers would accept stales but mark them as stales for you information.
5) Triplemining?
Well it seems like a little bit of a ponzi scheme. I have no issues hopping them however.
Well it seems like a little bit of a ponzi scheme. I have no issues hopping them however.
I have no issues hopping in your tripplemining minipool however
1) Stale Share?
He's talking about stales not rejects.
I stopped bitHopper from changing servers with getworks that contain shares. That should help a bit. And fixed a bunch of LP issues. I am still see some artificially high stale share counts. Let me play with it a bit. I don't know where they are coming from currently though.
He's talking about stales not rejects.
I stopped bitHopper from changing servers with getworks that contain shares. That should help a bit. And fixed a bunch of LP issues. I am still see some artificially high stale share counts. Let me play with it a bit. I don't know where they are coming from currently though.
Rejects = stales , unless I missed some arbitrary details about how these 2 differ.
Just a follow up, seems the stales is still the same, it evened out at 10% stales (was ~15% before your last fix) and doesnt seem to be a ozco.in issue.
I notice it actually on btcguild aswell with LP still, strange that no one else using bithopper is reporting this, unless they to lazy
I notice it actually on btcguild aswell with LP still, strange that no one else using bithopper is reporting this, unless they to lazy
I'm seeing the same (mostly on ozco.in, but now also on arsbitcoin)
:-/
edit: i'm talking about rejects
(i'm using phoenix btw.)
1) Stale Share?
He's talking about stales not rejects.
I stopped bitHopper from changing servers with getworks that contain shares. That should help a bit. And fixed a bunch of LP issues. I am still see some artificially high stale share counts. Let me play with it a bit. I don't know where they are coming from currently though.
He's talking about stales not rejects.
I stopped bitHopper from changing servers with getworks that contain shares. That should help a bit. And fixed a bunch of LP issues. I am still see some artificially high stale share counts. Let me play with it a bit. I don't know where they are coming from currently though.
Well, at least it doesn't seem they have automations in place for banning hoppers... it might be that you triggered something since most likely a few people mined with the default accounts - thus making you look like a botnet.
Bitclockers seem very fishy (abnormally "bad luck" with some wild claims their bitcoind is being hacked or something), and they claim to have a different payout system now.
Next on the possible features list: logging in on websites + "manually" paying out asap to make sure you don't loose money when/if being banned.
Edit:
Another possible pool would be x8s.de. Stats are openly available + live --> but only after a login.
Edit2:
MtRed just found a block - and just take a look at that sudden 100 GH/s hash rate increase! https://mtred.com/site/page/view/about.html
Bitclockers seem very fishy (abnormally "bad luck" with some wild claims their bitcoind is being hacked or something), and they claim to have a different payout system now.
Next on the possible features list: logging in on websites + "manually" paying out asap to make sure you don't loose money when/if being banned.
Edit:
Another possible pool would be x8s.de. Stats are openly available + live --> but only after a login.
Edit2:
MtRed just found a block - and just take a look at that sudden 100 GH/s hash rate increase! https://mtred.com/site/page/view/about.html
And the moment I mentioned their 1 month bad luck in the thread they now have good luck. Their bad luck starts on June 15.
Just a follow up, seems the stales is still the same, it evened out at 10% stales (was ~15% before your last fix) and doesnt seem to be a ozco.in issue.
I notice it actually on btcguild aswell with LP still, strange that no one else using bithopper is reporting this, unless they to lazy
I notice it actually on btcguild aswell with LP still, strange that no one else using bithopper is reporting this, unless they to lazy
Mine isn't that high. I don't have stats since poclbm doesn't track it, but it's less than 10% for sure:
Code:
localhost:8337 14/07/2011 14:00:53, def52202, accepted
localhost:8337 14/07/2011 14:01:33, 8cd52f20, accepted
localhost:8337 14/07/2011 14:01:42, 9e7ada0c, accepted
localhost:8337 14/07/2011 14:01:44, 9b32622d, accepted
localhost:8337 14/07/2011 14:02:27, 54be5614, accepted
localhost:8337 14/07/2011 14:02:28, f26f6d65, accepted
localhost:8337 14/07/2011 14:02:29, 4ed9c523, accepted
localhost:8337 14/07/2011 14:02:31, 773171c4, accepted
localhost:8337 14/07/2011 14:02:34, f6a1ce11, accepted
localhost:8337 14/07/2011 14:02:50, 465e0050, accepted
localhost:8337 14/07/2011 14:03:03, 9e67fe05, accepted
localhost:8337 14/07/2011 14:03:15, a30828d9, accepted
localhost:8337 14/07/2011 14:03:16, 6d664135, accepted
localhost:8337 14/07/2011 14:03:28, 2b85be70, accepted
localhost:8337 14/07/2011 14:03:34, 1c11aac7, accepted
localhost:8337 14/07/2011 14:03:40, ccf82762, accepted
localhost:8337 14/07/2011 14:04:03, b5cfb474, accepted
localhost:8337 14/07/2011 14:04:12, 3c4f25cf, accepted
localhost:8337 14/07/2011 14:04:17, 85206078, accepted
localhost:8337 14/07/2011 14:04:40, 06f78bbd, accepted
localhost:8337 14/07/2011 14:04:55, 229beaf5, accepted
localhost:8337 14/07/2011 14:05:07, ae85dd8f, accepted
localhost:8337 14/07/2011 14:05:11, 635da02e, accepted
localhost:8337 14/07/2011 14:05:13, 646692dd, accepted
localhost:8337 289858 khash/s
Jump to: