Um not really. Its better to set pools to info instead of disable as long as their API works so that we don't mine on deepbit when those servers find a block.

@paraipanakos
I accidentally turned on some getwork debug statements. I'll move them over to debug.

Set btcguild role to mine_deepbit.

Oh and the payout is what money you have been paid at the pool. It is for doing efficiency calculations.

Um actually you can do both. If it gets the LP from btcguild first it mines btcguild. If it gets the Lp from deepbit first it mines deepbit. It only will only mine one based on a guess.

Yeah. Its 43% for prop pools. 10% for slush style pools.

I found the error. I should probably submit it to twisted.

@gentarkin
Yeah that is the behavior we want.

And I can't figure out where that stupid error is coming from...
EDIT: I fixed it. Update

This is very highly formalized guessing. It should work though. Basically if it gets the LP for the current block from deepbit first and no other blocks apis go down b/c they found a block it assumes it is from deepbit. Same thing for btcguild if you set that up. It will slice deepbit until another block is found by someone else.

Oh. I get that error as well. For some reason one of the LP sites is pushing out uniquely bad data. You can ignore it. I'll add an errBack for it.

@GenTarkin
Can you post your error logs? I can't fix things if I don't see what broke. And it seems to be working on my machine.

Update to python 2.7. I'll add in a catch but you won't get sorting.

EDIT: Catch is added, update and see if it works.

Run bitHopper with --startLP

And it doesn't poll the API. This is extremely sketchy LP based hopping.

Different scheduler options description?
Um, I'll throw a page on the github wiki.

EDIT:
Um apparently I hadn't created it before. I'm setting it so that anyone can edit it. Feel free to dump info on there or clean it up.

Don't mine bitclockers then. something about us and them mix badly. They have a QOS program which nukes submissions from us. We don't quite know how they do it.

So I added deepbit hopping support. Just start with --startLP. Otherwise nothing has changed. Oh and deepbit needs to have the role mine_deepbit. It should also work for btcg.

Oh and this is extremely beta. I wrote it in the last 2 hours. It runs and appears to work.

@simonk
Thats normal. generally miners are lazy and may drop lp connections as there own protocols time out. If your mining client barfs though when recieving an LP then there is something wrong.

Withholding winning shares.
The issue is it hurts us as well. A winning share has the payment to the pool encoded in its data. Its impossible to change that and still have it be a winning share. So you make less money.

@Eskimo
The default is time based slicing. Each server gets equal time per server round.
So if you start partway through a server round it will be bouncing between all three equally without weighting there percentage. Its simple and it works. If you want to use a more advanced slice scheduler user altsclicescheduler.

The default does not look at shares. It doesn't look at rate. It only does time per server round. By server round I mean the pools time to generate a block.

@magnet
Typo's everywhere! I think I fixed it again.

Update? I think I fixed it.

run with --debug

Can I convince you to give me a debug log? Those errors don't appear on my computer.

I fixed the default slicer to hop properly when pools go over the difficulty threshold and all schedulers should now ignore api_lag for backup pools.

It is the default. It should be showing users though. I updated to fix that bug which may fix everything. Or it may not. Can you update and check if it shows your workers?