Topic: bitHopper: Python Pool Hopper Proxy - page 88. (Read 355813 times)

I think they where bigger before switching over to LNSMPPS.
All the hoppers left, so they shrunk...

But I put them back in, if we all do they will grow again

backup_latehop is my implementation.

What it does:
Instead of selecting the backup pool with the lowest stale percentage (as far as I understood, that's the main selection criteria) it selects the backup pool with the highest pool share count.

This does NOTHING to your expected payout (especially not on PPS, but should also not change anything on PPLNS/Scored) and is just a counter measure against people irrationally leaving hopping proof pools on long rounds. It is intended to help these hopping safe pools (used as backup) who are "stuck" on longer rounds by giving them a boost in the end. Also some people seem to like to hop into backup pools that have a high CDF (which is irrational... but anyways). The description is not by me, and I'm generally not too happy with the descriptions in user.cfg.default --> I might do a change + pull request there.

Variance of backup payouts will increase if you add scored + PPLNS pools as backup additionally to the *PPS ones already present, but in the longer run there's no difference. There should be also no difference between backup + backup_latehop. backup prefers lower stale rates, but backup pools might get hopped hard and overload - backup_latehop should get lower loaded servers usually, as people choose to manually hop away on long rounds. I implemented it as a different method because it's hard to have both (there will always be a server that has the most shares and there will always be one that has the lowest stale rate - how to decide then?!) and people might want to choose.

I personally use backup_latehop, as I see it as a kind of "reward" from the more intelligent/rational miner type to pools. It is rational/intelligent to leave on prop. pools early, as you earn more. It is also rational/intelligent to hop into backup pools at any time and pools often suffer on longer rounds. Should this get exploited, you can always switch back to the usual backup method.

got this in the mail


but they are tiny..they have 4.2gh

I have an account there but unless everyone came, i'm not sure if i like mining the really small pools, they are below 43% for days. I'd like to see ryouiki's sim with slow pools. I guess it would all work out it just seems to take a lot of time.

add them back if ya want to. personally i bet they just missed us.

I agree, that'd be really handy.

Can someone please post and update a list of all pools worth hopping (and why)?
There was so many changes in the last days, I completely lost the overview which one is still good and which not.

We should keep an updated list somewhere please!

Thanks! 

I've disabled them again.  Can't be good for the cards ramping up to 100% then back down to zero every minute or so.

they appear to actually be down right now, could be the reason for the excessive reds today with them

Same account.

How do you go about referencing multiple workers in the BH config files?

I hope it works.  His pool is very valuable among the few we have to hop, and I would love to be able to use it effectively.

index.html is fracked
Red on dark gray? Seriously?

I sent him a pm

anyways this is the part that gave me hope. bolding mine.


his whole reason for coming in here was the high stale problem, as we were submitting bad data and he wanted to tell us to quit. That's the wreaking havoc. That is fixed. Also with the slice now, if we all use different numbers, we wont be hopping simultaneously onto the pools. Their hash rate with rise a bit less drastically. SO that pretty much addresses all the issues he has as a pool OP. ADD 1% of a few gigahashes...well i think the PM might have a chance.

New account or same account you used with bithopper?

Just checked out bitclockers thread on here, and in the second post he refers to us as "cheaters", so I doubt he will work with us.  Need to find a way to get around bitclockers nonsense.

Regarding BitClockers, I don't think it's IP based.

I've been testing Cherry Picker for the last day and a half and it's been heavily picking on BitClockers - to great profit, I'd add.

There is some fingerprint left through the proxy - maybe the UA is still wrong and giving away. Cherry Picker just controls poclbm directly and poclbm does the mining directly. BitClockers hasn't messed with any of my mining activities while using Cherry Picker.

After the last day of slicing eating everyone's lunch I would just reiterate that Ryo is working on getting slicing integrated into his fork. Let him do the work and then merge commit it.

Yep, I'd be happy to donate 1% as well.  I'm sure we all would.  

I would gladly donate 1% for him to disable the antihopper things, but I doubt he would ever do it.  Go back and read what he wrote.  If I remember correctly it was quite hostile.  


No matter what, I would love to get bitclockers working fully again because they pay out so well.

Ps, if you do contact him I would recommend doing so through pm, because his uers might not respond well to the pool op working with pool hoppers in exchange for a donation.

Probably the best bet would be to recontact him. He was upset for sure but he was also communicative. He sounded like he is someone who could be reasoned with. If one of you dont contact him I might.I'll tell him we have fixed our shit and if he fixes his, he can have 1% of my reward.

I would have to guess he is doing it through ip, but seriously if anyone has a solution please pm me it.