bitHopper: Python Pool Hopper Proxy

[Fletch]

Has anyone compared the performance of bitHopper with, say, multiclone.us.to? I understand that using multiclone means I'm entrusting my hashes to a third party, but apart from that, are there performance differences?

As far as I can see, multiclone currently hops between btcguild, btcmine, mtred and slush (and reverts to "solo" mining if nothing fits) whereas bitHopper seems to use a set of different pools. Wouldn't it be most efficient to have the largest possible pool of pools to hop between?

[Moussekateer]

Has anyone compared the performance of bitHopper with, say, multiclone.us.to? I understand that using multiclone means I'm entrusting my hashes to a third party, but apart from that, are there performance differences?

As far as I can see, multiclone currently hops between btcguild, btcmine, mtred and slush (and reverts to "solo" mining if nothing fits) whereas bitHopper seems to use a set of different pools. Wouldn't it be most efficient to have the largest possible pool of pools to hop between?

Not sure how multiclone hops btcguld and slush since they have anti-hopping measures? Anyway Bithopper is a superior option as multiclone is essentially the same as someone running a copy of Bithopper on their server which everyone connects to. You can add more pools to the rotation in Bithopper if you want, it's quite straightforward.

[bb]

A centrally managed hopper has a lot of advantages actually. The biggest one being not having to worry about the hopper every day.

Just imagine a nice website that lets you enable/disable all the pools you like and some poor admin handling everything else...

[enmaku]

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.

[bb]

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.

[nob]

@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.

[murfshake]

Error in the cfg.

[mtred]
name:mtred  
mine_address:mtred.com:8337
api_address:https://mtred.com/api/user/key/%(mtred_user_apikey)s
role:mine
api_method:json
api_key:server,roundshares
#CHANGE THIS
#https://mtred.com/user/registration.html
user:scarium
pass:x
mtred_user_apikey:d91c52cfe1609f161f28a1268a2915b8

[btcg]
name:BTC Guild  
mine_address:us.btcguild.com:8332  
api_address:https://www.btcguild.com/pool_stats.php
user_api_address:https://www.btcguild.com/api.php?api_key=%(btcguild_user_apikey)s
role:mine
api_method:json
api_key:round_shares
user = c00w_test
pass = 1234
btcguild_user_apikey = 81a9081f4d5f32db7dbbed407cb5f686

Notice how for Mtred it is "user:scarium" and for btcg it is "user = c00w_test" with an "="

Which is proper or will it accept both?

I really want to figure out how to get just these 2 going and I already got MtRed up and running on it.  These are the only 2 I mine from, any help would be truly appreciated.  Thank you kindly,

[paraipan]

Error in the cfg.

[mtred]
...

Notice how for Mtred it is "user:scarium" and for btcg it is "user = c00w_test" with an "="

Which is proper or will it accept both?

I really want to figure out how to get just these 2 going and I already got MtRed up and running on it.  These are the only 2 I mine from, any help would be truly appreciated.  Thank you kindly,

yes it has that small error, put ":" instead of "=" and it should work, btcg isn't used anymore so mine at your risk

btcworld just gone rogue on stats

Code:

General Statistics
Current round started at:	Jul 13th, 08:03:38 pm
Current round duration:	291 hours
Valid shares for current round:	9,065
Shares for current round:	9,221
Previous round started at:	Jan 1st, 01:00:00 am
Previous round duration:	364342 hours
Valid shares for previous round:	0
Shares for previous round:	0

[bb]

@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.

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.

[gnaget]

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

[Grinder]

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.

[paraipan]

... give away their edge for free, making it useless in the process.

that's called helping the community I think, sharing, being social... etc

[Clipse]

... 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

[Grinder]

... give away their edge for free, making it useless in the process.

that's called helping the community I think, sharing, being social... etc

Sure, pool hopping has certainly helped the community a lot...

[paraipan]

... give away their edge for free, making it useless in the process.

that's called helping the community I think, sharing, being social... etc

Sure, pool hopping has certainly helped the community a lot...

i 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

[murfshake]

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.

[c00w]

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.

[Grinder]

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.

[paraipan]

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.

[joulesbeef]

there is a thread, is hopping ethical.


this thread is deep enough without the politics.