[OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #

[purelithium]

Haha very true. I might just stick your pool in there somewhere

[1713990594]

1713990594

[1713990594]

1713990594

[wizkid057]

Manual payout to knock out a good chunk of the payout queue that seemed to be "stuck" since the reward halving.

Bitcoin transaction af9853ded9419161d49ff62f14cffb4c0cd6f7c07a09eb559b839a4dcc1579af

-wk

[GigaWave]

Can you please explain this? I've read through the wiki and don't understand why I'm seeing this behavior.

I just started mining with this pool about three days ago. I've been watching the stats page for my Eligius account(Payout address). The first 48 hours I have earned the expected payout amount for my hashrate. But starting right at the 48 hour mark in, my payout started going to the bonus field. And now it looks like all of my payout is going to the bonus field for the past 24 hours, all while my regular payout fluctuates by about  0.0001, constantly being added to and deducted from in waves.

Here's a short example.

.24236895(Starting payout)
.24234715(Pay for Share "A")
.24233080(Pay for Share "B")


.12047178(Starting Bonus at Share "A")
.12053847(Bonus for Share "B")

[wizkid057]

Can you please explain this? I've read through the wiki and don't understand why I'm seeing this behavior.

I just started mining with this pool about three days ago. I've been watching the stats page for my Eligius account(Payout address). The first 48 hours I have earned the expected payout amount for my hashrate. But starting right at the 48 hour mark in, my payout started going to the bonus field. And now it looks like all of my payout is going to the bonus field for the past 24 hours, all while my regular payout fluctuates by about  0.0001, constantly being added to and deducted from in waves.

Here's a short example.

.24236895(Starting payout)
.24234715(Pay for Share "A")
.24233080(Pay for Share "B")


.12047178(Starting Bonus at Share "A")
.12053847(Bonus for Share "B")

This is how our new reward system behaves during "unlucky" rounds.  Please review CPPSRB - Capped PPS with Recent Backpay for details, however, I will try to explain this with regard to the actual stats right now.

CPPSRB logs every share in a share log, placing the newest mined shares at the "top" of the log.  Every so often (currently every second or so) the code tallies up the latest 25 BTC worth of shares, as those shares would all be paid if we found a block at that moment.  Now, if you continuously mine, and the current round leads to more than 25 BTC worth of shares being mined without the pool finding a block, older shares are no longer in this top 25 BTC worth of shares. Assuming you mine at a relatively steady hashrate, your new shares will come in at about the same rate your older shares of the round are bumped out of the top 25 BTC window, and are then tallied in the "Extra credit" field.  When a block is found, the top 25 BTC worth of shares are paid, and the next 25 BTC worth of shares are then at the top of the share log (moving units from "Extra Credit" to part of the estimated unpaid balance) ready to be paid as soon as a block is found, but, the share log is constantly growing, and the newest shares take priority, obviously, so things are constantly changing in realtime.

The short answer to why your balance "stopped" increasing is because you are only adding shares to the top of the share log at your hashrate, and other miners are doing the same, so, the window of the top of the share log is always sliding past your older shares during this unlucky round, making the older shares "Extra credit" for now, until we find a block(s) that are able to pay off that far back into the share log.

Hope this helps.

-wk

[GigaWave]

Yes it does. Thank you.

Seems like with this schema that a smaller contributor can be left out in the cold more often and not have as regular payouts. Even if they contribute with a regular and consistent hashrate. Is this correct?

[wizkid057]

Yes it does. Thank you.

Seems like with this schema that a smaller contributor can be left out in the cold more often and not have as regular payouts. Even if they contribute with a regular and consistent hashrate. Is this correct?

Actually, no.  The system is basically tailored to work best for miners with ANY consistent hash rate.  The variance of lucky and unlucky blocks will let any miners average around 100% PPS, with the pool never "forgetting" about any share's value, even for a 1MH/sec miner.  Granted, it will take a smaller miner much longer to reach our minimum payout (which I believe I will be calling a vote for adjustment), but, that's with any type of minimum payout at any pool.

But, overall, CPPSRB works best with any consistent miner.

-wk

[organofcorti]

.....
But, overall, CPPSRB works best with any consistent miner.

-wk

Are you certain about that? How are intermittent miners penalised? I'd thought CPPSRB was fine for all miners, big or small, consistent or intermittent.

[GigaWave]

Yes it does. Thank you.

Seems like with this schema that a smaller contributor can be left out in the cold more often and not have as regular payouts. Even if they contribute with a regular and consistent hashrate. Is this correct?

Actually, no.  The system is basically tailored to work best for miners with ANY consistent hash rate.  The variance of lucky and unlucky blocks will let any miners average around 100% PPS, with the pool never "forgetting" about any share's value, even for a 1MH/sec miner.  Granted, it will take a smaller miner much longer to reach our minimum payout (which I believe I will be calling a vote for adjustment), but, that's with any type of minimum payout at any pool.

But, overall, CPPSRB works best with any consistent miner.

-wk

When you say 'much longer'. What are the timescales? I'm mining at aprox. 800 MH/sec. Could you guess a average payout window?

Just asking because as i've experienced mining here for the past 3 days, is after 2 days I became stuck about half way under the minimum payout. Which I understand is due to a run of bad luck, and I'm not actually losing money.

[Luke-Jr]

.....
But, overall, CPPSRB works best with any consistent miner.

-wk

Are you certain about that? How are intermittent miners penalised? I'd thought CPPSRB was fine for all miners, big or small, consistent or intermittent.

There's no penalty. But a intermittent miner would throw all their shares within a certain part of the share log, so the possibility that part of the sharelog goes unpaid would mean a higher % lost than if the same shares were spread out over the sharelog more.

[wizkid057]

Good morning,

Just recently the server suffered from some issue likely related to our postgresql database software. We're investigating further and I will post details later today when the cause is determined.

No systems compromised and no data lost.

Thanks

Wk

[wizkid057]

Good morning,

Just recently the server suffered from some issue likely related to our postgresql database software. We're investigating further and I will post details later today when the cause is determined.

No systems compromised and no data lost.

Thanks

Wk

Greetings,

Just an update, stats are back online.

I've traced the issue back to some type of disk i/o hang early this morning, which caused enough delay for stats update tasks to overlap.  That combined with accesses from the web server hanging and such caused enough of a resource pile up waiting on disk usage to hang the server for a bit.

I've adjusted some settings and will be putting better checks in the stats update scripts to make sure that this doesn't happen again in the event of some i/o hang.

Still investigating the initial cause of the i/o hold up, but, I doubt it is anything serious.

-wk

[organofcorti]

.....
But, overall, CPPSRB works best with any consistent miner.

-wk

Are you certain about that? How are intermittent miners penalised? I'd thought CPPSRB was fine for all miners, big or small, consistent or intermittent.

There's no penalty. But a intermittent miner would throw all their shares within a certain part of the share log, so the possibility that part of the sharelog goes unpaid would mean a higher % lost than if the same shares were spread out over the sharelog more.

I see your point if you compare CPPSRB to PPS. But compared to other non-PPS methods, it's not a penalty.

[muyuu]

Stats are down. In fact isn't the whole site down?

[wizkid057]

Trying to track down whatever is causing apache to go insane and spawn hundreds of processes.

I'll have it back up very shortly!

-wk

[purelithium]

has anyone done a study on how CPPSRB compares to plain PPS, in real-world stats? I'd be interested to see this if it's been done. Say a set number of shares over a period of time, how many get paid and how much is made compared to PPS.

[muyuu]

I hate it when having stability problems mean losing BTC you had already "earned".

[wizkid057]

I hate it when having stability problems mean losing BTC you had already "earned".

You never lose BTC you've earned, even if you or the pool goes offline for any issue.  I don't understand your statement.

[The00Dustin]

I hate it when having stability problems mean losing BTC you had already "earned".

You never lose BTC you've earned, even if you or the pool goes offline for any issue.  I don't understand your statement.

The line on the chart drops when you stop mining or sometimes when the pool goes offline.  This is because each share is worth less once difficulty is exceeded, and you aren't submitting more shares.  This makes it look like you had earned BTC and are losing them.  IMHO, the chart should behave differently, either it should have a third line for "CPPSRB BTC this round" (that doesn't include ec, which can show up after a block is found), or the line on the chart should only change when blocks are found (or orphaned) like it used to, with only the EC line moving during a round.

