Topic: bitHopper: Python Pool Hopper Proxy - page 49. (Read 355823 times)
LOL! So, question what exactly is the diff between the old default scheduler and the new one. I notice the old one doesnt list the "slice" column...
It was paraipanakos!! I knew it! He always had it in for OldDefaultScheduler.
You should code into the next hopper, If user = paraipanakos then mine+charity everything
You should code into the next hopper, If user = paraipanakos then mine+charity everything
Ok who erased OldDefaultScheduler from the wiki?
it's a valid scheduler..which some think might be the best one there is. Just cause it is called old, no need to erase it from existence.
it's a valid scheduler..which some think might be the best one there is. Just cause it is called old, no need to erase it from existence.
me did it
, sorry
Wiki history shows who did what. I'll track em down
Ok who erased OldDefaultScheduler from the wiki?
it's a valid scheduler..which some think might be the best one there is. Just cause it is called old, no need to erase it from existence.
it's a valid scheduler..which some think might be the best one there is. Just cause it is called old, no need to erase it from existence.
Um, I just redid the whole deepbit system again to produce estimated share counts. So every scheduler now works!
kick butt c00w
and i just submitted my first deepbit share.. WOOHOO
lol
one the one so far
but I havent upgraded yet. i'm on 1.3-63
@simonk83 happened to me a moment ago with mt.red , just deleted the log thinking it's a connection prob with them, seems like it happens with a server it chosen by bH, please run it with if you dont mind
Code:
--debug > output.log
I realised I wasn't quite on the latest, so I've done a pull. If it happens again I'll run it via debug and grab the log. Seems OK for now though (although it was running for a few hours prior to those errors happening).
Um, I just redid the whole deepbit system again to produce estimated share counts. So every scheduler now works!
@simonk83 happened to me a moment ago with mt.red , just deleted the log thinking it's a connection prob with them, seems like it happens with a server it chosen by bH, please run it with if you dont mind
Code:
--debug > output.log
Hope everybody was on MtRed. 
Same goes for ozcoin I guess.
Btw, do we actually know if the 10% slush mining will work out?
Oops, just saw loads (more than I manage to capture) of this as my miners went idle:
Followed straight after by:
Code:
[12:15:11] RPC request [getwork] submitted to PolMine.pl
[12:15:11] RPC request [getwork] submitted to PolMine.pl
[12:15:11] RPC request [getwork] submitted to PolMine.pl
[12:15:11] RPC request [getwork] submitted to PolMine.pl
[12:15:12] RPC request [getwork] submitted to PolMine.pl
[12:15:12] RPC request [getwork] submitted to PolMine.pl
[12:15:13] RPC request [getwork] submitted to PolMine.pl
[12:15:13] RPC request [getwork] submitted to PolMine.pl
[12:15:14] RPC request [getwork] submitted to PolMine.pl
[12:15:14] RPC request [getwork] submitted to PolMine.pl
[12:15:15] RPC request [getwork] submitted to PolMine.pl
[12:15:15] RPC request [getwork] submitted to PolMine.pl
[12:15:15] triple: 858469
[12:15:15] RPC request [getwork] submitted to PolMine.pl
[12:15:15] RPC request [getwork] submitted to PolMine.pl
[12:15:16] RPC request [getwork] submitted to PolMine.pl
[12:15:16] RPC request [getwork] submitted to PolMine.pl
[12:15:17] RPC request [getwork] submitted to PolMine.pl
[12:15:17] RPC request [getwork] submitted to PolMine.pl
[12:15:18] RPC request [getwork] submitted to PolMine.pl
[12:15:18] RPC request [getwork] submitted to PolMine.pl
[12:15:19] RPC request [getwork] submitted to PolMine.pl
[12:15:19] RPC request [getwork] submitted to PolMine.pl
[12:15:19] RPC request [getwork] submitted to PolMine.pl
[12:15:19] RPC request [getwork] submitted to PolMine.pl
[12:15:20] RPC request [getwork] submitted to PolMine.pl
[12:15:20] RPC request [getwork] submitted to PolMine.pl
[12:15:21] RPC request [getwork] submitted to PolMine.pl
[12:15:21] RPC request [getwork] submitted to PolMine.pl
[12:15:21] slush: 2500803
[12:15:22] RPC request [getwork] submitted to PolMine.pl
[12:15:22] RPC request [getwork] submitted to PolMine.pl
[12:15:23] RPC request [getwork] submitted to PolMine.pl
[12:15:23] RPC request [getwork] submitted to PolMine.pl
[12:15:23] RPC request [getwork] submitted to PolMine.pl
[12:15:23] RPC request [getwork] submitted to PolMine.pl
[12:15:24] mtred: 264683
[12:15:25] Error in pool api for itzod
[12:15:25] RPC request [getwork] submitted to PolMine.pl
[12:15:25] RPC request [getwork] submitted to PolMine.pl
[12:15:26] RPC request [getwork] submitted to PolMine.pl
[12:15:26] RPC request [getwork] submitted to PolMine.pl
[12:15:27] RPC request [getwork] submitted to PolMine.pl
[12:15:27] RPC request [getwork] submitted to PolMine.pl
[12:15:28] RPC request [getwork] submitted to PolMine.pl
[12:15:28] RPC request [getwork] submitted to PolMine.pl
[12:15:28] RPC request [getwork] submitted to PolMine.pl
[12:15:28] RPC request [getwork] submitted to PolMine.pl
[12:15:29] RPC request [getwork] submitted to PolMine.pl
[12:15:29] RPC request [getwork] submitted to PolMine.pl
[12:15:30] RPC request [getwork] submitted to PolMine.pl
[12:15:30] RPC request [getwork] submitted to PolMine.pl
[12:15:31] RPC request [getwork] submitted to PolMine.pl
[12:15:31] RPC request [getwork] submitted to PolMine.pl
[12:15:32] RPC request [getwork] submitted to PolMine.pl
[12:15:32] RPC request [getwork] submitted to PolMine.pl
[12:15:32] Server change to mtred
Followed straight after by:
Code:
[12:16:14] RPC request [getwork] submitted to BTCServ.net
[12:16:16] RPC request [04130000] submitted to OzCo.in
[12:16:20] RPC request [getwork] submitted to BTCServ.net
[12:16:21] RPC request [getwork] submitted to BTCServ.net
[12:16:22] RPC request [getwork] submitted to BTCServ.net
[12:16:22] RPC request [0d9c5000] submitted to OzCo.in
[12:16:22] triple: 859632
[12:16:22] bitp: 1214343
[12:16:22] RPC request [getwork] submitted to BTCServ.net
[12:16:23] RPC request [getwork] submitted to BTCServ.net
[12:16:23] RPC request [getwork] submitted to BTCServ.net
[12:16:24] RPC request [getwork] submitted to BTCServ.net
[12:16:24] RPC request [getwork] submitted to BTCServ.net
[12:16:24] bcpool: 2539522
[12:16:24] RPC request [getwork] submitted to BTCServ.net
[12:16:25] RPC request [getwork] submitted to BTCServ.net
[12:16:25] RPC request [getwork] submitted to BTCServ.net
[12:16:25] RPC request [getwork] submitted to BTCServ.net
[12:16:26] slush: 2525203
[12:16:26] RPC request [getwork] submitted to BTCServ.net
[12:16:26] RPC request [getwork] submitted to BTCServ.net
[12:16:27] RPC request [getwork] submitted to BTCServ.net
[12:16:27] RPC request [getwork] submitted to BTCServ.net
[12:16:27] RPC request [getwork] submitted to BTCServ.net
[12:16:27] RPC request [getwork] submitted to BTCServ.net
[12:16:28] Error in pool api for itzod
[12:16:28] RPC request [getwork] submitted to BTCServ.net
[12:16:28] RPC request [getwork] submitted to BTCServ.net
[12:16:29] RPC request [getwork] submitted to BTCServ.net
[12:16:29] RPC request [getwork] submitted to BTCServ.net
[12:16:30] RPC request [getwork] submitted to BTCServ.net
[12:16:30] RPC request [getwork] submitted to BTCServ.net
[12:16:30] RPC request [getwork] submitted to BTCServ.net
[12:16:30] RPC request [getwork] submitted to BTCServ.net
[12:16:31] RPC request [getwork] submitted to BTCServ.net
[12:16:31] RPC request [getwork] submitted to BTCServ.net
[12:16:32] RPC request [getwork] submitted to BTCServ.net
[12:16:32] RPC request [getwork] submitted to BTCServ.net
[12:16:33] RPC request [getwork] submitted to BTCServ.net
[12:16:33] RPC request [getwork] submitted to BTCServ.net
[12:16:33] RPC request [getwork] submitted to BTCServ.net
[12:16:33] RPC request [getwork] submitted to BTCServ.net
[12:16:34] RPC request [getwork] submitted to BTCServ.net
[12:16:34] RPC request [getwork] submitted to BTCServ.net
[12:16:35] RPC request [getwork] submitted to BTCServ.net
[12:16:35] RPC request [getwork] submitted to BTCServ.net
[12:16:36] RPC request [getwork] submitted to BTCServ.net
[12:16:36] RPC request [getwork] submitted to BTCServ.net
[12:16:36] RPC request [getwork] submitted to BTCServ.net
[12:16:36] RPC request [getwork] submitted to BTCServ.net
[12:16:37] RPC request [getwork] submitted to BTCServ.net
[12:16:37] RPC request [getwork] submitted to BTCServ.net
[12:16:38] RPC request [getwork] submitted to BTCServ.net
[12:16:38] RPC request [getwork] submitted to BTCServ.net
[12:16:38] btcserv: 120273
[12:16:39] RPC request [getwork] submitted to BTCServ.net
[12:16:39] RPC request [getwork] submitted to BTCServ.net
[12:16:39] RPC request [getwork] submitted to BTCServ.net
[12:16:39] RPC request [getwork] submitted to BTCServ.net
[12:16:40] RPC request [getwork] submitted to BTCServ.net
[12:16:40] RPC request [getwork] submitted to BTCServ.net
[12:16:40] btcmonkey: 3516104
[12:16:41] RPC request [getwork] submitted to BTCServ.net
[12:16:41] RPC request [getwork] submitted to BTCServ.net
[12:16:42] RPC request [getwork] submitted to BTCServ.net
[12:16:42] RPC request [getwork] submitted to BTCServ.net
@joulesbeef: ok, if you're going to use extremes of pool speed or hashrate , sure. Variance will kill you and long term becomes months rather than weeks or days. But then over the *very* long term, oDS will still win over slice.
Choosing larger pools (~50Ghps and above) is a simpler and more efficient was of reducing variance. Yes - the more pools the better - but the efficiency loss due to having to use slice to reduce variance might be an issue.
Edit: Also don't forget you wouldn't have only been mining on bloody's the whole time, only when it had fewer total shares than any other pool. Mining on a small pool is risky, so your is to increase risk to get more pools and possibly a better payout. But because of the increased risk you need slicing to reduce variance, which also reduces payout.
and I'd like to make some chartporn for you (you know you want it...) but I really don't know how to model slice until until someone explains exactly how it works inmining on a small pool all circumstances. PM me if you have something I can use (ie a decision tree, flowchart or some other human language algo) and not just the actual code.
Choosing larger pools (~50Ghps and above) is a simpler and more efficient was of reducing variance. Yes - the more pools the better - but the efficiency loss due to having to use slice to reduce variance might be an issue.
Edit: Also don't forget you wouldn't have only been mining on bloody's the whole time, only when it had fewer total shares than any other pool. Mining on a small pool is risky, so your is to increase risk to get more pools and possibly a better payout. But because of the increased risk you need slicing to reduce variance, which also reduces payout.
Quote
I'd like to see some more graphs and math before i am sold.
and I'd like to make some chartporn for you (you know you want it...) but I really don't know how to model slice until until someone explains exactly how it works inmining on a small pool all circumstances. PM me if you have something I can use (ie a decision tree, flowchart or some other human language algo) and not just the actual code.
@c00w just happened to see this in log
it's for real ? or just a guess
Code:
2011-08-09 03:33:22+0200 [HTTP11ClientProtocol,client] New Block: d8f14ee933cee60c1ab4d1232f4c60b3c9451a3a0bc43f9b0000080e00000000
2011-08-09 03:33:22+0200 [HTTP11ClientProtocol,client] Block Owner triple
2011-08-09 03:33:22+0200 [-] LP Call eu1.triplemining.com:8344/LP
it's for real ? or just a guess
Quote
The problem with slow pools isn't that they pay less, but that you put more eggs in one basket and if the round goes long you lose much more. But if the round is short, you gain much more.
true but in my example, their 100% was 20 days, i dont doubt in the long run it works out, but it could be several months before a short round. If they had a 600% block for the first one, it would be 4 months waiting on that short round to make it all worth it.
Quote
But tell me: have you plotted your daily efficiency over time? Say, daily shares and daily earnings over two weeks? Let me make a prediction: I bet you 1 bitcoin that oldDefaultScheduler will approach the theoretical maximum for the number of pools you use, but slicers will not.
Reason: Since variation due to pool luck is reduced, the short term efficiency might seem better than oldDefaultScheduler. But for two weeks of one compared to the other and the same shares submitted per day (and taking any difficulty changes into account) oDS will come out ahead since it will have more early shares than the slicer.
Reason: Since variation due to pool luck is reduced, the short term efficiency might seem better than oldDefaultScheduler. But for two weeks of one compared to the other and the same shares submitted per day (and taking any difficulty changes into account) oDS will come out ahead since it will have more early shares than the slicer.
nope i havent. I dont 100% disagree with you, but had I not been slicing, i would have been on bloodies for days.. weeks if yall hadnt decided to mine there and so far they havent found a block, in that time others had short rounds. I know it is more complex than that but it sure seems to me like several days would have been wasted.. sure after a year if bloody hits.. if they dont change from prop over that time, or start to delay stats.. i might make up for all that time i wasted.
and on that last part
2 slow pools 5% a day.. we start pool one starts at 1% when we start the hopper the pool two at 0%
since both pools are at same hash rate we should stay on pool two until pool one finds a block.
pool one finds a block at 70%(or really close to 14 days)
without slicing.. reward 0 for 2 weeks.
with slicing i mined for half of that time it took to get 70%.. each share about 1.42 times average winner slicing.
Ok i know what you are saying.. it has been 2 weeks and now i am back on pool one at 0% while pool 2 is going above 70%.. as long as pool one hits a block before passing pool two.. we got mega payday that makes up for the last 2 weeks right?
lets see.
pool 2 is still having bad luck but after 2 weeks they find a block at 140%..
now after 2 weeks pool one is at 70% and then the admin decides to stop sending out stats, we have no clue when the round ends, we just ahve to wait until we get paid and the admin has decided to delay that so you can use that info to hop.
default.. i did pool 2 for 70% last week and pool one for 70 this week.. no pay for pool one.. paid on pool 2 my shares on pool 2 are worth 0.72 average value.
slicing i did 70 shares on pool two and 70 on pool one.(35 week one, 35 for week 2.. each). I get the same.. it is a tie.. my shares on pool 2 are worth 0.72
one month average.. slice wins
.
( the guy messing with stats has no baring on anything except to end the game. I think i showed the need to reduce variance in the first two weeks.. but since we are quitting this pool our future payout will be the exact same.. this leaves us with the last prop pool as everyone as gone anti hopping.. slice wins for all time)
yeah I am doing extremes.. and yeah I can see it will still work out over time, but time isnt certain in the bitcoin world and it is pretty damn uncertain in the hopper world.
I'd like to see some more graphs and math before i am sold.
Um. Enable everything which produces valid share counts.
Right, I might need a list of which work
Maybe I'll wait until it's more defaulterised
Um. Enable everything which produces valid share counts. If in doubt: don't. Then add deepbit with role:mine_deepbit in user.cfg.
Then start bitHopper with --startLP.
Soon that option will be by default once I get the deepbit share estimator working.
If any errors appear: Tell me.
Then start bitHopper with --startLP.
Soon that option will be by default once I get the deepbit share estimator working.
If any errors appear: Tell me.
Hope everybody was on MtRed.
Deepbit Hopping is finally working for the default slice scheduler. I'm going to add in an estimation function and then get it working for the old scheduler since it looks like that might be a better scheduler.
Cool. Can anyone give me (and plenty others I'm sure
) a quick rundown on how to get this working? Something about enabling every pool (even ones you don't use) and setting them all to info?
Deepbit Hopping is finally working for the default slice scheduler. I'm going to add in an estimation function and then get it working for the old scheduler since it looks like that might be a better scheduler.
Quote
Ok i havent done the math but lets say WE got 1 supper slow, and 3 fast pools.
I'll have to think about this for a while so I can answer in a non-math way. Actually, given the number of people using slicing, I might spend a bit of time on it, and write something substantial up. In short, pool hash speed only affect the number of shares you get and their value, not efficiency. The problem with slow pools isn't that they pay less, but that you put more eggs in one basket and if the round goes long you lose much more. But if the round is short, you gain much more.
But tell me: have you plotted your daily efficiency over time? Say, daily shares and daily earnings over two weeks? Let me make a prediction: I bet you 1 bitcoin that oldDefaultScheduler will approach the theoretical maximum for the number of pools you use, but slicers will not.
Reason: Since variation due to pool luck is reduced, the short term efficiency might seem better than oldDefaultScheduler. But for two weeks of one compared to the other and the same shares submitted per day (and taking any difficulty changes into account) oDS will come out ahead since it will have more early shares than the slicer.
Jump to: