[CLOSED] MaxBTC.com Pool - Closed Indefinitely Aug 3rd 2013

[MintCondition]

Man that is crappy. It seems to kill any small profit you might get as well when were on these unlucky blocks. 

DGM, the reward method used by MaxBTC, does not suffer from hoppers. On the contrary, extra pool hashrate will only lower everyone's variance, smoothing earnings. You'll get less per block but that much more blocks will be found. This creates the same expected earnings but with less fluctuations each day. Of course the lowest variance is obtained from a PPS pool such as eleuthria's BTCGuild or forementioned ABCPool.  PPS pools usually have a fee to compensate the risk they take off your shoulders, while other pools may be fee-less.

Hope this helps,
MC

[Doff]

I see, that does clear things up.

Thank you

Doff

Man that is crappy. It seems to kill any small profit you might get as well when were on these unlucky blocks. 

DGM, the reward method used by MaxBTC, does not suffer from hoppers. On the contrary, extra pool hashrate will only lower everyone's variance, smoothing earnings. You'll get less per block but that much more blocks will be found. This creates the same expected earnings but with less fluctuations each day. Of course the lowest variance is obtained from a PPS pool such as eleuthria's BTCGuild or forementioned ABCPool.  PPS pools usually have a fee to compensate the risk they take off your shoulders, while other pools may be fee-less.

Hope this helps,
MC

[btcx]

Man that is crappy. It seems to kill any small profit you might get as well when were on these unlucky blocks. 

DGM, the reward method used by MaxBTC, does not suffer from hoppers. On the contrary, extra pool hashrate will only lower everyone's variance, smoothing earnings. You'll get less per block but that much more blocks will be found. This creates the same expected earnings but with less fluctuations each day. Of course the lowest variance is obtained from a PPS pool such as eleuthria's BTCGuild or forementioned ABCPool.  PPS pools usually have a fee to compensate the risk they take off your shoulders, while other pools may be fee-less.

Hope this helps,
MC

Well said.  I just responded to some questions over at Ogrr about this as well:  https://ogrr.com/viewtopic.php?f=373&t=2551&p=16217#p16217

[JWU42]

Seems the settings here are more extreme than ozco.in.  I got paid for 2+ days (granted - very small amounts) after mining there with 10 Gh/s for about 3 hours.  Did the same here and wonder if I will even get paid for this block 

[btcx]

Seems the settings here are more extreme than ozco.in.  I got paid for 2+ days (granted - very small amounts) after mining there with 10 Gh/s for about 3 hours.  Did the same here and wonder if I will even get paid for this block 

According to Ozcoin's site, they use c=0.2, which should pay out for about 36m shares (~22 rounds at current difficulty).  MaxBTC uses c=0.1, which would be good for 16m shares (~10 rounds).  Increasing c would mean slower decay and less variance for miners but also more risk for the pool, which may be acceptable once we stop paying out the bonuses. 

[JWU42]

Thanks for the info - much appreciated!

[btcx]

Beginning round 87, bonuses will be eliminated and c increased from 0.1 to 0.15.

[Meni Rosenfeld]

DGM has 2 parameters. You can decrease variance at the cost of either operator risk or maturity time. If the decay is too fast you can increase o while keeping c fixed. Of course, then people will need to understand that their payment for mining now will be spread out over the next several blocks.


DGM is perfectly usable by intermittent miners, the average reward is not affected. There will be variance which has mostly a psychological effect (I'm not saying psychological factors shouldn't be considered, only that you shouldn't assume there's anything more than that). If the variance (even with optimal parameters) is too much to bear, go with PPS.

However, I would be surprised if the peculiarities of DGM didn't leave room for more advanced and profitable strategies than the standard pool hopping, which of course would be (and will be) another topic.

DGM is provably hopping-proof. Block withholding attacks (including lie-in-wait) are still possible, as with any other system.

[zvs]

Beginning round 87, bonuses will be eliminated and c increased from 0.1 to 0.15.

This change appeared to have messed up the payments as well,

Block 87 (911000 shares) only rewarded 36 bitcoins
Block 88 (798000 shares) rewarded 40 bitcoins
Block 89 (1261000 shares, negative luck) rewarded 46 bitcoins

[btcx]

