bitHopper: Python Pool Hopper Proxy

[c00w]

Errors with role:
Um check you pool.cfg and make sure very pool has its role specified. Thats the error. Some pool doesn't have a role.

[msb8r]

Also had Mt.Red Api disabled.  Restart fixed it.

seems like mtred slowed down their api update

My guess is that pool op did some maintenance. I had no updates on shares for about an hour, but things look fine now. Also after the no-update period the invalid block has been removed from unconfirmed balance..

[Sukrim]

yo have it tested sukrim ? I'll make a pull req if you know it works for the purpose

At least it throws no errors on my system but now works fine when built with PyInstaller. Dunno what'll happen exactly if these "except:" blocks are hit (but that's anyways not what I changed) but the change itself had no effect on both "from source" and "with runtime included" versions that I could observe.

[c00w]

Just make the pull request. I'll merge it in and if it breaks I'll fix it. Its minor.

[Clipse]

Just make the pull request. I'll merge it in and if it breaks I'll fix it. Its minor.

Can you have a look at my namecoin mining suggestion few posts up.

[c00w]

Um, I can see scraping the btc exchange rate and the nmc exchange rate to deal with the fact that difficulty doesn't match the price exchange, we already use the nmcdifficulty/btcdifficulty ratio. The website doesn't reflect that however.

So yeah we should scrape that and only use namepools if the two prices make sense. I agree completely.

EDIT: However I don't use namepools and I added in the capability for those who wish to. If you are using namepools you should check the exchange rates and make an informed decision. If you modify bitHopper to do it for you I welcome the pull request.

EDIT2: basically as long as nmc_price/nmc_difficulty > bitcoin_price/bitcoin_difficulty you should be mining namecoins. However if there are no pools to hop with bitcoin then if nmc_price/nmc_difficulty > .77 * bitcoin_price/bitcoin_difficulty you should hop them.

And now that I've though about it I might just code it in...

EDIT3: And if nmc price/difficulty > btc price/diff but there are no pools to hop then hop btc pools if nmc price/diff *.77 < btc price/diff

[muyoso]

My guess is that pool op did some maintenance. I had no updates on shares for about an hour, but things look fine now. Also after the no-update period the invalid block has been removed from unconfirmed balance..

MtRed had an invalid block too?  Thats like the third invalid block in the last couple of days for the various pools I mine.

[msb8r]

My guess is that pool op did some maintenance. I had no updates on shares for about an hour, but things look fine now. Also after the no-update period the invalid block has been removed from unconfirmed balance..

MtRed had an invalid block too?  Thats like the third invalid block in the last couple of days for the various pools I mine.

This was an invalid block from 5-6 days (?) ago, that stayed in the unconfirmed payout..

Edit: Invalid block was from 2011-07-21

[Clipse]

Um, I can see scraping the btc exchange rate and the nmc exchange rate to deal with the fact that difficulty doesn't match the price exchange, we already use the nmcdifficulty/btcdifficulty ratio. The website doesn't reflect that however.

So yeah we should scrape that and only use namepools if the two prices make sense. I agree completely.

EDIT: However I don't use namepools and I added in the capability for those who wish to. If you are using namepools you should check the exchange rates and make an informed decision. If you modify bitHopper to do it for you I welcome the pull request.

EDIT2: basically as long as nmc_price/nmc_difficulty > bitcoin_price/bitcoin_difficulty you should be mining namecoins. However if there are no pools to hop with bitcoin then if nmc_price/nmc_difficulty > .77 * bitcoin_price/bitcoin_difficulty you should hop them.

And now that I've though about it I might just code it in...

This will possibly create 2 extra effects, other than just pure profitibility right now for hoppers.

1.) burst of namecoin mining traffic - creating more interest possibly and also get to the next difficulty drop a bit faster albeit the drop would be less.
2.) possible value increase since more people might decide to hop it aswell thus creating higher hashing network mostly with bursts.

[muyoso]

This was an invalid block from 5-6 days (?) ago, that stayed in the unconfirmed payout..

Edit: Invalid block was from 2011-07-21

Oh, thats weird.

On a different note, does anyone have mine_slush working?  Its supposed to jump away from slush at .1*difficulty shares apparently, but the last time I tried it, it would stay until around .4*difficulty shares.  Seems other people have been experiencing the same thing.  I haven't tried it on the newest version of c00w's hopper though.

[paraipan]

pull request... done

@sukrim:  The code you released is public domain or you transfer copyright to c00w?

"mine_friendly" should make it as "mine_help" (my opinion)

[Sukrim]

Similar to mine_friendly (or charity or whatever) I'd like to develop a patch to extend the backup pools to all hopping proof ones and hop to the one(s) that have the highes share count currently.

Parapinaikos, that's not exactly as I suggested it - at least in the pool.py and website.py version of your pull request "application_path" isn't even used. Also __file__ will always exist, it will just point to a wrong path when being frozen ("compiled").

Edit:
For clarification: the code I posted was the whole "try:" block. Why did you do the changes, were there errors?

[c00w]

Yeah, mine_friendly is the wrong name. I might do a search and replace to change it to mine_charity.

EDIT:
__file__ doesn't always exist. just a heads up.

[paraipan]

Similar to mine_friendly (or charity or whatever) I'd like to develop a patch to extend the backup pools to all hopping proof ones and hop to the one(s) that have the highes share count currently.

Parapinaikos, that's not exactly as I suggested it - at least in the pool.py and website.py version of your pull request "application_path" isn't even used. Also __file__ will always exist, it will just point to a wrong path when being frozen ("compiled").

Edit:
For clarification: the code I posted was the whole "try:" block. Why did you do the changes, were there errors?

my bad, there were no errors I copy pasted poorly

[iopq]

at the current difficulty and exchange rates namecoin mining should never trigger

[Clipse]

at the current difficulty and exchange rates namecoin mining should never trigger

It wont the way its implemented atm however if implemented the way I proposed it will enable quite a few times optimally and profitably.

The approach I suggested(that c00w will implement afaik) is to stay for exactly the same variable time to difficulty so that you would be able to either A.) hit it lucky and get paid more than BTC worth or b.) get paid longterm the same worth as BTC.

Its actually quite a practical approach for the times that there is no prop pools <43% of difficulty. This method should also give you the chance of higher returns if lucky or similar returns if unlucky as EMPPS pools.

[Endeavour79]

Why does bithopper stop polling ozco.in stats after a while (approx ~1-2h)?

Any ideas?

[hawks5999]

@Hawks
How many servers and how many gh/s do you have if you make 10,000 shares in a night? Or are you on a 20 day trek?

3 servers. 10 miners (11 when my RMA comes back). About 2.5 Gh/s. Gone for 2.5 days. It looks like I've had 20k shares to deepbit as a backup in the last 24 hours

[bb]

Yeah, mine_friendly is the wrong name. I might do a search and replace to change it to mine_charity.

EDIT:
__file__ doesn't always exist. just a heads up.

__file__:
From docs: "If the loader does not make filename information available, this variable is set to None."
When does this happen??

[Starlightbreaker]

Anybody tried mtred beta?

it gives me slightly more stale than the regular one.