@beef
You have to run with --scheduler SliceScheduler

@Magnet
You need the latest version to get Lp working. So no but it'll help. Does any pool have <40% shares? Besides that one?

No faster than once every 10 seconds if multiple pools are available to hop.

Oh and I found a bug in LP and fixed it. So it now actually looks like it works.

@bb
It means if you have three pools less than 30% it will route getworks from one for a bit then the next then the next. So it will spread your work evenly and make sure that you are in on every round at every pool. Basically it resolves the issue of being stuck on a slow pool with a low amount of shares while a faster pool gets three short rounds in a row.

@phant
What? You want to record the number of getworks? Shares/getwork?

The reasons flowers is the most profitable is he spreads the shares over all available pools pretty evenly. We just implemented the same system basically.

Share based slicing would make it so we work towards each pool getting exactly the same number of shares. This would be the most even and hopefully a little more profitable although not much.

So the reason flowers is more profitable is he hops more. Which is the point. He doesn't hop too much. In fact with our new system we should technically be able to do every getwork from a different pool if we had enough.

Client based hopping?
Um probably. Eventually. A lot of work needs to be done before that happens.

Um. But he's not using our scheduler system at all. So if he finishes someone is going to have to rewrite it anyway. And this code doesn't stop someone from merging in that scheduler. Thats the point of the new scheduler system. And slicing is really needed.

EDIT: And the final goal is to do share's submitted based slicing not time based.

EDIT2: But yeah we're going to eventually want ryo's scheduler merged into the main fork. But I don't have the time for doing a major merge so writing it from scratch was quicker and easier.

delete stats.db.

stats.py scrapes balances from user apis. Its just not seen a lot of love and supports like two sites.

@muyuso
Thats actually a bug. It should store the payouts but for some reason it is not working for basically everyone.

Thats the next step. And if you want to modify the slice scheduler to do that go ahead. But currently you can only have 1 current server so you need to change it in order to give a decent amount of work to each valid server. I want to slice it based on shares submitted to server in the current block. However a time based slice is a lot quicker to implement.

I just added a new LP system and a slice scheduler similar to flowers. New lp is on by default. Scheduler uses --scheduler SliceScheduler

Oh and ryou's dynamic penalty doesn't conflict with my code. Its just another item that needs to get added.

Merging ryo's version in:
I'm working on it. I don't understand why dynamic penalties + slicing are needed. But I'm merging in slicing right now. Then lots of cleanup. Then dynamic penalties. Especially for backup servers to represent their fee percentage.

How to completely disable the status page?
Um I can add an option I guess. Or just delete all of the stuff in bitSite's getchild besides return self.

I just finished reworking LP to poll all servers. I'm not sure if I should release it yet however as well all the testing I have done is with sending works and I'm waiting to see how it works when it receives an LP response.

Then its slicing time as that appears to be really needed. And its the oldest issue.

I plan on adding rejects and last time seen. Whats in the database is the shares for each worker and where they were submitted currently.

Tommorow I'll add an api_error and an api_delagger. should fix some of these problems.

Um that is because certain people wanted it to not be disabled on the first error. I bow to people who complain enough on issues which are minor.

@Sukrim
We don't want it to do api_disable or change the times because of network outages. Only for pool owners messing with us. Especially because there is no automated way to undo an api_disable. You have to do it manually with the website.
If you have a vision for how to clean up the api code send me a message or post it here or on github. My next project is cleaning up the LP code to cut down on rejects and to make it possible to hop without share scraping.

EDIT: On rereading you post I really need an api_error flag.

Yeah I'm going to fix it so deleting it like that works though. I just need to check for existence of user and if it is not there delete it.

@eskimo
It should work now.

deleting pools in user.py not deleting them in pool.py
It should. I'll look at it and see what I need to do to get it to work.

@macboy80
is your code in the public domain? I'd be glad to move it over to bitHopper when I have the time. Or a pull request would be awesome.

Um if by geometric you mean slush's algorithm it is hoppable.

expected payout is not how much you should make for the current block: It is how much you should make for all shares that have been submitted, correctly calculating for difficulty.