Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB

[anth0ny]

Any new miner basically starts with a fresh slate, and their shares enter the top of the share log with an estimated reward of 100% immediately.

(Ignoring orhpans.)

Their estimated reward is not really 100% though, for any finite time. As long as there is a possibility it will be <100% and no possibility it will be >100% then the expected value is <100%

Exactly.

[1715123384]

1715123384

[1715123384]

1715123384

[smooth]

What happens if the pool gets several quick successive orphans in a row with far less than 25 BTC worth of mining (at 100% PPS) done to find them, but much more of the share log is dumped?  Doesn't make much sense...

The same (or at least balancing) thing that happens when a block takes more shares and is then orphaned. Some of the shares used to find that block get to stay on the log. In expectation when you get an orphan, the work done to find that block has been lost, and you are never getting it back. Putting those shares onto the log suggests that the pool will somehow get good luck in the future to offset the bad luck it had in the past. That is true for regular bad luck blocks, but false for orphans.

Here's an alternative suggestion that has much less effect on variance. Dump the oldest 25 BTC worth of shares in the log.

I was specifically referring to the shares they submit immediately upon starting to mine... they will be at the top of the share log with estimated reward of 100%.  The shares before theirs in the share log have no affect on their own earnings.

I think we can agree their estimated reward would be 100% if there were no orphans. Since there are orphans it must be less than 100%.

[roy7]

I'm not opposed to CPPSRB and I do mine a bit at Eligius myself when not mining alt coins, but personally it feels more intuitive to me use something like PPLNS or DGM where blocks found now are skewed towards people doing work now. When making my TRC pool last year, CPPSRB is the direction I was heading for a while, but I eventually went with DGM instead because of that. (Also, I never wanted to hold coins at the pool under any circumstances, which PPLNS or DGM also allows.)

[wizkid057]

What happens if the pool gets several quick successive orphans in a row with far less than 25 BTC worth of mining (at 100% PPS) done to find them, but much more of the share log is dumped?  Doesn't make much sense...

The same (or at least balancing) thing that happens when a block takes more shares and is then orphaned. Some of the shares used to find that block get to stay on the log. In expectation when you get an orphan, the work done to find that block has been lost, and you are never getting it back. Putting those shares onto the log suggests that the pool will somehow get good luck in the future to offset the bad luck it had in the past. That is true for regular bad luck blocks, but false for orphans.

Here's an alternative suggestion that has much less effect on variance. Dump the oldest 25 BTC worth of shares in the log.

There are most likely ways to exploit this approach, even if it did somehow work out properly in simulations.

In any case, the net effect assuming it works is more variance, and likely even more confusion... not an actual increase in earnings.

----

100% minus 0% minus 0% is not less than 100%.

You seem to have failed at math again and did not subtract orphan percentage.

The average expected value of everyone is 100%, but that doesn't mean the average expected value of each person is 100%.

Never said this.  I actually said way earlier in this that the expected value is around 98% pool-wide.

Expected value is less than 100%, even if there are no orphans

Again with the math fail... if there were no orphans expected value would be 100%.

[wizkid057]

I'm not opposed to CPPSRB and I do mine a bit at Eligius myself when not mining alt coins, but personally it feels more intuitive to me use something like PPLNS or DGM where blocks found now are skewed towards people doing work now. When making my TRC pool last year, CPPSRB is the direction I was heading for a while, but I eventually went with DGM instead because of that. (Also, I never wanted to hold coins at the pool under any circumstances, which PPLNS or DGM also allows.)

CPPSRB with real-time coinbase payouts is actually a pretty complicated setup pool-side and has to take many factors into account.  I personally underestimated this when initially drafting the code but have worked in many improvements over the last year+.

[smooth]

The same (or at least balancing) thing that happens when a block takes more shares and is then orphaned. Some of the shares used to find that block get to stay on the log. In expectation when you get an orphan, the work done to find that block has been lost, and you are never getting it back. Putting those shares onto the log suggests that the pool will somehow get good luck in the future to offset the bad luck it had in the past. That is true for regular bad luck blocks, but false for orphans.

Here's an alternative suggestion that has much less effect on variance. Dump the oldest 25 BTC worth of shares in the log.

There are most likely ways to exploit this approach, even if it did somehow work out properly in simulations.

That is possible. I would have to think about it some more, and do some math. Unfortunately I'm pretty busy so I won't. If someone wants to do the actual math and PM me, I'll collaborate on it.  My intuition is that it can be reduced to some version of PPLNS that is not exploitable, but that might require a tweak or two.

In any case, the net effect assuming it works is more variance, and likely even more confusion... not an actual increase in earnings.

There is certainly not an increase in total earnings. As you say all the earnings for the pool are paid out to someone, so it can't be increased. There would probably be some increase in earnings to some identifiable subset of past, present, or future miners, along with a corresponding decrease to some other set. Whether that shift would be good or bad is another question.

[anth0ny]

What happens if the pool gets several quick successive orphans in a row with far less than 25 BTC worth of mining (at 100% PPS) done to find them, but much more of the share log is dumped?  Doesn't make much sense...

The same (or at least balancing) thing that happens when a block takes more shares and is then orphaned. Some of the shares used to find that block get to stay on the log. In expectation when you get an orphan, the work done to find that block has been lost, and you are never getting it back. Putting those shares onto the log suggests that the pool will somehow get good luck in the future to offset the bad luck it had in the past. That is true for regular bad luck blocks, but false for orphans.

Here's an alternative suggestion that has much less effect on variance. Dump the oldest 25 BTC worth of shares in the log.

There are most likely ways to exploit this approach, even if it did somehow work out properly in simulations.

In any case, the net effect assuming it works is more variance, and likely even more confusion... not an actual increase in earnings.

----

100% minus 0% minus 0% is not less than 100%.

You seem to have failed at math again and did not subtract orphan percentage.

The average expected value of everyone is 100%, but that doesn't mean the average expected value of each person is 100%.

Never said this.  I actually said way earlier in this that the expected value is around 98% pool-wide.

Expected value is less than 100%, even if there are no orphans

Again with the math fail... if there were no orphans expected value would be 100%.

Interesting how you put the part where I said "if there are no orphans" at the end, while I had it at the beginning.

My two comments ("100% minus 0% minus 0% is not less than 100%." and "The average expected value of everyone is 100%, but that doesn't mean the average expected value of each person is 100%.") were under the scenario that there are no orphans.

[wizkid057]

What happens if the pool gets several quick successive orphans in a row with far less than 25 BTC worth of mining (at 100% PPS) done to find them, but much more of the share log is dumped?  Doesn't make much sense...

The same (or at least balancing) thing that happens when a block takes more shares and is then orphaned. Some of the shares used to find that block get to stay on the log. In expectation when you get an orphan, the work done to find that block has been lost, and you are never getting it back. Putting those shares onto the log suggests that the pool will somehow get good luck in the future to offset the bad luck it had in the past. That is true for regular bad luck blocks, but false for orphans.

Here's an alternative suggestion that has much less effect on variance. Dump the oldest 25 BTC worth of shares in the log.

There are most likely ways to exploit this approach, even if it did somehow work out properly in simulations.

In any case, the net effect assuming it works is more variance, and likely even more confusion... not an actual increase in earnings.

----

100% minus 0% minus 0% is not less than 100%.

You seem to have failed at math again and did not subtract orphan percentage.

The average expected value of everyone is 100%, but that doesn't mean the average expected value of each person is 100%.

Never said this.  I actually said way earlier in this that the expected value is around 98% pool-wide.

Expected value is less than 100%, even if there are no orphans

Again with the math fail... if there were no orphans expected value would be 100%.

Interesting how you put the part where I said "if there are no orphans" at the end, while I had it at the beginning.

My two comments ("100% minus 0% minus 0% is not less than 100%." and "The average expected value of everyone is 100%, but that doesn't mean the average expected value of each person is 100%.") were under the scenario that there are no orphans.

I just grabbed parts of your post and addressed them.  Order didn't seem relevant since the part about adding percentages was after a quote of mine that included orphan %, so, no clear way to understand that you intended the math to not include orphans.  In which case, we appear to be in agreement.  Without orphans, earnings will average to 100%.

[roy7]

CPPSRB with real-time coinbase payouts is actually a pretty complicated setup pool-side and has to take many factors into account.  I personally underestimated this when initially drafting the code but have worked in many improvements over the last year+.