Beginning round 87, bonuses will be eliminated and c increased from 0.1 to 0.15.

This change appeared to have messed up the payments as well,

Block 87 (911000 shares) only rewarded 36 bitcoins
Block 88 (798000 shares) rewarded 40 bitcoins
Block 89 (1261000 shares, negative luck) rewarded 46 bitcoins

Thanks for chiming in, Meni.  If you see anything wrong with my reasoning/math here (or zvs'), please let me know.

Settings were changed from f=-0.125, c=0.1, o=0.8 in round 86 to f=-0.17647, c=0.15, o=0.85 in the rounds zvs is referring to.  
 
The pool appears to be doing what it's supposed to.  There is no standard on luck but it's set to 0% = difficulty.  The change in parameters and the big pool hopper not being on much in recent rounds is what's making the fee appear so high.  DGM lowers variance and tries to make payments fairly evenly over time.  People that understand variance mine at 0% DGM pools, and people that don't go to 5+% PPS pools and lose 5+% in the long run.

The change in settings would slow the decay and maturity time.  Twice the amount of shares would be needed to replace one of the previous ones.  Eventually it'll reach equilibrium and everything will be 1:1 again.  Also, those rounds are lucky so the pool takes more of the rewards that it had to pay out for the unlucky rounds.  The geometric method is based on p, which is 1/D as the probability that the block will be solved, so 1261000 shares would still be considered "unlucky".  Depending on the scores in previous rounds, it may pay out more than 50 BTC or it may pay out less.  In this case, there were two lucky rounds before it and one that was still better than expected.  The upward trajectory of the payouts even with fairly lucky rounds is expected as the new settings take over to find equilibrium.  Once equilibrium is reached, strings of lucky rounds will usually reduce payouts.

[Meni Rosenfeld]

Thanks for chiming in, Meni.  If you see anything wrong with my reasoning/math here (or zvs'), please let me know.

Settings were changed from f=-0.125, c=0.1, o=0.8 in round 86 to f=-0.17647, c=0.15, o=0.85 in the rounds zvs is referring to.

If DGM is implemented as described in the forum or in AoBPMRS, it requires score rescaling if the average fee is changed. If no rescaling is done, it means that people who mine shortly before the change will get on average less than a 1.25% bonus, rather than 1.25% as they were promised. This has no effect on people who mine after the change. I don't think that has any relation with zvs's observations, though.

Another effect, which is normal, is that changing the timescale means that miners have a new equilibrium score, which takes some time to build up to. This can cause a reduction in immediate payments, which is compensated by a higher later payment. Edit: On second thought, this effect doesn't happen on the global level. It happens per miner when the overall hashrate changes.

But from a casual examination, it looks like what zvs refers to as "messed up payments" is not related at all to the parameter change. The total reward of a block depends on the luck of several previous blocks. (This is the result of cashing out previous score, it has no affect on the profitability of mining new shares). It's possible that there were a few lucky rounds before block 87, causing a reduced total payout which slowly builds up back to the equilibrium.

[zvs]

Thanks for chiming in, Meni.  If you see anything wrong with my reasoning/math here (or zvs'), please let me know.

Settings were changed from f=-0.125, c=0.1, o=0.8 in round 86 to f=-0.17647, c=0.15, o=0.85 in the rounds zvs is referring to.

If DGM is implemented as described in the forum or in AoBPMRS, it requires score rescaling if the average fee is changed. If no rescaling is done, it means that people who mine shortly before the change will get on average less than a 1.25% bonus, rather than 1.25% as they were promised. This has no effect on people who mine after the change. I don't think that has any relation with zvs's observations, though.

Another effect, which is normal, is that changing the timescale means that miners have a new equilibrium score, which takes some time to build up to. This can cause a reduction in immediate payments, which is compensated by a higher later payment.

But from a casual examination, it looks like what zvs refers to as "messed up payments" is not related at all to the parameter change. The total reward of a block depends on the luck of several previous blocks. (This is the result of cashing out previous score, it has no affect on the profitability of mining new shares). It's possible that there were a few lucky rounds before block 87, causing a reduced total payout which slowly builds up back to the equilibrium.

Hmm, I think the change combined with the earlier lucky blocks probably made the payment less than it would have been than if nothing had been changed?   Wouldn't it cause the lucky blocks to stick around for longer when otherwise they may have been "passed" by the share count?

In any case, yeah, it definitely caught up or w/e.  It's paying out fine now.

[Meni Rosenfeld]

Hmm, I think the change combined with the earlier lucky blocks probably made the payment less than it would have been than if nothing had been changed?   Wouldn't it cause the lucky blocks to stick around for longer when otherwise they may have been "passed" by the share count?

It would be the other way around. Increasing c should make for a more rapid recovery from previous luck.

[btcx]

Thanks for chiming in, Meni.  If you see anything wrong with my reasoning/math here (or zvs'), please let me know.

Settings were changed from f=-0.125, c=0.1, o=0.8 in round 86 to f=-0.17647, c=0.15, o=0.85 in the rounds zvs is referring to.

If DGM is implemented as described in the forum or in AoBPMRS, it requires score rescaling if the average fee is changed. If no rescaling is done, it means that people who mine shortly before the change will get on average less than a 1.25% bonus, rather than 1.25% as they were promised. This has no effect on people who mine after the change. I don't think that has any relation with zvs's observations, though.

Another effect, which is normal, is that changing the timescale means that miners have a new equilibrium score, which takes some time to build up to. This can cause a reduction in immediate payments, which is compensated by a higher later payment. Edit: On second thought, this effect doesn't happen on the global level. It happens per miner when the overall hashrate changes.

But from a casual examination, it looks like what zvs refers to as "messed up payments" is not related at all to the parameter change. The total reward of a block depends on the luck of several previous blocks. (This is the result of cashing out previous score, it has no affect on the profitability of mining new shares). It's possible that there were a few lucky rounds before block 87, causing a reduced total payout which slowly builds up back to the equilibrium.

I don't think the rescaling is required.  The bonuses were meant to be applied for the rounds mined in.  So, if you were going to get 1 BTC with DGM, you'd get 1.0125 BTC instead.  It was easily accomplished with DGM without having to add any extra bonus code by increasing f by that amount, which would be the same as increasing the DGM payout by that amount since f isn't involved in calculating the score payout = (exp(lS-ls)*(r-1)*(1-f))/p.

The bonus you're referring to is for the lifetime of the share, which isn't how we're defining bonus (and I don't think most people would define it that way either), though what you're referring to is probably more fair and isn't exploitable.

[Meni Rosenfeld]

I don't think the rescaling is required.  The bonuses were meant to be applied for the rounds mined in.  So, if you were going to get 1 BTC with DGM, you'd get 1.0125 BTC instead.  It was easily accomplished with DGM without having to add any extra bonus code by increasing f by that amount, which would be the same as increasing the DGM payout by that amount since f isn't involved in calculating the score payout = (exp(lS-ls)*(r-1)*(1-f))/p.

The bonus you're referring to is for the lifetime of the share, which isn't how we're defining bonus (and I don't think most people would define it that way either), though what you're referring to is probably more fair and isn't exploitable.

I guess that's one way to look at it. To me a bonus implies that every share I mine during the bonus period gives me on average 101.25% PPS.

[Frizz23]

Why does the topic still say: "[459 GH] MaxBTC.com Pool ..."? We are below 100 GH now!

[Tittiez]

Why does the topic still say: "[459 GH] MaxBTC.com Pool ..."? We are below 100 GH now!

"Shhhhhh"

[btcx]

I guess that's one way to look at it. To me a bonus implies that every share I mine during the bonus period gives me on average 101.25% PPS.

To be honest, we never considered that definition.  It's similar to how we do donations; the amount they want to donate is a % of what their income is for that round, not what their mined shares would produce for that round over its lifetime.  it's a lot easier for people to understand, calculate, and predict than it is to have the donations spread out over multiple rounds.  it also makes implementation easier since no rescaling would be required whenever they decide to change their donation %.

[Frizz23]

Why does the hashrate of your pool vary so much? Does that mean it's getting hopped?

[Meni Rosenfeld]

I guess that's one way to look at it. To me a bonus implies that every share I mine during the bonus period gives me on average 101.25% PPS.

it also makes implementation easier since no rescaling would be required whenever they decide to change their donation %.

You can parametrize the calculation in a way that will not require an explicit rescaling when changing the average fee to do what I described.