Well:
1. You recieved more from Eligius that if you were mining alone. If you had mined alone and found 3 blocks, you'd have 75 BTC. Mining on Eligius,  you received 79 BTC.
2. Having 97% shares rewarded puts you around the same average than the average miner around here, as, even with 0% fees, the pool cannot get to 100% PPS due to work lost on orphaned block. You would do no better mining alone, as you would have a slight chance too of seeing your blocks orphaned.

Since this pool is 0% fee, your expected reward would be exactly the same. However, you'd have greater variance mining alone. So no reason to not mine into a pool.

Ok, I may have answered a lot of questions on this forum, but I have one now.

It has been often said on this forum that because of the orphaned block, the pool payout to miners converges to about 97% PPS, instead of 100%.

Therefore, if blocks were -never- orphaned, the payout would converge to 100% PPS. However, it is my understanding that when a block is orphaned, the pool (and the Bitcoin Network) act as if that block had never existed.

Therefore, I do not see how it makes a difference to the payout value that some block are orphaned, since acting as if it had never existed, is the same as if no block was ever orphaned, no?

Indeed, the full Bitcoin network has difficulty of any arbitrary value, but I've never seen a pool (any pool! not just this one) that sent share of values not multiple of two.

The ideal mathematical case is that it takes infinitely many steps, so you never reach 0, but Bitcoin cannot be subdivided smaller than 0.00000001 BTC. In 2140, the reward will round down to 0 and no new bitcoins will be created. However, that is very far in the futures, and many things will change from here. (One probable thing that might happen is that the protocol might be modified to make bitcoin divisible to smaller unit)

Anyway, the point is moot, as it is know that the current algorythm of Eligius is unsustainable in the long term. It is built as if transaction fees do not exist; and indeed at first it didn't even pay them to the miners. The fact that the transaction fees are put toward paying the share log is a relatively new thing (a few months), but the shares are still 'created' as if the the transactions fees were not paid to the miners.

That problem is not really significant currently, because the transaction fees are insignificant, but I'm pretty sure the pool operator will address this when the transaction fees will become significant. It is just difficult to devise a "fair" way of paying the transaction fees to the miners, because contrarily to the block reward, their value is unpredictable and varies a lot.

I just changed it anyway, made that section more detailed.

I just tought that it might help people undestand how this pool works by making a summary of the pool operations in list form.

A) The pool maintains the following:
1. A share log.
2. A payout queue.
3. For each user, a record indicating their own personnal balance, their payout threshold, the date of their last payout and the date of their of their last account activity.
4. An offline wallet.

B) Initialization
1. The share log and the payout queue begin empty.
2. The personal balance of each miner is initialized at 0; and the date of their last payout and their last activity is initialized at the date they begun mining.
3. The payout threshold is chosen by each miner, if none is given, it defaults to 0.04194304 BTC.
4. The offline wallet begins empty.

C) Unit of accounting
1. The basic unit of accounting in Eligius is a "share". A share is 'worth' block_reward/bitcoin_difficulty. (At the time of writing this: 25 BTC/17 336 316 979 = 0.000 000 001 442 BTC)
2. The value of bitcoin_difficulty for a given share is the difficulty at the time the share was awarded. It does not change later when the bitcoin difficulty increases.
3. The value of block_reward, however, is always taken as the current block reward. So when the block reward will be cut in half in 2017, the 'value' of all the shares still in the share log will be halved.

D) When a user submits a miner share (a valid proof-of-work meeting the difficulty requirement of the pool, pdiff):
1. The pool adds to the top of the share log pdiff shares. These shares are identified as belonging to the miner who submitted them.

E) When the pool finds a block:
1. 25 BTC+Transaction fees worth of shares are removed from the top of the share log, and credited to their respective miners' record. Each miners who was credited at least one share has it's date of last activity updated to the time the block was found.
2. If a miner was payed out with the generation transaction of that block, the payed out amount is removed from it's personnal balance. The date of their last payout is updated to the moment the block was found.
3. The pool refreshes the payout queue, see below.

G) How the payout queue is built:
1. Each user records are checked. Miners whose personnal balance is above their payout threshold are put in the payout queue. Miners whose date of last activity is older that a month are also put in the payout queue.
2. The queued miners are sorted by the time of their last payout, the oldest first.
3. The pool then goes down the list and finds the last queued miner such as the total of the balance of all the miners above him (including him) stays below 25 BTC. All those miners are put in the generation transaction to be put in the next block the pool finds, to be payed the full amount of their balance.
4. If the payout queue does not contain 25 BTC worth of queued miners's balance, the exceeding amount is sent to the pool's offline address.
5. While the pool computes 1, 2 and 3 (it takes time), it makes the miner work on a simple block that would send all the generated amount to the pool's offline address, to not waste miner's work.

H) When the payout queue grows longer that a few hundred BTC:
1. The pool operator initiates a transaction with the bitcoins in the offline wallet, paying everybody in the payout queue (except those in the first block, so that miners still have something to work on) the full amount of their balance.
2. If a miner was payed out with the manual payout transaction, the payed out amount is removed from it's personnal balance. The date of their last payout is updated to the date the transaction was submitted.
3. The pool refreshes the payout queue.

I) When the Bitcoin network orphans a block found by Eligius.
1. Everything that was done when the pool found the block (see E) is completely reversed.
2. Safe mode is triggered, see below.

J) When the pool is in safe mode:
1. The pool works mostly as normal, meaning submitted share are recorded as belonging to their respective miners, and when a block is found, those shares are credited to the miners' balance.
2. However, the automatic payout by generation transaction are disabled: The pool will always mine to the offline wallet until the situation is checked by the pool operator, who'll do some sanity check to ensure everybody is receiving their due amount. If everything is OK, the pool will resume normal operation.
3. During safe mode, the payout queue and the stats displayed on the main site may of may not be correct.
4. Safe mode may be triggered by an orphaned block, but it may also be triggered when a checks built into the pool software fails for whatever reason, it is however usually benign, but better be safe that sorry.

Difficulty is a power of 2.

Difficulty indirectly represents the number of zeroes a the binary representation of a block hash must begin with to be considered a valid share.

The formula is :
Number of zeros necessary = 32 + log2(difficulty).

So a diff1 share begins with: 0000 0000 0000 0000 0000 0000 0000 0000 XXXX XXXX....

A diff2 share adds one 0: 0000 0000 0000 0000 0000 0000 0000 0000 0XXX XXXX....
Since it cuts in half the number of valid shares, the "difficulty" of finding a valid share is doubled.

A diff4 share adds another 0:  0000 0000 0000 0000 0000 0000 0000 0000 00XX XXXX....
The number of valid share is again cut in half, so the amount of work necessary to finding a valid share, relative to a diff1 share, is 4 times.

You can see, then, how and why the difficulty is constrained to powers of two. Furthermore, putting a non-power of two in the above formula would result in a non-integer amount of zeros necessary, which is impossible.

At the protocol level, the most meaningful value is the number of 0s, but difficulty is more useful and meaningful reprensentation for us humans, since we are mostly interested in the amount of work we'll need to do, and not what a correct answer looks like.

I'm gonna explain with a simple example, in which there are only two miners: a slow one and a fast one. Both mine continuously at a constant hashrate.

Every time someone submits a share, that share is added to the shelf. The 'value' of such share is 25 BTC/bitcoin_difficulty. That is totally independent of the speed of the miners.

The share shelf contain mostly shares of the 'fast' miner, with the slow miners shares more or less uniformly dispersed trough it. The relative proportion of the fast vs slow shares in the shelf is the same as the relative proportion of their hashrate, and thus the same as the relative proportion of their fair reward.

Every time the pool finds a block, it will pay the topmost 25 BTC worth of shares of the shelf. As stated earlier, since the shares are uniformly distributed and in a fair proportion between the miner, the payed amount to each miner is fair too.

The difference between a short and a fast round is that in a long round, all miners will receive for that round an amount less than what would be expected just by the number of shares they submitted (and the shelf grows), whereas for a short round, miners will receive more that what would be expected just by the number of shares they submitted (and the shelf shrinks). However each round pays exactly the same amount, and that payout is fair, because it is in the same proportion of their respective hashrate.

Not on the website. However, I think the server honors difficulty requests sent by stratum as a command-line option of your miner.

I just read your explanation: Very well done!

I just have a suggestion for a small improvement: You should make it clear that "shelved shares" represent an amount of work the pool recognises you have done but have not yet paid, for it has never found enough block to pay for them. So "shelved shares" are, by themselves, worthless; they do not reprensent an amount of coins the pool "owes" to you. They will, however, be payed in a "best effort" basis, as soon the pool finds coins to cover them, if it ever does.

On the other hand, your account balance reprensents coins the pool "owes" to you; that it has found enough money to pay for. The whole "account balance" thing, and payout treshold, is not essential to the CPPSRB system; in fact, miners could always be payed for their rewarded shares immediately, every time a block is found. This would, however, result in HUGE generation transaction with thousands of outputs, most of which are ridiculously small amounts. Although valid by the bitcoin rules, this would be undesirable because a) Certain clients have a bug in their handling of transactions with too many outputs, and b) The miners wallets would be made of hundreds of small amount outputs; when they will be spent, all these outputs will need to be merged in a single big transaction that will cost a lot in transaction fees to the miner.

So Eligius' operators have found preferable to delay the payout of rewarded shares until a reasonable amount has been accumulated by a miner. However, while the payout is delayed; the pool HAS that money on hand, and so, if it were to ever close down, it should have enough money in it's offline wallet to cover every miners' balances. (And none of their shelved share) One can check the balance of the offline wallet address (18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B) and quickly check that it has enough money to pay for the entire payout queue (http://eligius.st/~wizkid057/newstats/payoutqueue.php/), the remainder being the balance of all the miners who have not yet crossed their treshold.