[wizkid057]

I hate it when having stability problems mean losing BTC you had already "earned".

You never lose BTC you've earned, even if you or the pool goes offline for any issue.  I don't understand your statement.

The line on the chart drops when you stop mining or sometimes when the pool goes offline.  This is because each share is worth less once difficulty is exceeded, and you aren't submitting more shares.  This makes it look like you had earned BTC and are losing them.  IMHO, the chart should behave differently, either it should have a third line for "CPPSRB BTC this round" (that doesn't include ec, which can show up after a block is found), or the line on the chart should only change when blocks are found (or orphaned) like it used to, with only the EC line moving during a round.

First, let me quickly clarify that shares are never worth less in the CPPSRB share log. They are stored with the share value for the time they were mined.

Also, if the pool is offline, *no one's* balances are changing, so, no one could possibly lose earned coins.

Next, I agree that the graph should partition out the estimated earnings from the unpaid ("locked in") earnings. This is on my TODO list for the stats.

But, understand that you never ever lose earnings. If you stop mining during an unlucky round, then sure, your shares will be pushed further into the share log (dubbed shelved shares now, for shares not in the current block's payments) and just won't be paid immediately. They're never "lost."  The pool tracks and stores every single share and its value at the time of mining, and they are only removed from the share log once the block which paid them reaches over 120 confirmations.

Hope this helps.

-wk

[muyuu]

If I go offline for some maintenance work, will this affect my earnings? (yes or no)

Wish I had the time to study the system but I'm swamped with work.