organofcorti
Donator
Legendary
Online
Activity: 2002
Poor impulse control.


October 28, 2011, 07:22:31 AM 

I think long time blog readers will get a kick out of this: Hello everybody,
Is the pool ok? As for me the current 9+ hour block looks a bit unlucky. And the previous 4 hour too.
Yeah, im sure it's just unlucky. I've seen 12+ hour blocks in the recent past (not counting the 1 1/2 day block from when the pool was ddos'ed). Didn't happen as often when the pool was up around 2000 ghash, but now that its around 1200/1300 there is a lot more variance. ....which I explained way back in How to hop 4: so if the pools hashrate increases to 150% the exponential part of the score decreases. The overall effect is that it will make the resulting efficiency and hop point closer to proportional than before the increase in hashrate. Conversely, too low a hashrate or a c value that is too low will increase the exponential part of the score. In the extreme case where c approaches 0, n/(hashrate*c) approaches infinity. Each share is infinitely more valuable than the previous, meaning the pool score and the share score will approach equivalence so that only the share that solves a block will be rewarded. This is in effect solo mining. Have to love it when the real world agrees with the math.





Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.



martychubbs


November 01, 2011, 03:48:08 PM 

Word on the street is "c value for Coinatron is 6." However, I expect the c value to be higher and have had good luck mining with a c value of 3000. Have you determined a c value for Coinatron yet? Keep up the great work!




organofcorti
Donator
Legendary
Online
Activity: 2002
Poor impulse control.


November 01, 2011, 08:03:19 PM 

Word on the street is "c value for Coinatron is 6." However, I expect the c value to be higher and have had good luck mining with a c value of 3000. Have you determined a c value for Coinatron yet? Keep up the great work!
Coinotron's score system is different from Slush's, and mine_c on bitHopper is not appropriate. I would use role:mine instead. I'll explain why at some point, but in the meantime please enjoy following chart porn, just for you:




organofcorti
Donator
Legendary
Online
Activity: 2002
Poor impulse control.


November 02, 2011, 12:08:15 PM 

When I first published the Slush hop function in How to hop 4 I made a mistake in not bothering to take difficulty into account, since D seemed pretty stable at the time. c00w even asked about how Slush hopping would be affected by difficulty and I lazily replied something like 'not a problem'. I wasn't expecting D to drop by a third! So I rejigged the hop function to take current difficulty into account. I'll publish the derivation on hoppersden.info when I have time. The new function makes a significant difference (try it against the old one and see) so please pass the word. Anyway here it is, ready to go: Hop point =0.0164293+1.14254/(1.8747*D/(hashrate*c)+2.71828) 'c' can be calculated (see 'How to hop 8') if you get some score, share and time values from the pool website, 'hashrate' is the average hashrate of the pool since start of roundin Ghps, and D is current difficulty. Finding an accurate solution that was still fairly simple took a while, so sorry for the delay. Edit: fixed formula  brackets in wrong place. Thanks for the heads up, eveofwar




martychubbs


November 07, 2011, 02:23:43 PM 

Word on the street is "c value for Coinatron is 6." However, I expect the c value to be higher and have had good luck mining with a c value of 3000. Have you determined a c value for Coinatron yet? Keep up the great work!
Coinotron's score system is different from Slush's, and mine_c on bitHopper is not appropriate. I would use role:mine instead. I'll explain why at some point, but in the meantime please enjoy following chart porn, just for you: I'm giving "mine" w/penalty a try, have a suggestion on the optimal penalty? Also, thanks for the cp...had my way with it! Ohh!




catfish


November 08, 2011, 12:47:34 PM 

OK, I'm not above making a fool of myself, since if this is a stupid question then I really ought to know better (I studied stats and probability at a university everyone has heard of).
Distilling things into plain English and away from the equations for a moment (though I will use jargon)... the repetition of chance of a 'share' submitted by your miners finding a block, and winning some proportion of a prize, is the simplest form of stochastic process, correct? There is no dependence on the previous state (however from looking at the kernel code, it appears that the last block hash *is* used somewhere in the calculations... though this complicates matters and I'll ignore it).
Hence the statisticians and game theorists here using dice or coinflip thought experiments as models.
However, if the model is effectively a discretetime set of independent events, then unless the sample size (number of players) is statistically small, what makes hopping between pools any different than hopping back into the same pool? You're joining a series of independent events, so joining at any time should make zero difference.
Intuitively, this is wrong, since humans have an innate psychological 'law of averages' which is a fallacy. Innately, your average human will see a pool that has a 4 day block running and think 'must be done soon', just like after seeing 10 heads on a cointoss experiment will make most humans expect a tail to have a higher probability  it hasn't though.
I understand that the reason why my logic is faulty is that *the game stops* when a certain condition is found, making it possible to analyse the probability distribution of the lengths of each round (i.e. the number of events before the gamestopping event is found). And given that is a binomial distribution, we have the analyses here.
But bitcoin mining is NOT like coin tossing. Not even inside one pool. The statistical models here present each independent event as having a specific probability which is invariant (correct me if I'm wrong, because my entire post depends on this contention). However the probability depends on the *total* number of participants in the game *across* all pools  this is the bitcoinspecific 'tweak' to the probability function (otherwise doubling the number of miners would double the money supply, etc.)
So there's interpool variance in these distributions. A steady mediumsized pool's 'width' of the probability distribution (i.e. standard deviation of time taken to find a block) will rise if other pools gain large amounts of hashing power, making the pool a smaller proportion of the entire network, and vice versa. If you can hop so frequently that you can rely on the probability staying invariant, then these strategies make sense. But as soon as you introduce variables to the probability of each independent event, and the pool's variance depends on its total hashpower, which is also affected by poolhoppers moving, then simplified models become less accurate.
I've seen far too much of this in quantitative finance  a model that works very well with the nice little line 'assume that P (or whatever) is invariant' fails bigstyle when P turns out *not* to be invariant, but volatile as hell. Isn't that JUST as relevant here?
It seems to me that the entire poolhopping 'strategy' relies on exploiting variance in smalltomedium sized pools. The largest pools must be getting towards the law of large numbers by now, surely?
Wouldn't one potential strategy simply be to monitor the hashpower of a select range of pool hashpowers (not so small that payouts are very infrequent or the pool is at risk of closure, and not so big that there is little variance in their blockfinding times) and jump to a new pool when the variance in the new pool hits a local maximum? The risk here is that if the small pools have enough 'hoppers' following this strategy on board, then a different pool's local maximum will cause all the hoppers to leave, resulting in the 'old' pool maximising its variance through loss of hashpower. And then the hoppers return... ad infinitum. Which would result in hoppers *losing* due to network downtime and too much switching between pools.
By the way, this is NOT what I do... I support medium sized pools for the good of the network  my hashpower earns me enough for me to be happy with being 'honest'  even though I make no value judgement with this word. It's business and if hopping is unwanted by a particular pool operator, it's the operator's job to make it undesirable / unprofitable, IMO.
Apologies, I haven't read the literature already out there on mining analysis, and my knowledge of probability *ought* to be a damn sight better, but it was decades ago...

...so I give in to the rhythm, the click click clack I'm too wasted to fight back...
BTC: 1A7HvdGGDie3P5nDpiskG8JxXT33Yu6Gct



teukon
Legendary
Offline
Activity: 1246


November 08, 2011, 04:39:14 PM 

But bitcoin mining is NOT like coin tossing. Not even inside one pool. The statistical models here present each independent event as having a specific probability which is invariant (correct me if I'm wrong, because my entire post depends on this contention). However the probability depends on the *total* number of participants in the game *across* all pools  this is the bitcoinspecific 'tweak' to the probability function (otherwise doubling the number of miners would double the money supply, etc.)
I'm afraid I've not had time to read everything you said carefully (I have to dash) but the assumption you gave here could be the cause. I hope I've not missed the point. The probability of any one hash (share if you like) generating a Bitcoin block is essentially fixed. (It is changed once every 2016 blocks  approximately 2 weeks). If you select a 10 day period shortly after a difficulty change then the various hopping strategies outlined here apply. If you are careful you can probably profit even more when difficulty changes (and yes, some of the strategies given here may have to be tweaked to accomodate a change). I haven't been keeping up with this thread so it's possible there are some posts on what to do at difficulty changes.




organofcorti
Donator
Legendary
Online
Activity: 2002
Poor impulse control.


November 09, 2011, 12:26:57 PM 

Word on the street is "c value for Coinatron is 6." However, I expect the c value to be higher and have had good luck mining with a c value of 3000. Have you determined a c value for Coinatron yet? Keep up the great work!
Coinotron's score system is different from Slush's, and mine_c on bitHopper is not appropriate. I would use role:mine instead. I'll explain why at some point, but in the meantime please enjoy following chart porn, just for you: I'm giving "mine" w/penalty a try, have a suggestion on the optimal penalty? Also, thanks for the cp...had my way with it! Ohh! Hey Marty, The hop point for coinotron is about 0.73*D, but you don't know if they're using c=6 or not and if you stayed until 0.73*D you'd lose efficiency. The other downside is that until around 0.38*D you wouldn't want to be there if you had a prop pool. Until hopper software can incorporate hopping efficiency function (discussed in How to hop 4, I'd just treat it like a proportional pool if you really want to hop it. Your best bet though is to compare your shares submitted per round to your reward. You can work backward to find out if your reward is consistent with a normal proportional pool or not. If they aren't using C=6, then there's nothing to worry about at all. If they are, you can use a penalty of 0.6. Good luck!




organofcorti
Donator
Legendary
Online
Activity: 2002
Poor impulse control.


November 09, 2011, 01:07:29 PM 

OK, I'm not above making a fool of myself, since if this is a stupid question then I really ought to know better (I studied stats and probability at a university everyone has heard of). Thanks for your interest, catfish. I am absolutely certain that pool hopping works. I was even before I understood the probability behind it, by using mining simulations. How to hop 5 gives some examples of this sort, and How to hop 6 derives the expected value for a share. Having studied probability yourself I encourage you to read through these posts which I hope will help explain why the expected value of a share varies. When I discuss pools in this reply I am only referring to pools with a standard proportional payout although some information is standard for all pools. However, if the model is effectively a discretetime set of independent events, then unless the sample size (number of players) is statistically small, what makes hopping between pools any different than hopping back into the same pool? You're joining a series of independent events, so joining at any time should make zero difference.
Intuitively, this is wrong, since humans have an innate psychological 'law of averages' which is a fallacy. Innately, your average human will see a pool that has a 4 day block running and think 'must be done soon', just like after seeing 10 heads on a cointoss experiment will make most humans expect a tail to have a higher probability  it hasn't though.
I understand that the reason why my logic is faulty is that *the game stops* when a certain condition is found, making it possible to analyse the probability distribution of the lengths of each round (i.e. the number of events before the gamestopping event is found). And given that is a binomial distribution, we have the analyses here.
But bitcoin mining is NOT like coin tossing. Not even inside one pool. The statistical models here present each independent event as having a specific probability which is invariant (correct me if I'm wrong, because my entire post depends on this contention). However the probability depends on the *total* number of participants in the game *across* all pools  this is the bitcoinspecific 'tweak' to the probability function (otherwise doubling the number of miners would double the money supply, etc.)
But bitcoin mining *is* like coin tossing, even in one pool. You make the statement that bitcoin mining probabilities do not follow a geometric distribution but I'd like to know why you think that. Maybe you're confusing shares with hashes? Each share is a hash of difficulty 1, and so has a probability of 1/D of solving a block. A series of events each which have the same probability of ending a trial is a standard bernoulli trial. So there's interpool variance in these distributions. A steady mediumsized pool's 'width' of the probability distribution (i.e. standard deviation of time taken to find a block) will rise if other pools gain large amounts of hashing power, making the pool a smaller proportion of the entire network, and vice versa. A pool with a hashrate of ten times another pool will solve blocks ten times more quickly, on average, because it is accumulating shares ten times more quickly. The variance you mention is related to the time taken to solve a block, not to the number of shares taken to solve it. Over a large enough series of rounds, the share variance at a small pool is the same as at a large pool, only it takes more time for the mean and variance to settle. If you can hop so frequently that you can rely on the probability staying invariant, then these strategies make sense. Why is frequent hopping helpful? But as soon as you introduce variables to the probability of each independent event, and the pool's variance depends on its total hashpower No, just the time based variance[/quote], which is also affected by poolhoppers moving, then simplified models become less accurate. I've seen far too much of this in quantitative finance  a model that works very well with the nice little line 'assume that P (or whatever) is invariant' fails bigstyle when P turns out *not* to be invariant, but volatile as hell. Isn't that JUST as relevant here? It seems to me that the entire poolhopping 'strategy' relies on exploiting variance in smalltomedium sized pools. The largest pools must be getting towards the law of large numbers by now, surely?[/quote] To quote Starlightbreaker  "hop all the pools!". In fact because the time based variance of small pools is so large, they are not preferable. The larger the pool, the more constant the hopping profit. Wouldn't one potential strategy simply be to monitor the hashpower of a select range of pool hashpowers (not so small that payouts are very infrequent or the pool is at risk of closure, and not so big that there is little variance in their blockfinding times) and jump to a new pool when the variance in the new pool hits a local maximum? The risk here is that if the small pools have enough 'hoppers' following this strategy on board, then a different pool's local maximum will cause all the hoppers to leave, resulting in the 'old' pool maximising its variance through loss of hashpower. And then the hoppers return... ad infinitum. Which would result in hoppers *losing* due to network downtime and too much switching between pools.
Even if this sort of variance was useful to a pool hopper, one round's variance is not reliant on previous rounds so that a maximum in average variance doesn't predict variance in the next round Apologies, I haven't read the literature already out there on mining analysis, and my knowledge of probability *ought* to be a damn sight better, but it was decades ago...
Great questions, catfish! It took me a lot of reading to get up to speed. The best place to start is Analysis of bitcoin pooled mining reward systems. Another thing you could do is collect a hundred or so block lengths (deepbit publishes theirs) and do some calculations for yourself. At the minimum you could generate a histogram to show you that the block lengths are distributed according to a geometric probability distribution. If you can prove that to yourself, everything else should follow.




Meni Rosenfeld
Donator
Legendary
Offline
Activity: 1932


November 10, 2011, 07:27:15 PM 

But bitcoin mining is NOT like coin tossing. Not even inside one pool. The statistical models here present each independent event as having a specific probability which is invariant (correct me if I'm wrong, because my entire post depends on this contention). However the probability depends on the *total* number of participants in the game *across* all pools  this is the bitcoinspecific 'tweak' to the probability function (otherwise doubling the number of miners would double the money supply, etc.)
The dependence on other pools is done only via difficulty retargeting, which happens once every two weeks. In between difficulty adjustments, each pool really is its own completely independent Poisson process. It seems to me that the entire poolhopping 'strategy' relies on exploiting variance in smalltomedium sized pools. The largest pools must be getting towards the law of large numbers by now, surely?
Poolhopping works by maximizing your gain for every share. Your gain per share in a proportional pool depends only on the eventual number of shares in the round, which is completely independent of any temporal considerations (such as the pool's hashrate)  only on the fixed probability of every share to be a valid block and end the round. The less shares in a round, the more you gain per share, so you want to submit to pools with the least shares in the current round. Until hopper software can incorporate hopping efficiency function
You mean it doesn't now? How... uninspired. Another thing you could do is collect a hundred or so block lengths (deepbit publishes theirs) and do some calculations for yourself. At the minimum you could generate a histogram to show you that the block lengths are distributed according to a geometric probability distribution.
One way to test if a list of empirical values were generated from a specific distribution is by comparing moments. If you take each round length and divide it by the difficulty at the time, you'll get values supposed to be distributed exponentially with mean 1. So the average nth power of the values should be n!. But you need quite a lot of observations to be accurate, more so for the higher moments  with 100 samples, even the second moment will be a bit off.




organofcorti
Donator
Legendary
Online
Activity: 2002
Poor impulse control.


November 11, 2011, 12:06:55 PM 





paraipan
Legendary
Offline
Activity: 924
Firstbits: 1pirata


November 11, 2011, 12:25:19 PM 

lol organofcorti, pretty explanatory yeah, nice graphs man
Care to make a graph which compares standard prop with score type payouts and simulates intermittent disconnects from the pool ?
Can't seem to find a worthwhile explanation or graph around interwebs. If you have the ability so simulate score payouts over a 200 or more, rounds, normal and intermittent connection, to make a good average would be great.

BTCitcoin: An Idea Worth Saving  Q&A with bitcoins on rugatu.com  Check my rep



organofcorti
Donator
Legendary
Online
Activity: 2002
Poor impulse control.


November 11, 2011, 12:29:49 PM 

Until hopper software can incorporate hopping efficiency function
You mean it doesn't now? How... uninspired. Yes, I didn't think simulate out potential losses if a hopping efficiency function isn't used, and hopperware creators and maintainers are only going to introduce significant changes if there's a good enough reason or enough people ask for them. I think I'll have to write and run a simulation now that there are fewer proportional pools and the chance of hopping to a hoppable scored with a lower expected share value (and therefore reduced efficiency) is greater. BTW, thanks for your help on hopper v fulltimer potential earnings question. I think the charts turned out ok.




organofcorti
Donator
Legendary
Online
Activity: 2002
Poor impulse control.


November 11, 2011, 12:41:52 PM 

lol organofcorti, pretty explanatory yeah.
Care to make a graph which compares standard prop with score type payouts and simulates intermittent disconnects from the pool ?
Can't seem to find a worthwhile explanation or graph around interwebs. If you have the ability so simulate score payouts over a 200 or more, rounds, normal and intermittent connection, to make a good average would be great.
Hey paraipan, You handle's getting shorter, I see. I guess it must be more efficient that way? No? Not even a chuckle? Sigh. Anyway your proposal sounds like a good project. I'll need to know a bit more:  Which type of score payout? I'm assuming Slush's?
 How much does the intermittent connection affect share submission? How long would there be no share submission as a proportion of round length, and what would the reduction in average hashrate be?




Meni Rosenfeld
Donator
Legendary
Offline
Activity: 1932


November 11, 2011, 01:19:41 PM 

BTW, thanks for your help on hopper v fulltimer potential earnings question. I think the charts turned out ok.
To be honest I don't understand what the first two charts are saying.




paraipan
Legendary
Offline
Activity: 924
Firstbits: 1pirata


November 11, 2011, 01:41:00 PM 

lol organofcorti, pretty explanatory yeah.
Care to make a graph which compares standard prop with score type payouts and simulates intermittent disconnects from the pool ?
Can't seem to find a worthwhile explanation or graph around interwebs. If you have the ability so simulate score payouts over a 200 or more, rounds, normal and intermittent connection, to make a good average would be great.
Hey paraipan, You handle's getting shorter, I see. I guess it must be more efficient that way? No? Not even a chuckle? Sigh. Anyway your proposal sounds like a good project. I'll need to know a bit more:  Which type of score payout? I'm assuming Slush's?
 How much does the intermittent connection affect share submission? How long would there be no share submission as a proportion of round length, and what would the reduction in average hashrate be?
yeah it's true bout my nick haha, thanks for considering my proposal organof adding missing data:  slush score would be a good example and easy for all to understand, yes  the problems will cut share submission and work requests completely. The graph should contain reference score just like you simulated before and it's equivalent containing real world parameter, miner pool connection, that adds to pool variance as a whole. You take the reference point, can be 15 minutes every hour, 1 hour every day or 1 day every month, because it depends on the time frame you choose to sample. Thanks again for providing this kind of resources to the community, i'm sure some donations will come your way soon and be able to do even more stuff.

BTCitcoin: An Idea Worth Saving  Q&A with bitcoins on rugatu.com  Check my rep



organofcorti
Donator
Legendary
Online
Activity: 2002
Poor impulse control.


November 11, 2011, 01:44:04 PM 

BTW, thanks for your help on hopper v fulltimer potential earnings question. I think the charts turned out ok.
To be honest I don't understand what the first two charts are saying. Maybe not so ok, then The first chart shows how the round payout for the hoppers as a group and the fulltime miners as a group changes before and after the hoopers leave, as a function of the hashrate increase due to hoppers adding hashrate to a pool. So it shows the portion of the round reward that leaves the pool with the pool hoppers (over and above what they would have been paid with a fair payout system), on average. The second chart shows the (expected pool hopper payout)/(fair payout) compared with (expected fulltime miner payout)/(fair payout), again as a function of the hashrate increase due to hoppers.




Meni Rosenfeld
Donator
Legendary
Offline
Activity: 1932


November 11, 2011, 02:07:29 PM 

BTW, thanks for your help on hopper v fulltimer potential earnings question. I think the charts turned out ok.
To be honest I don't understand what the first two charts are saying. Maybe not so ok, then The first chart shows how the round payout for the hoppers as a group and the fulltime miners as a group changes before and after the hoopers leave, as a function of the hashrate increase due to hoppers adding hashrate to a pool. So it shows the portion of the round reward that leaves the pool with the pool hoppers (over and above what they would have been paid with a fair payout system), on average. The second chart shows the (expected pool hopper payout)/(fair payout) compared with (expected fulltime miner payout)/(fair payout), again as a function of the hashrate increase due to hoppers. Ok, I get it now.




organofcorti
Donator
Legendary
Online
Activity: 2002
Poor impulse control.


November 12, 2011, 01:46:02 PM 

 slush score would be a good example and easy for all to understand, yes  the problems will cut share submission and work requests completely.
The graph should contain reference score just like you simulated before and it's equivalent containing real world parameter, miner pool connection, that adds to pool variance as a whole. You take the reference point, can be 15 minutes every hour, 1 hour every day or 1 day every month, because it depends on the time frame you choose to sample.
Thanks again for providing this kind of resources to the community, i'm sure some donations will come your way soon and be able to do even more stuff.
I've completed the simulation, and it works well until I try to compare Slush to proportional  for some reason Slush comes out ahead in payouts by 0.7% consistently. Once I either find the source of the error or find out why it's not an error I'll post the results.




Meni Rosenfeld
Donator
Legendary
Offline
Activity: 1932


November 12, 2011, 03:53:33 PM 

 slush score would be a good example and easy for all to understand, yes  the problems will cut share submission and work requests completely.
The graph should contain reference score just like you simulated before and it's equivalent containing real world parameter, miner pool connection, that adds to pool variance as a whole. You take the reference point, can be 15 minutes every hour, 1 hour every day or 1 day every month, because it depends on the time frame you choose to sample.
Thanks again for providing this kind of resources to the community, i'm sure some donations will come your way soon and be able to do even more stuff.
I've completed the simulation, and it works well until I try to compare Slush to proportional  for some reason Slush comes out ahead in payouts by 0.7% consistently. Once I either find the source of the error or find out why it's not an error I'll post the results. I wouldn't be surprised if it's a real result caused by selfhashratehopping. As you recall, in temporal pools it is an advantage to mine when the hashrate is higher. When you disconnect from the pool its hashrate is reduced, so conversely, you mine when the hashrate is higher. I haven't quantified this effect, and AFAIK it could just as easily have the opposite effect by expediting decay of share submitted before disconnecting. I'll try to look into it.