You can go check on the payout queue page. (http://eligius.st/~wizkid057/newstats/payoutqueue.php) A good rule of thumb is that you will never receive two payout faster than the "age" of the last payment in the first block of the queue. AND THAT, REGARDLESS OF YOUR THRESHOLD.

If your theshold is set such that you cross it at longer intervals than the queue time, you will be immediately payed when you cross it. If you cross your treshold at a shorter interval that the queue time, your threshold essentially does nothing (it might as well be 0), and your payout interval will be entirely dependent of the fluctuations of the queue.

The last payment of the first block, at the time of writing this, is 1 week, 6 hours and 29 minutes old. People who have received their last payment earlier than 1 week, 6 hours and 29 minutes ago will have to wait longer before their payout.

A queue longer that a week is a bit long I admit, usually it is more around 3-4 days, but it is not unheard of. However, wizkid has stated earlier in this thread that he will do a manual payout soon, which should help shrink the queue.

First, to clarify, shelved shares are not "owed" to you. They represent work you did that the pool has not yet found money to pay for yet. By the CPPSRB rules, theses are "worth" nothing until the pool finds enough blocks, if it ever does.

However, rewarded-but-unpayed shares (your account balance that grows until you hit your treshold then you get payed) is indeed owed to you; and if the pool were to close down, it must have enough money on hand to pay for them for all their miners.

---

Right now, the cold storage address has 777.68 BTC, and the payout queue is 652.41 BTC long. So Eligius has more that enough money to cover the queue. The remaining 125.27 BTC would then cover those who were rewarded BTC but have not yet hit their treshold. (However, I do not know how to check it these amount equals, but it does seem a reasonable value.)

So, no need to worry.

---

The cold storage address is 18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B. It is mainly funded in the following conditions:
- The pool is in failsafe mode.
- The total amount of BTC in the queue is less that a block's worth. (i.e., not enough miners are above their treshold)
- Two blocks are found so fast by Eligius that it had not enough time to properly compute who gets what amount.

In usual condition, the miners are payed directly from the generation transaction, so the queue length does not grow. (it will of course vary a little bit according to the different miner's threshold, but it averages out over a sufficient long time)

When one of the above condition is met, since miners were not payed by the block, the queue grows, and fast. But, that money will be sent, manually, some time later.

---

The cold storage address is also sent 0.00000001 BTC each time Eligius finds a block. It can be used to quickly check directly on the blockchain if Eligius has found a block even if the pool's webserver is down.

CPPSRB and PPLNS are very similar. CPPSRB is usually presented as a variant of PPS, but it could as well be presented as a "PPLUNS: Pay per last unpaid N shares".

The difference is mostly for occasionnal miners I believe. In PPLNS, your reward are ONLY affected by the luck as you are mining/shortly after. If you submitted a share just before a luck round: cool! you get great rewart. If you submit it before an unlucky round, boo, you get nothing. After a while, your share is "lost", and any change in luck will nut change it.

In CPPSRB, even if you submit a share just before an unlucky round, and it gets shared, if it is lucky later on, even when you are not mining, it will be payed.

Of course both methods converge to fair PPS value. However, in PPLNS, only luck shortly after you have mined affect your payout, whereas in CPPSRB, any future luck even if you were not mining during the lucky round, will help your payout to converge.

I would guess it's because your paout priority made it so you were the last one the mined block, and the full payout didn't fit in that block, so it payed what it could. But what was left unpaid was under your payment treshold, so you were no longer in the payout queue.

No, not yet, but WK said he'll try to do something about that.


As far as I know, as long as you do not put in an NMC address, you do not earn any NMC, the pool keeps them. That's how it can afford to do 105% PPS for NMC, by splitting the earnings of all the miners who do not claim it.

Correct me if I'm wrong, but except for a few hicups of a few hours here and there, payout was working well most of the time? There was a BIG problem a few months back, but it has been quite some time ago, and it was blocked for a week or so. Since then, nothing that blocked payout for more than 2 days!


He has repetitedly stated he does not want to do that. I'm not quite sure why he cares son much about that, but he really wants that there exists at least one free public-usable bitcoin mining pool of minimally good quality.

CPPSRB is immune to pool hopping. People can come and go, and they only get payed the fair amount of their submitted share.

I remember when they started paying transaction fees to miners. There was no "simple" way to do it under CPPSRB, so they decided that for the time being, the "worth" of a single stays the same, that is, the block reward divided by difficulty, but both the block reward and the transaction fees go torward paying the share log.

Thus, currently, Eligius paying out shares a little faster than it generates them, so that over the time, the unpaid share log would reduces in length. This is not sustainable in the long term, however, that log is so big that it will be many decades before the entire share log is payed like that. (Unless transaction fees increase dramatically) But when/if it happens, another way of paying the transaction fees will have to be devised.

You made me realise a mistake in my analysis; you are right that luck does not influence the queue length by itself as shelved shares are payed and offset this exactly. The only "natural" cause of queue length variability is payment treshold effects.

What I DID calculate though, is the increase of each miner's shelved shares. But since it increases in sqrt(N), N being the number of shares you submitted, even if continously increases, then the relative fraction of your shelved shares over all your shares decreases.

Since I made a mistake, my code is pointless