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
Topic: bitHopper: Python Pool Hopper Proxy - page 151. (Read 355816 times)
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
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
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.
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.
We should continue all ethics discussions at Pool hopping... ethical or not?.
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.
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.
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.
The actual displayed stats is delayed 0-60mins so hopping is pointless right now over there.
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*
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.
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.-no more stress if pool goes down from attacks
-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.
there is a thread, is hopping ethical.
this thread is deep enough without the politics.
this thread is deep enough without the politics.
we should open another thread to continue with this, didn't make myself clear enough ? English is not my native language 
you should try it and leave politics aside for the moment, we don't have enough data to say it's good or bad for the system.
you should try it and leave politics aside for the moment, we don't have enough data to say it's good or bad for the system.
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.-no more stress if pool goes down from attacks
-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.
1) : versus =?
They are actually the same. either works. I used : because it looks cleaner.
2) bitcoins.lc and a couple of other pools not working?
Um. yeah disabled for a reason. btcguild dropped stat support and bclc just changes its stuff constantly to stop people hopping it.
3)p2pool being the future?
I think its hoppable actually.
They are actually the same. either works. I used : because it looks cleaner.
2) bitcoins.lc and a couple of other pools not working?
Um. yeah disabled for a reason. btcguild dropped stat support and bclc just changes its stuff constantly to stop people hopping it.
3)p2pool being the future?
I think its hoppable actually.
Hello friends, has anyone successfully been able to hop at bitcoins.lc or btcguild? Thank you all,
[bclc]
name:bitcoins.lc
mine_address:bitcoins.lc:8080
api_address:https://www.bitcoins.lc/stats.json
role:disable
api_method:json
api_key:round_shares
user:FSkyvM
pass:xndzEU
If I enable this at all it crashed the whole program.
[bclc]
name:bitcoins.lc
mine_address:bitcoins.lc:8080
api_address:https://www.bitcoins.lc/stats.json
role:disable
api_method:json
api_key:round_shares
user:FSkyvM
pass:xndzEU
If I enable this at all it crashed the whole program.
... give away their edge for free, making it useless in the process.
that's called helping the community I think, sharing, being social... etci think it did:
-no more stress if pool goes down from attacks
-maximizing incentives for "small" miners
-hashing power spreading more evenly (various pools)
-pool operators finding bottlenecks in their infrastructure
-finding better payout schemes (transferring risk to pools, PPS - greater responsibility of pool ops. )
the list could go on
... give away their edge for free, making it useless in the process.
that's called helping the community I think, sharing, being social... etc... give away their edge for free, making it useless in the process.
that's called helping the community I think, sharing, being social... etc
I sort of agree with both of you, I call it being a socially sharing idiot
... give away their edge for free, making it useless in the process.
that's called helping the community I think, sharing, being social... etc
Regarding making a pool, you probably won't be able to finish it before all the pools are hopping proof. There are so few left now that it's putting a huge strain on them, so the last ones will probably give up soon. It is bound to happen after hopping has become as widespread as bitHopper has made it. It's quite interesting how so many bitcoin users willingly give away their edge for free, making it useless in the process.
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.
If it keeps pools from banning hoppers, then it might even out, and it'll make hoppers look better
@bb:
the problem is the payout. That's the main problem with multiclone.
You have to change BitHopper to use Usernames (easiest way would be bitcoin addressand not multible worker for every user), let BitHopper generate a stats file for every User on your Server.
This would be easy.
But you have to maintain a "Main Databaes" with all shares per server, per round, per use summited and then scrape the Data from your "main" account, to rate every users share and pay them out automaticaly.
in my optinion a git update is a lot easier and you don't have to depend on a admins account.
Multiclone had the problem, when a Pool Op baned his account with all the shares.
the problem is the payout. That's the main problem with multiclone.
You have to change BitHopper to use Usernames (easiest way would be bitcoin addressand not multible worker for every user), let BitHopper generate a stats file for every User on your Server.
This would be easy.
But you have to maintain a "Main Databaes" with all shares per server, per round, per use summited and then scrape the Data from your "main" account, to rate every users share and pay them out automaticaly.
in my optinion a git update is a lot easier and you don't have to depend on a admins account.
Multiclone had the problem, when a Pool Op baned his account with all the shares.
Sure. You would have to track what the submitted shares turned out to be worth.
You have the problem with account banning when you are using bitHopper as well.
Jump to: