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
Topic: bitHopper: Python Pool Hopper Proxy - page 104. (Read 355689 times)
Client based hopping?
Um probably. Eventually. A lot of work needs to be done before that happens.
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
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.
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.
by the way, this guy might be on to something worth exploring...
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...
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...
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.
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.
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.
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.
delete stats.db.
Code:
Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
File "G:\bitcoin\hopping\c00w-bitHopper-f597e2a\bitHopper.py", line 44, in __i
nit__
self.db = database.Database(self)
File "G:\bitcoin\hopping\c00w-bitHopper-f597e2a\database.py", line 37, in __in
it__
call.start(60)
File "G:\Python27\lib\site-packages\twisted\internet\task.py", line 163, in st
art
self()
File "G:\Python27\lib\site-packages\twisted\internet\task.py", line 194, in __
call__
d = defer.maybeDeferred(self.f, *self.a, **self.kw)
------
File "G:\Python27\lib\site-packages\twisted\internet\defer.py", line 133, in m
aybeDeferred
result = f(*args, **kw)
File "G:\bitcoin\hopping\c00w-bitHopper-f597e2a\database.py", line 96, in writ
e_database
self.update_user_shares_db()
File "G:\bitcoin\hopping\c00w-bitHopper-f597e2a\database.py", line 167, in upd
ate_user_shares_db
self.curs.execute(sql)
sqlite3.OperationalError: no such column: user
stats.py scrapes balances from user apis. Its just not seen a lot of love and supports like two sites.
why don't we scrape balances from pool pages? slush has lots of balances and stuff
@muyuso
Thats actually a bug. It should store the payouts but for some reason it is not working for basically everyone.
Thats actually a bug. It should store the payouts but for some reason it is not working for basically everyone.
You have to manually input earnings to see any efficiency ratings.
Do you enter a number every time you take money out of the pool (payout to your wallet) (is it additive)?, or do you update the BTC value occasionally with your pool BTC balance? And it's only good for the shares that bitHopper "knows" about, right? There's no way to enter previous shares into the database.
Yea, you have to only give it the rounds that bithopper has kept track of. Whenever you update the client with a new version it resets and I don't know of how to carry stats over. Its not additive, you have to add in a new total each time.
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.
Why do we need slicing? Can't we just mine on multiple pools simultaneously? That should work with current versions that sort the shares to the correct pools. If two pools roughly have the same amount of shares, just mine on both at the same time.
I just added a new LP system and a slice scheduler similar to flowers. New lp is on by default. Scheduler uses --scheduler SliceScheduler
wow, nice man, eh the LP stuff in beta-testing I guess, my production serv. wouldn't be very grateful if I mess up with it again
edit: testing in progress... just joking about the server
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.
Oh and ryou's dynamic penalty doesn't conflict with my code. Its just another item that needs to get added.
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.
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 think you should really add the work ryo did to your version, from my testing the dynamic penality system is working out alot more profitable.
It just makes it easier to move on with latest updates you make since ryo's version is pretty much done afaik and he is only updating it from time to time with few changes you make in the master version thus it would be less time wasting if we could put his fork into master version.
Correct me if I'm wrong but what c00w tries to do here with LP has nothing in common with ryo's penalty and slicing from flower altough it would be nice to have it all in one package
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.
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.
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 think you should really add the work ryo did to your version, from my testing the dynamic penality system is working out alot more profitable.
It just makes it easier to move on with latest updates you make since ryo's version is pretty much done afaik and he is only updating it from time to time with few changes you make in the master version thus it would be less time wasting if we could put his fork into master version.
Jump to: