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

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

Quote from: Graet on May 11, 2012, 10:10:50 AM

Quote from: organofcorti on May 11, 2012, 09:55:23 AM

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?

I do think that's a great start, but it occurred to me that miners just want to know how the variable choice will affect them. Many miners will confuse expectation with variance and maturity time. Having the variables listed is good, no doubt, but for a naive miner it will be difficult to understand the relevance.

Quote from: Meni Rosenfeld on May 11, 2012, 10:26:07 AM

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.

Thinking about it some more, even listing the single share variance wouldn't be a very good indicator for a general miner. Charted data from a simulation might be a better bet, but I'm not sure how you'd select a set of exemplars that would cover all (or most) situations of interest to a miner. For example, would you need to have separate large and small miner simulation results? Plus, each pool would have to run their own simulation to illustrate what effects their variable choices have on the performance metrics of the examplars selected.

Meni Rosenfeld

donator

Activity: 2058

Merit: 1054

Quote from: organofcorti on May 11, 2012, 09:55:23 AM

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.

Graet

vip

Activity: 980

Merit: 1001

Quote from: organofcorti on May 11, 2012, 09:55:23 AM

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?

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

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.

Meni Rosenfeld

donator

Activity: 2058

Merit: 1054

Quote from: check_status on May 11, 2012, 09:43:04 AM

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. Cheesy

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.

check_status

full member

Activity: 196

Merit: 100

Web Dev, Db Admin, Computer Technician

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. Cheesy

Graet

vip

Activity: 980

Merit: 1001

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

Meni Rosenfeld

donator

Activity: 2058

Merit: 1054

Quote from: kano on March 18, 2012, 09:53:01 AM

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.

Quote from: kano on March 18, 2012, 09:53:01 AM

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 Tongue

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.

Quote from: kano on March 18, 2012, 09:53:01 AM

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.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Meni Rosenfeld on March 18, 2012, 09:30:00 AM

Quote from: kano on March 18, 2012, 09:12:38 AM

Quote from: Meni Rosenfeld on March 18, 2012, 08:58:56 AM

Quote from: kano on March 18, 2012, 08:54:18 AM

Quote from: Meni Rosenfeld on March 18, 2012, 01:28:57 AM

Quote from: kano on March 18, 2012, 01:15:44 AM

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 Tongue

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

donator

Activity: 2058

Merit: 1054

Quote from: kano on March 18, 2012, 09:12:38 AM

Quote from: Meni Rosenfeld on March 18, 2012, 08:58:56 AM

Quote from: kano on March 18, 2012, 08:54:18 AM

Quote from: Meni Rosenfeld on March 18, 2012, 01:28:57 AM

Quote from: kano on March 18, 2012, 01:15:44 AM

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

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Meni Rosenfeld on March 18, 2012, 08:58:56 AM

Quote from: kano on March 18, 2012, 08:54:18 AM

Quote from: Meni Rosenfeld on March 18, 2012, 01:28:57 AM

Quote from: kano on March 18, 2012, 01:15:44 AM

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

donator

Activity: 2058

Merit: 1054

Quote from: kano on March 18, 2012, 08:54:18 AM

Quote from: Meni Rosenfeld on March 18, 2012, 01:28:57 AM

Quote from: kano on March 18, 2012, 01:15:44 AM

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

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Meni Rosenfeld on March 18, 2012, 01:28:57 AM

Quote from: kano on March 18, 2012, 01:15:44 AM

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

donator

Activity: 2058

Merit: 1054

Quote from: coinotron on March 18, 2012, 08:04:04 AM

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.)

coinotron

legendary

Activity: 1182

Merit: 1000

Hey Meni!

Coinotron's BTC pool rewards are now calculated using DGM

Meni Rosenfeld

donator

Activity: 2058

Merit: 1054

Quote from: kano on March 18, 2012, 01:15:44 AM

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.

Quote from: kano on March 18, 2012, 01:15:44 AM

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.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

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

donator

Activity: 2058

Merit: 1054

Quote from: kano on March 18, 2012, 12:23:31 AM

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

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

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?

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Meni Rosenfeld on February 22, 2012, 06:14:01 AM

...
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.

Quote from: kano on February 22, 2012, 05:24:31 AM

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

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 Cheesy

(Well it sort of is coz it was just wasted hashes before)

Topic: Double geometric method: Hopping-proof, low-variance reward system - page 4. (Read 75564 times)