bitHopper: Python Pool Hopper Proxy

[c00w]

delete stats.db.

[1713856816]

1713856816

[1713856816]

1713856816

[1713856816]

1713856816

[1713856816]

1713856816

[hawks5999]

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.

From a project management perspective, I'd recommend letting ryo finish integrating slicing into his fork (which he's working on now, I believe) and then merge it all in together. He's doing time based, multi-threshold with dynamic penalty now and it will be all that including slicing when complete. Seems like merging the complete package would be easier than making it fit into another slicing implementation. Just my two bits.

[c00w]

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.

[hawks5999]

Ok, just shows what I don't understand about the architecture of the various forks.

But what I do understand is that share based hopping seems to be the least profitable based on simulation of the hopping approaches (share-based/time-based/ryouiki's current/flower-slice). Flower-slice seems the most profitable but jumps too much. The link in my previous comment has the information. Combining slice with time+multi-threshold+dyn-penalty seems like it will yield the highest results. I'm totally open to the idea that I may be completely wrong.

I'll add as well, that an even more final goal should be to incorporate all the work in the proxy into a client like Cherry Picker. Running both side by side has revealed to me that rejects will always tend to be higher with a proxy vs. a client. For a little more final goal, all this incorporated into the base miner software and configurable through something like guiminer (with an additional web frontend interface) would be panacea. Ah! to dream...

[hawks5999]

by the way, this guy might be on to something worth exploring...

[c00w]

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.

[hawks5999]

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

I'm sure you'll have it done before next difficulty increase

[phants]

Hi!
I use this as proxy for solo-mining.
How to make so that "getwork" for "shares" were considered?
The counter is at a stop.

Sorry for my English

[djex]

So digbtc changed their payout system to SMPPS / PPLNS so that ones off the list.

[bb]

So the slicing basically means that if there are multiple hoppable pools, they are all mined at the same time? (Or do I still not get it?)

[c00w]

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

[phants]

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

Yes
How it can be executed?

[paraipan]

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

Yes
How it can be executed?

you can do that easily with bitcoin-mining-proxy from Chris Howie, it uses mysql for storing all the data you need

[phants]

you can do that easily with bitcoin-mining-proxy from Chris Howie, it uses mysql for storing all the data you need

Thanks!
But it is too difficult for me

[paraipan]

you can do that easily with bitcoin-mining-proxy from Chris Howie, it uses mysql for storing all the data you need

Thanks!
But it is too difficult for me

hehe if you managed to install yourself a opencl gpu, a miner and the hopper proxy, setting-up a LAMP on linux or windows should be a piece of cake

[MaGNeT]

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.

Testing it!
How often should it hop?

[c00w]

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.

[joulesbeef]

So digbtc changed their payout system to SMPPS / PPLNS so that ones off the list.

that did not take long.. they didnt even give us a chance to piss them off.



so do you have to do anything to turn on slicing? I just ask as the console seems a bit calmer than the last flower version i tried.


and xaamp is a great lamp for noobs

If joulesbeef can figure out xaamp, you can too.

[MaGNeT]

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.

Do I have to upgrade?

It didn't hop yet... Stays at 1 pool (not the one with the lowest shares but under 30%)

[c00w]

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