Double geometric method: Hopping-proof, low-variance reward system

[JWU42]

My head hurts... 

[1713932793]

1713932793

[1713932793]

1713932793

[1713932793]

1713932793

[1713932793]

1713932793

[kano]

...
It's just like if a miner adds or removes mining hardware. He changes his contribution to the pool, and accordingly his reward.

All this assumes there isn't something very strange with the whole p2pool/cgminer issue I'm missing.

You can't get more per block out of thin air - sorry

You can get more blocks if you avoid wasting your hashes on something that will be invalid.

Yep I got that one wrong big time
Oh well.

I guess it's just forrestv being evil and telling people with bad reject ratios, that can be fixed, it's OK

The gain is out of thin air
(Well it sort of is coz it was just wasted hashes before)

[kano]

So I was thinking about DGM the other day coz I've swapped back to Ozcoin for a while ...

and I was thinking about how it compares to a modified version of PPS
... or more specifically what I guess is SMPPS though I'm not sure but what I mean is:
a PPS that pays (50/difficulty)*0.985 per share i.e. with a 1.5% pay back to the payout fund (to cover orphans)
and the pool effectively has outstanding debt that is paid later when the fund is less than the amount due to be paid at any payout time

Anyway is there a reason to use DGM instead of an appropriate modified version of PPS?
Since I'm thinking that the point of DGM is to match some modified PPS scheme, why not just use the much simpler scheme it is trying to match and have everyone be able to calculate their expected payments?

[Meni Rosenfeld]

So I was thinking about DGM the other day coz I've swapped back to Ozcoin for a while ...

and I was thinking about how it compares to a modified version of PPS
... or more specifically what I guess is SMPPS though I'm not sure but what I mean is:
a PPS that pays (50/difficulty)*0.985 per share i.e. with a 1.5% pay back to the payout fund (to cover orphans)
and the pool effectively has outstanding debt that is paid later when the fund is less than the amount due to be paid at any payout time

Anyway is there a reason to use DGM instead of an appropriate modified version of PPS?
Since I'm thinking that the point of DGM is to match some modified PPS scheme, why not just use the much simpler scheme it is trying to match and have everyone be able to calculate their expected payments?

This is indeed very similar to SMPPS. SMPPS is broken as I've already written about at length. The short story is that when the debt grows large (which will happen with 100% probability), miners will have greatly delayed payments and thus move on to a different pool, causing the collapse of this one.

Even under the unrealistic assumption that miners will not leave, they will just suffer unbounded maturity time. The purpose of a reward method is to balance variance, fees and maturity time, not to try eliminating any two for an extreme increase in the third.

[kano]

Other than orphans (as I said with the 98.5% with 1.5% back into the fund that pays) what else will make the 'SMPPS' pool's expected balance average less than zero (plus some initial balance to help startup) over time?

again I'm only referring to SMPPS for a base of discussion but using the description I mentioned above - in case there is any difference

[Meni Rosenfeld]

Other than orphans (as I said with the 98.5% with 1.5% back into the fund that pays) what else will make the 'SMPPS' pool's expected balance average less than zero (plus some initial balance to help startup) over time?

Not expected balance average. The balance it will reach eventually.

When a miner decides if to mine in a pool, his maturity time is affected by the balance now, not by the expected balance in the future. It takes just one point in time when the balance is low enough to cause a collapse.

If the fee exactly matches the losses (so the operator doesn't get anything on average), this is Brownian motion and it is guaranteed to eventually be low enough, no matter how low is "low enough".

If there is an additional fee which stays within the pool, the negative balance likely reached is inversely proportional to the extra. It will still cause large maturity time. The accumulated funds that will help the balance remain positive could have instead been handed out to miners.

Also, this method is hoppable. Mining when the balance is high results in reduced maturity time, which means continuous miners will suffer from more than their fair share of increased maturity time.

again I'm only referring to SMPPS for a base of discussion but using the description I mentioned above - in case there is any difference

You didn't specify what your method is. All *SMPPS match your description, the difference between them is how to distribute new funds.

[coinotron]

Hey Meni!

Coinotron's BTC pool rewards are now calculated using DGM

[Meni Rosenfeld]

Hey Meni!

Coinotron's BTC pool rewards are now calculated using DGM

Great, enjoy! (And watch out for the high risk with your chosen parameters.)

[kano]

Other than orphans (as I said with the 98.5% with 1.5% back into the fund that pays) what else will make the 'SMPPS' pool's expected balance average less than zero (plus some initial balance to help startup) over time?

Not expected balance average. The balance it will reach eventually.

When a miner decides if to mine in a pool, his maturity time is affected by the balance now, not by the expected balance in the future. It takes just one point in time when the balance is low enough to cause a collapse.
...

But that collapse is the same with DGM also.
Simple example, last week or the week before DeepBit has 26 blocks with an average across those 26 of 200% shares.
DGM would also have the same problem of the balance getting low enough to cause a collapse.

[Meni Rosenfeld]

Other than orphans (as I said with the 98.5% with 1.5% back into the fund that pays) what else will make the 'SMPPS' pool's expected balance average less than zero (plus some initial balance to help startup) over time?

Not expected balance average. The balance it will reach eventually.

When a miner decides if to mine in a pool, his maturity time is affected by the balance now, not by the expected balance in the future. It takes just one point in time when the balance is low enough to cause a collapse.
...

But that collapse is the same with DGM also.
Simple example, last week or the week before DeepBit has 26 blocks with an average across those 26 of 200% shares.
DGM would also have the same problem of the balance getting low enough to cause a collapse.

DGM doesn't have a balance. It is hopping-proof. Bad luck will cause reduced payouts for past shares but will not affect future shares.

If the parameters are too aggressive the operator has a risk of losing his reserves, but this risk can be kept arbitrarily low with a choice of parameters.

Also, assuming the operator keeps a cashout reserve (which he should), operator bankruptcy causes no direct losses to miners.

[kano]

Other than orphans (as I said with the 98.5% with 1.5% back into the fund that pays) what else will make the 'SMPPS' pool's expected balance average less than zero (plus some initial balance to help startup) over time?

Not expected balance average. The balance it will reach eventually.

When a miner decides if to mine in a pool, his maturity time is affected by the balance now, not by the expected balance in the future. It takes just one point in time when the balance is low enough to cause a collapse.
...

But that collapse is the same with DGM also.
Simple example, last week or the week before DeepBit has 26 blocks with an average across those 26 of 200% shares.
DGM would also have the same problem of the balance getting low enough to cause a collapse.

DGM doesn't have a balance.
...

OK I don't get that one.

Since the amount it pays is not exactly the block amount each time a block is found, it must have a balance.

When it pays above the block amount (bad luck) that amount is obviously not covered by the block so must come from a 'balance' stored somewhere.
Then when the pool gets a short block and pays less than the block amount, that is effectively increasing the balance.

I'm simply looking at the payouts on Ozcoin - so unless they are doing it completely wrong, there must be a balance by the fact that the block amount doesn't match the payout amount.

[Meni Rosenfeld]

Other than orphans (as I said with the 98.5% with 1.5% back into the fund that pays) what else will make the 'SMPPS' pool's expected balance average less than zero (plus some initial balance to help startup) over time?

Not expected balance average. The balance it will reach eventually.

When a miner decides if to mine in a pool, his maturity time is affected by the balance now, not by the expected balance in the future. It takes just one point in time when the balance is low enough to cause a collapse.
...

But that collapse is the same with DGM also.
Simple example, last week or the week before DeepBit has 26 blocks with an average across those 26 of 200% shares.
DGM would also have the same problem of the balance getting low enough to cause a collapse.

DGM doesn't have a balance.
...

OK I don't get that one.

Since the amount it pays is not exactly the block amount each time a block is found, it must have a balance.

When it pays above the block amount (bad luck) that amount is obviously not covered by the block so must come from a 'balance' stored somewhere.
Then when the pool gets a short block and pays less than the block amount, that is effectively increasing the balance.

I'm simply looking at the payouts on Ozcoin - so unless they are doing it completely wrong, there must be a balance by the fact that the block amount doesn't match the payout amount.

It's the operator's reserve. In bad luck the operator pays from his reserve, in good luck he builds up his reserve.

You could call this "balance" if you insist but the difference from SMPPS is that the current reserve has no effect on the payment for future shares. That is, the reserve is not a miner-facing property and having a low reserve does not mean miners are better off elsewhere (especially since even in the event of bankruptcy, an honest operator will offer PPS cashout before discontinuing the pool).

[kano]

Other than orphans (as I said with the 98.5% with 1.5% back into the fund that pays) what else will make the 'SMPPS' pool's expected balance average less than zero (plus some initial balance to help startup) over time?

Not expected balance average. The balance it will reach eventually.

When a miner decides if to mine in a pool, his maturity time is affected by the balance now, not by the expected balance in the future. It takes just one point in time when the balance is low enough to cause a collapse.
...

But that collapse is the same with DGM also.
Simple example, last week or the week before DeepBit has 26 blocks with an average across those 26 of 200% shares.
DGM would also have the same problem of the balance getting low enough to cause a collapse.

DGM doesn't have a balance.
...

OK I don't get that one.

Since the amount it pays is not exactly the block amount each time a block is found, it must have a balance.

When it pays above the block amount (bad luck) that amount is obviously not covered by the block so must come from a 'balance' stored somewhere.
Then when the pool gets a short block and pays less than the block amount, that is effectively increasing the balance.

I'm simply looking at the payouts on Ozcoin - so unless they are doing it completely wrong, there must be a balance by the fact that the block amount doesn't match the payout amount.

It's the operator's reserve. In bad luck the operator pays from his reserve, in good luck he builds up his reserve.

You could call this "balance" if you insist but the difference from SMPPS is that the current reserve has no effect on the payment for future shares. That is, the reserve is not a miner-facing property and having a low reserve does not mean miners are better off elsewhere (especially since even in the event of bankruptcy, an honest operator will offer PPS cashout before discontinuing the pool).

Heh - that sounds like just giving it a different name for the sake of making it sound better

If the pool doesn't have the BTC to make DGM payments during bad luck, it's not gonna appear from no where - the payments will be late

As for bankruptcy payout - the main problem I'd see there from DGM vs PPS (or some of the different PPS) is that no one can probably work out the owed amount on DGM since there is a future component to that, that depends on the future also.
On PPS it's pretty simple.

[Meni Rosenfeld]

Heh - that sounds like just giving it a different name for the sake of making it sound better

Maybe. It's an important distinction and using a different name could prevent confusion.

If the pool doesn't have the BTC to make DGM payments during bad luck, it's not gonna appear from no where - the payments will be late

The payments are not delayed on any case. Either they are paid on time or the pool declares bankruptcy and shuts down. In practice, the operator may be willing to liquidate personal assets and add it to the pool's reserves to keep it running. With parameters like in EMC the risk is minimal. Ozcoin is more aggressive, cointron even more so.

As for bankruptcy payout - the main problem I'd see there from DGM vs PPS (or some of the different PPS) is that no one can probably work out the owed amount on DGM since there is a future component to that, that depends on the future also.
On PPS it's pretty simple.

You can calculate the expected future payment for a given score. (Actually, you can parametrize it so that the expected payout is the score). The operator should pay that out so that miners won't suffer (I'm assuming a deterministic payout is considered better than a variable payout of the same expectation). The total score of all miners is bounded, and the operator should have this as an additional reserve - he should declare bankruptcy before he becomes unable to offer a cashout.

[Graet]

Seem to be more miners asking questions about DGM.
Thought I would bump this a bit so its easier for them to find 

[check_status]

If I'm shopping for a pool to join, how do I use the information on a pools page to calculate my expected payout?
If a pool is hiding information that would make comparison possible, then why should I join their pool when they are not being transparent enough for me to be comfortable?
I've been parametrying alot and I just scratch my head.

[Meni Rosenfeld]

If I'm shopping for a pool to join, how do I use the information on a pools page to calculate my expected payout?
If a pool is hiding information that would make comparison possible, then why should I join their pool when they are not being transparent enough for me to be comfortable?
I've been parametrying alot and I just scratch my head.

You shouldn't join a pool which hides information. Fortunately, the only pools doing that are the ones you shouldn't be joining anyway.

Your expected payout is the same in every hopping-proof pool with 0 fee (assuming the same number of invalids), and it is equal to p*B per share.

[organofcorti]

At a guess (and seeing a number of conversations about it) he's probably concerned about variance vs maturity time. It would be nice if pools posted these values based on their chosen parameters. It would be a point of differentiation for them, anyway.

[Graet]

At a guess (and seeing a number of conversations about it) he's probably concerned about variance vs maturity time. It would be nice if pools posted these values based on their chosen parameters. It would be a point of differentiation for them, anyway.

I thought the other pools were too.
We have since we moved to DGM shown
Double Geometric Variables
f=-0.25, c=0.2, o=0.8
in our forum thread 1st post and on Ozcoin's homepage
are there others we should be showing?

[Meni Rosenfeld]

At a guess (and seeing a number of conversations about it) he's probably concerned about variance vs maturity time. It would be nice if pools posted these values based on their chosen parameters. It would be a point of differentiation for them, anyway.

I see, I interpreted "expected payout" literally. I use the term "performance metrics" for the entire range of payout details.

One problem is that I don't know of a simple calculation that will give the variance and maturity time as a function of the parameters. Also, there is more than one kind of variance. If there is demand for this I'll try to work on some approximations or charts or something. For now there's the variance for a single share in the OP, it's relevant for very small or intermittent miners, and as you can see it's a mouthful.