Yeah btcguild will work. Anything will work although it may not be that accurate
EDIT: But really: MINE DEEPBIT. They will make you the most money. Seriously.
Topic: bitHopper: Python Pool Hopper Proxy - page 48. (Read 355813 times)
So can we mine BTCGuild with re_rate and mine_deepbit?
gah I'm torn between oldDefaultScheduler and DefaultScheduler
BTCServ.net is new and slow.. with old default I am stuck here until someone finds a block...crap i dont even know where to find balance or crap on that site.
to slice or to not slice that is the question.
BTCServ.net is new and slow.. with old default I am stuck here until someone finds a block...crap i dont even know where to find balance or crap on that site.
to slice or to not slice that is the question.
I would recommend using penalty for that slow pool issue, wait until you have desired number of shares on there and then increase penalty slowly to convince bH leave them, after they find a block same penalty applies if they still have the same average hashrate
Yeah. Preferably in Gh/s
Quote
Um bclc shouldn't affect anything either way. In fact if you want to mine them and not deal with their messing around use re_rate and mine_deepbit and scrape them with LP. You have to change the regular expressions to supply rate instead of shares though.
You mean the hash rate?
Um bclc shouldn't affect anything either way. In fact if you want to mine them and not deal with their messing around use re_rate and mine_deepbit and scrape them with LP. You have to change the regular expressions to supply rate instead of shares though.
If you are hopping pools with low hashing power, slicing reduces your variance.
I for one am not hopping micro pools at all. You are basically beta testing those pools. Also, there might always be a pool op making a run for it after the first block.
I for one am not hopping micro pools at all. You are basically beta testing those pools. Also, there might always be a pool op making a run for it after the first block.
to slice or to not slice that is the question.
That's the problem I'm having. I can decide what is best. Since I have smaller pools enabled slicing is good but then payout is effected. If I stick with default it's all fine and good on large pools but if it gets stuck on a small pool then payout is effected. So it's turned into a job of manually moving pools around to maximize payout.
gah I'm torn between oldDefaultScheduler and DefaultScheduler
BTCServ.net is new and slow.. with old default I am stuck here until someone finds a block...crap i dont even know where to find balance or crap on that site.
to slice or to not slice that is the question.
BTCServ.net is new and slow.. with old default I am stuck here until someone finds a block...crap i dont even know where to find balance or crap on that site.
to slice or to not slice that is the question.
So, I just saw a bunch of new blocks pop up like 2 or 3 ... but, BH said they were owned by 2 diff pools in the LP output....but those 2 pools on the stats page did not get their shares reset... Im confused...shouldnt the shares reset if they found new blocks? (if the LP implementation is working properly in BH?)
Depends which pools (pools in question could be delaying stats) or their blocks were invalid for some reason and they simply continue counting.
So, I just saw a bunch of new blocks pop up like 2 or 3 ... but, BH said they were owned by 2 diff pools in the LP output....but those 2 pools on the stats page did not get their shares reset... Im confused...shouldnt the shares reset if they found new blocks? (if the LP implementation is working properly in BH?)
@djex
Um we actually don't use the other servers in the latest iteration. We probably should. But our cutoff times are a lot better.
Um we actually don't use the other servers in the latest iteration. We probably should. But our cutoff times are a lot better.
oh so I dont have to have 20 info servers huh..cool that will make my screen smaller again.
what about bitcoin.lc.. does leaving them on hurt? they do that random delay crap
I recon there is an extra method to "slicing" that wasnt considered here yet.
Adjusting mining method based on time left till next difficulty and considering current difficulty to next difficulty increase/decrease.
If next difficulty is soon (insert random low timeframe) and difficulty is increasing (insert random increase percentage here) then stick to (insert random fast pools with lower share)
If next difficulty is soon (insert random low timeframe) and difficulty is decreasing (insert random decrease percentage here) then ignore (insert random pool speed and only consider lowest share)
If next difficulty is in a while (insert random high timeframe) and difficulty is increasing (insert random increase percentage here) then ignore (insert random pool speed and only consider min shares)
I think you could even narrow the timeframes down with some neat formula considering pool avg daily hashrate , share count , next difficulty(up or down) and lastly timeframe till next difficulty adjustment.
Its important to consider difficulty adjustments when mining low share slow pools since they can easily spread across difficulties where you will get penalised even more.
This approach should make the whole lowest shares vs fastest pool debate move more smoothly.
Adjusting mining method based on time left till next difficulty and considering current difficulty to next difficulty increase/decrease.
If next difficulty is soon (insert random low timeframe) and difficulty is increasing (insert random increase percentage here) then stick to (insert random fast pools with lower share)
If next difficulty is soon (insert random low timeframe) and difficulty is decreasing (insert random decrease percentage here) then ignore (insert random pool speed and only consider lowest share)
If next difficulty is in a while (insert random high timeframe) and difficulty is increasing (insert random increase percentage here) then ignore (insert random pool speed and only consider min shares)
I think you could even narrow the timeframes down with some neat formula considering pool avg daily hashrate , share count , next difficulty(up or down) and lastly timeframe till next difficulty adjustment.
Its important to consider difficulty adjustments when mining low share slow pools since they can easily spread across difficulties where you will get penalised even more.
This approach should make the whole lowest shares vs fastest pool debate move more smoothly.
@djex
Um we actually don't use the other servers in the latest iteration. We probably should. But our cutoff times are a lot better.
Um we actually don't use the other servers in the latest iteration. We probably should. But our cutoff times are a lot better.
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...
see this discussion here
i'm giving him a hard time with extremes, but there is a lot of evidence to support him that it is the best scheduler
I'm not 100% sold due to some slow pools, but I'm running it now. Have to give due warning about the stats page.. it's different
which brings up.. who is most responsible for the altslicescheduler?
I just have some questions on how it works, for organofcorti to sim.
Quote
So with mine_deepbit I should switch to info on all possible pools (out of the ones disabled) that will give proper stats?
yes
i add BTCmine as well.. it was never hoppable but it is one of the ten largest pools.
not sure if it is in the hopper.
Can't wait to hear the first reports back on the deepbit hopping. Been excited ever since I read about it yesterday.
So with mine_deepbit I should switch to info on all possible pools (out of the ones disabled) that will give proper stats?
@GenTarkin: old one doesn't slice, it just (more or less) stays at the pool with the lowest share count.
@djex: slicing has only been around for so long. Give it some time to kill the variance.
@djex: slicing has only been around for so long. Give it some time to kill the variance.
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.
IMO best one regards to payout. I found with slicing my payout is often below the daily expected payout for my hash rate but with the OldDefaultScheduler payout is around 0.28 BTC more than the expected.
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
nice, I was asking for itedit: (mental note) don't mess with things I can't remember what are used for
Jump to: