bitHopper: Python Pool Hopper Proxy

[Clipse]

i think it did:
-no more stress if pool goes down from attacks

"Flexible mining proxy" already did backup pools better, and now poclbm has built in support for it. If you mean that pools won't go down you're just wrong.

-maximizing incentives for "small" miners

Small miners have less to gain from it than larger ones, and of course they lose too if they use a proportional pool.

-hashing power spreading more evenly (various pools)

That makes no sense unless you desperately want to believe it. How can you call putting 150 GH on a 10-30 GH pool for a short while and then run away for days until it's profitable again spreading it evenly?

-pool operators finding bottlenecks in their infrastructure

Waste time changing things that would otherwise work just fine, instead of adding features their users want.

-finding better payout schemes (transferring risk to pools, PPS - greater responsibility of pool ops. )

Force pools to switch to payout schemes their users don't want.

the list could go on

I'm sure you think so.

He forgot the last unquestioned answer, "Dont like this, dont use this"

Just move along if its not for you.

[Sukrim]

EskimoBob mentioned in another thread earlier that we might have a better rep if instead of switching to a predetermined backup pool in such downtime, if we switched to whatever pool is on the longest block. Would dedicating JUST the hashes that would've gone to backup to such a pool be seriously detrimental (i.e. bring efficiency below 1) or could this be feasible? If it doesn't hurt anything and I'm just sending those shares to ars/eligius anyway I'd rather help a pool I hop out. It'd give us a better image and make pools more willing to stick with hoppable algos.

This would totally bring profits down. You would be joining a pool when it is least profitable. The profitability of eligius is constant.

We could join only non-prop pools then (as a "reward" for not using that broken algorithm). The longer term payout should anyways be 100% there and every *PPS pool might pay out either less than 100% in the short run (depts) or less than 100% forever (depts that cannot be covered by future luck - think of the switch to 25 BTC/block), so a bit more diversity in the backup pools can't hurt anyways.

All we'd need there would be a function to check which backup pool has the most shares currently and use this one. Then everyone can declare any non-prop pool as backup and support them as you wish.

[organofcorti]

EskimoBob mentioned in another thread earlier that we might have a better rep if instead of switching to a predetermined backup pool in such downtime, if we switched to whatever pool is on the longest block. Would dedicating JUST the hashes that would've gone to backup to such a pool be seriously detrimental (i.e. bring efficiency below 1) or could this be feasible? If it doesn't hurt anything and I'm just sending those shares to ars/eligius anyway I'd rather help a pool I hop out. It'd give us a better image and make pools more willing to stick with hoppable algos.

This would totally bring profits down. You would be joining a pool when it is least profitable. The profitability of eligius is constant.

We could join only non-prop pools then (as a "reward" for not using that broken algorithm). The longer term payout should anyways be 100% there and every *PPS pool might pay out either less than 100% in the short run (depts) or less than 100% forever (depts that cannot be covered by future luck - think of the switch to 25 BTC/block), so a bit more diversity in the backup pools can't hurt anyways.

All we'd need there would be a function to check which backup pool has the most shares currently and use this one. Then everyone can declare any non-prop pool as backup and support them as you wish.

Great idea Sukrim - I think that should be implemented as an option at least. Then for new prop pools we have the carrot and the stick - if you're prop we'll bail early, if you're XXPPS we'll jump in at the end and help finish a block.

@c00w - I'd like to try mining scoring pools as outlined a few pages earlier. I'm thinking of having a 0.1*<diff> cutoff for slush, for example. Is there a simple way to choose 'hopping off' points for each pool separately?

[Clipse]

So havnt seen it mentioned here, but dont bother with bitcoins.lc

The actual displayed stats is delayed 0-60mins so hopping is pointless right now over there.

[organofcorti]

So havnt seen it mentioned here, but dont bother with bitcoins.lc

The actual displayed stats is delayed 0-60mins so hopping is pointless right now over there.

Even if I am missing out on a bit, I'm still getting 150% there.

[bb]

We should continue all ethics discussions at Pool hopping... ethical or not?.

[Clipse]

So havnt seen it mentioned here, but dont bother with bitcoins.lc

The actual displayed stats is delayed 0-60mins so hopping is pointless right now over there.

Even if I am missing out on a bit, I'm still getting 150% there.

Weird, we are only getting into the mid to long range rounds.

Atm there is no way to get accurate share submission for <100k share rounds , these are the rounds we would score at the most.

At their current ~400gh poolspeed without hoppers , the shares seem to first refresh on a new round ~90k mark, and recently they had couple of quick rounds that any hopper would miss out on.

[rampone]

Mmmhhh, sorry Mister triplemining op. But at least u had some hashrate while i was away.

Lesson 1: never leave your hopper longer than 4 hours

And now I am wondering: Did mtred find a block or also gone rogue?h

[muyoso]

Mmmhhh, sorry Mister triplemining op. But at least u had some hashrate while i was away.

Lesson 1: never leave your hopper longer than 4 hours

And now I am wondering: Did mtred find a block or also gone rogue?h

32minute block.  Was awesome.

[c00w]

Custom difficulty cutoffs?
Yeah. That would be pretty quick. I'll add it in. use mine_slush as role for a 10% cutoff.

[bb]

What is the general purpose of custom cutoffs? (Wasn't there someone showing what the ideal cutoff was?)

[rampone]

with mtred: Never mined, they minted a new block!! hoppersden invite anyone 4 me plz?

[organofcorti]

So havnt seen it mentioned here, but dont bother with bitcoins.lc

The actual displayed stats is delayed 0-60mins so hopping is pointless right now over there.

Even if I am missing out on a bit, I'm still getting 150% there.

Weird, we are only getting into the mid to long range rounds.

Atm there is no way to get accurate share submission for <100k share rounds , these are the rounds we would score at the most.

At their current ~400gh poolspeed without hoppers , the shares seem to first refresh on a new round ~90k mark, and recently they had couple of quick rounds that any hopper would miss out on.

.

How are you noticing this - is it a difference between json and website? I'm at work and can't check, sorry.

[organofcorti]

Custom difficulty cutoffs?
Yeah. That would be pretty quick. I'll add it in. use mine_slush as role for a 10% cutoff.

Excellent <rubs hands> I'll try it on all non-XXMPS/Meni algo pools. See how we go compared to theory.

[bigbeerjr]

with mtred: Never mined, they minted a new block!! hoppersden invite anyone 4 me plz?

Is there something special to get mtred working? I keep getting error decoding json, and it shows up as red on the stats page, and won't switch.

Thanks!

[muyoso]

How are you noticing this - is it a difference between json and website? I'm at work and can't check, sorry.

I have been mining bitcoins.lc for a while and have been monitoring it.  For the last few days I have only been able to jump to bitcoins.lc 30 minutes into a block which is like 177k shares.  I asked Jine straight up what was going on and he replied that he is randomly delaying stats 0-3600 seconds. 

[organofcorti]

@c00w - while I've got you - are shares in the db assigned a difficulty level? My efficiency has been through the roof lately, and while this might be because I've only gone on backup once this week - today - I was just wanting to make sure that all shares weren't given the same difficulty since the efficiency will look better compared to the total coins you have and artificially elevate the efficiency. Or should we reset the db at each diff increase? Sorry if this has already been covered.

[c00w]

mtred should work by default. Are you using the latest version?
Oh and mine_nmc and mine_slush are added.

Shares are stored in database as difficulty stamped (and once i add workers, difficulty and worker stamped). I'm not sure if the network code is taking that into account or if we serve the data like that. I should just serve an expected for each server. I'll take a look.

[organofcorti]

How are you noticing this - is it a difference between json and website? I'm at work and can't check, sorry.

I have been mining bitcoins.lc for a while and have been monitoring it.  For the last few days I have only been able to jump to bitcoins.lc 30 minutes into a block which is like 177k shares.  I asked Jine straight up what was going on and he replied that he is randomly delaying stats 0-3600 seconds. 

I'm still not sure how you would tell - if stats are delayed by an hour, then you'd still get a full amount of shares because bitHopper would still hop off at the point that it thought was correct. It sounds like what you're talking about is more like delaying an update to let everyone know a block has started?

Either way, is the website total shares the same as or different to the json total shares?

[muyoso]

I'm still not sure how you would tell - if stats are delayed by an hour, then you'd still get a full amount of shares because bitHopper would still hop off at the point that it thought was correct. It sounds like what you're talking about is more like delaying an update to let everyone know a block has started?

Either way, is the website total shares the same as or different to the json total shares?

What happens is this.  Say a round is six hours and 30 minutes long.  Well the website will report the round as 7 hours long, and then suddenly report that round as six hours and 30 minutes long and report the new round as starting 30 minutes ago.  So then the hopper switches usually because its only like 170k shares but you have essentially missed out on the most valuable mining that there is.  You still make money over Ars on short to normal length rounds, but on long rounds your shares are essentially worthless.