I don't doubt it. I do *almost real-time coinbase payouts myself, I just use DGM instead of CPPSRB to calculates the payments. Eligius was my inspiration to do coinbase payouts. So that was a mission critical feature for me that I wouldn't go live without. (Basically the goal was coinbase payouts + never hold anyone else's coins ever for any reason.)

(* I only update the payouts included in the coinbase once every 3.5 seconds since I don't want to waste the cpu power to calculate it fresh on every single share submitted, or have delays if the database server is slow. So a miner's score might be off by a small fraction if a few seconds of work are credited after a block instead of before it. I felt that was a fair performance trade-off. On principal though, every miner gets work a tiny bit different because if your work finds a block, then the coinbase outputs on the block you found already included credit for that share you just earned by finding the block itself. That was a bit of a headache, but made me feel good. )

[anth0ny]

The same (or at least balancing) thing that happens when a block takes more shares and is then orphaned. Some of the shares used to find that block get to stay on the log. In expectation when you get an orphan, the work done to find that block has been lost, and you are never getting it back. Putting those shares onto the log suggests that the pool will somehow get good luck in the future to offset the bad luck it had in the past. That is true for regular bad luck blocks, but false for orphans.

Here's an alternative suggestion that has much less effect on variance. Dump the oldest 25 BTC worth of shares in the log.

There are most likely ways to exploit this approach, even if it did somehow work out properly in simulations.

That is possible. I would have to think about it some more, and do some math. Unfortunately I'm pretty busy so I won't. If someone wants to do the actual math and PM me, I'll collaborate on it.  My intuition is that it can be reduced to some version of PPLNS that is not exploitable, but that might require a tweak or two.

A big question that needs to be answers first is what do you do if the log goes empty. Revert to PPLNS?

Also, I mean, exploitable how? CPPSRB is probably always going to be vulnerable to some sort of block withholding attack.

In any case, the net effect assuming it works is more variance, and likely even more confusion... not an actual increase in earnings.

There is certainly not an increase in total earnings. As you say all the earnings for the pool are paid out to someone, so it can't be increased. There would probably be some increase in earnings to some identifiable subset of past, present, or future miners, along with a corresponding decrease to some other set. Whether that shift would be good or bad is another question.

Again it depends on what you do if the log goes empty. But if you're decreasing the expected value for the oldest miners (as measured presently, not as measured when they originally got a share), which removing their shares clearly does, then you must be increasing it for someone else.

[un_ordinateur]

Start out as a new miner. Mine 16 shares. With average luck, you'll get paid for those 16 shares. With above average luck, you'll get paid for those 16 shares, and some people who mined before you also get paid for their shares. With bad luck, you get nothing.

Expected value is less than 100%, even if there are no orphans, unless you assume that Eligius lasts forever.

The difference is that once you stop mining with Eligius, the pool will still pay you out shares if it is lucky, whereas every other pool will stop immediately (or after a few hours with PPLNS)

That is where the expectation value of Eligius goes back to 100%, and it is where you "benifit" of the phenomenon that "handicaps" you when you start mining, that is, if the pool is lucky, it pays older shares, not your shares.

I agree that to uncover shares buried deep into the share log, you will probably wait a very long time. But it is as unliquely that a significant amount of your work will pay other than yourself. So it evens out.

Think of it as a "entry deposit" you will get back when you stop mining. Your first few days, you will probably "give" some work to older other miners. But as soon as you have a few shelved shares, you will almost probably always work toward those shares. That "shelved share buffer" is about constant over time, so it always shrinks when seen as a percentage of all the shares you submitted.

Sure it matters. The people at the very end of the shelved share list have virtually no chance of ever getting paid for those shares, in large part because the block rewards keep going down and the difficulty keeps going up.

In Eligius pool, the shelved shares are NOT stored as a given BTC amount, but a fraction of the block reward. When the pool finds a blocks, it then pays the shares at as function of the block reward at the time the block was found, not at the time the share was submitted.

So your balance in units of "block reward fraction" does not depend on the actual block reward. The expected "worth" of the unpayed shares will be cut in half when the block reward will half.

Eventually Eligius will cease to exist. At that point, if there are any shelved shares, then Eligius has paid out less than 100% PPS (including transaction fees) minus orphan %. Those shelved shares are never paid.

Yes, but Eligius will have never owned such money. All the unpayed shares left are only attribuable to the pool's bad luck. A PPLNS pool would not have done any better. No body is ripping off anybody here.

Yes a given user might have had more money (even over 100%!) if the PPLNS pool was lucky when the user mined on it. But a given user might as well have had less money if he was unlucky when he mined on it.

Whether the pool is PPLNS or CPPSRPB, on average users have had exactly the same reward. The only difference is that there is more variability in PPLNS: Some users are over-rewarded, others are under-rewarded. BUT THE AVERAGE OF BOTH METHOD IS THE SAME.

At that point, you chose which method you prefer. If you prefer to gamble, you should prefer PPLSN. You might get lucky. Or not. With CPPSRB, you cannot go over 100%, it is true, but you cannot go as far under it as you could with PPLNS.

It also depends on what you define as "fair". What is fairer:
-That everybody's work, whatever the time it is submitted, has equal worth? That CPPSRP
-That the pool should pay shares more if it is luck and pay shares less if it is unlucky? That PPLNS


In any case, this debate is slightly pointless, because, for any user who has been mining for a few months, the difference between both method is very, very small.

[anth0ny]

I just grabbed parts of your post and addressed them.  Order didn't seem relevant

Well, it was.

Without orphans, earnings will average to 100%.

If you average everyone together. But that doesn't mean it's 100% for each individual.

[smooth]

A big question that needs to be answers first is what do you do if the log goes empty.

This can already happen, in theory, if the pool gets really lucky. What happens when this occurs is not described, as far as I can tell.

Crediting shares at effectively 100% PPS even though the actual earnings must be less than that (given the reality of orphans) reduces the probability of the share log running empty, but that strikes me as somewhat sweeping the problem under the rug.

[un_ordinateur]

A big question that needs to be answers first is what do you do if the log goes empty.

This can already happen, in theory, if the pool gets really lucky. What happens when this occurs is not described, as far as I can tell.

As far as I know, if this were to happen, then the block reward would be sent to a cold wallet, where wizkid would do a manual payment when the pool has a few unlucky.

This is, indeed, losing one of the few advantages of eligius, namely, no need to trust the operator, but it is a moot question considering the actual state of the pool.

[wizkid057]

A big question that needs to be answers first is what do you do if the log goes empty.

This can already happen, in theory, if the pool gets really lucky. What happens when this occurs is not described, as far as I can tell.

Crediting shares at effectively 100% PPS even though the actual earnings must be less than that reduces the probability of the share log running empty, but that strikes me as somewhat sweeping the problem under the rug.

If the entire share log is paid the excess goes to a buffer.  Then when the next block is found, the amount of the buffer is added to its reward for purposes of paying the share log.  This is described here.

[un_ordinateur]

I'll cede this one to WK or un_ordinateur.

I must say I'm quite honored to be considered a trusted information source. Especially in the trustless universe that is bitcoin. Thanks!

[un_ordinateur]

CPPSRB is probably always going to be vulnerable to some sort of block withholding attack.

I'm quite sure that ALL pools are vulnerable to a block witholding attack. But the attacker gain nothing from doing it, unless their goal is to destroy the pool. But there is no way to gain money from it.

Well, the users might always "blackmail" the pool by threathening the pool to withold their block unless they send them some coins, but that could happen to any pool, whatever the method.

[anth0ny]

Start out as a new miner. Mine 16 shares. With average luck, you'll get paid for those 16 shares. With above average luck, you'll get paid for those 16 shares, and some people who mined before you also get paid for their shares. With bad luck, you get nothing.

Expected value is less than 100%, even if there are no orphans, unless you assume that Eligius lasts forever.

The difference is that once you stop mining with Eligius, the pool will still pay you out shares if it is lucky, whereas every other pool will stop immediately (or after a few hours with PPLNS)

Well, yeah, that is the difference.

I'd say it's also a disadvantage.

Don't get me wrong, I don't think it's a significant disadvantage. But the idea that you one day might have dust which will disappear in 30 days later unless you go back to mining, and that collecting that dust would be necessary to get the same expected value as everyone else, is a disadvantage.

That is where the expectation value of Eligius goes back to 100%, and it is where you "benifit" of the phenomenon that "handicaps" you when you start mining, that is, if the pool is lucky, it pays older shares, not your shares.

But again, you only capture that extra % if someone keeps mining after you stop.

Hopefully it's small. I suspect it is. Maybe even negligibly small. I'm curious as to what it is, though. I guess it depends on too many variables, though. Among other things, will everyone else stop mining with Eligius when you do?

I agree that to uncover shares buried deep into the share log, you will probably wait a very long time. But it is as unliquely that a significant amount of your work will pay other than yourself. So it evens out.

It evens out so long as Eligius keeps growing, perhaps. But that can't happen forever.

Sure it matters. The people at the very end of the shelved share list have virtually no chance of ever getting paid for those shares, in large part because the block rewards keep going down and the difficulty keeps going up.

In Eligius pool, the shelved shares are NOT stored as a given BTC amount, but a fraction of the block reward. When the pool finds a blocks, it then pays the shares at as function of the block reward at the time the block was found, not at the time the share was submitted.

So your balance in units of "block reward fraction" does not depend on the actual block reward. The expected "worth" of the unpayed shares will be cut in half when the block reward will half.

Not exactly. The expected value will decline more smoothly than that. But for the most part I think we're saying the same thing. The expected value goes down as the difficulty goes up and the block rewards go down.

Eventually Eligius will cease to exist. At that point, if there are any shelved shares, then Eligius has paid out less than 100% PPS (including transaction fees) minus orphan %. Those shelved shares are never paid.

Yes, but Eligius will have never owned such money. All the unpayed shares left are only attribuable to the pool's bad luck. A PPLNS pool would not have done any better. No body is ripping off anybody here.

I'm sorry if I suggested that.

(Although, possibly somebody is ripping off everybody, if anyone is engaging in a block withholding attack.)

Yes a given user might have had more money (even over 100%!) if the PPLNS pool was lucky when the user mined on it. But a given user might as well have had less money if he was unlucky when he mined on it.

Whether the pool is PPLNS or CPPSRPB, on average users have had exactly the same reward. The only difference is that there is more variability in PPLNS: Some users are over-rewarded, others are under-rewarded. BUT THE AVERAGE OF BOTH METHOD IS THE SAME.

The average over all the participants over all time, yes. The average of a new participant, no.

Just consider a miner who once mines a single difficulty 16 share.

At that point, you chose which method you prefer. If you prefer to gamble, you should prefer PPLSN. You might get lucky. Or not. With CPPSRB, you cannot go over 100%, it is true, but you cannot go as far under it as you could with PPLNS.

With CPPSRB, just as with PPLNS, you can get 0%. Again, consider a miner who once mines a single difficulty 16 share.

It also depends on what you define as "fair". What is fairer:
-That everybody's work, whatever the time it is submitted, has equal worth? That CPPSRP

I'm not sure what you mean by that. It's certainly not true under CPPSRP (or any sane system) that 1 gigahash, whatever the time it is submitted, has equal worth.

-That the pool should pay shares more if it is luck and pay shares less if it is unlucky? That PPLNS


In any case, this debate is slightly pointless, because, for any user who has been mining for a few months, the difference between both method is very, very small.

Right now it is. I'm worried about block withholding attacks, though, and the cost of that attack to the attacker is much smaller under CPPSRP than PPLNS.

I am interested though, in calculating just how small the difference is assuming no block withholding, though. Or at least putting a really small upper bound on it.

[organofcorti]

PPLNS variance is higher than CPPSRB.  <snip>

Is this from simulation or analysis? Merni Rosenfeld derives the reward variance for PPLNS on page ten here: https://bitcoil.co.il/pool_analysis.pdf

For PPLNS, the variance is 1/(network mining difficulty)*(Bitcoin block reward)^2 * 1/N

(N is the "N' in PPLNS)

What is the variance you've calculated for CPPSRB (analytical or otherwise)? Did you take into account the varying maturity time for CPPSRB compared with the more predictable maturity time for PPLNS?

Cheers, wk - I've been interested to know this for ages.

[anth0ny]

CPPSRB is probably always going to be vulnerable to some sort of block withholding attack.

I'm quite sure that ALL pools are vulnerable to a block witholding attack.

Some more than others, though. Under CPPSRB, the cost of not sharing a block (or the maximum cost of delaying one) is one share (at whatever difficulty you've got set, which could be as low as 16 if you've got the network bandwidth and write the mining software) plus a small fraction of your recently shelved shares. Virtually nothing.

Under PPLNS, the cost of not sharing a block (or the maximum cost of delaying one) is all your shares out of the last N. If you're a big miner, that's significantly more than nothing.

But the attacker gain nothing from doing it, unless their goal is to destroy the pool. But there is no way to gain money from it.

What about the "lie in wait" attack? And that's just a simple version. Combine it with a sybil attack and some creative use of GBT and someone with a large share of the network connections and/or hashing power can profit quite a bit from it.