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

[frisco]

Hi, I am sorry if this has been already asked but a naive search couldn't find anything.

Can someone tell me how the fees are distributed and what is the "Eligius Payout Change Aggregation" address?

I am trying to understand how the fees work and how it is possible that the payout qeue has grown from 1 block to 8 in less than 3 days.

As different addresses reach the payout threshold, they enter the payout queue.  A small amount of mining that is spread among many addresses can bring all of them across the threshold, and thus make the payout queue large, both in the number of addresses, and the amount of payout.

Even taking that into account that it should stabilize soon after the manual payout process. At every block 25BTC + fees? are awarded for every block and 25BTC+fees are paid, some people with previous pending balances can reach the threshold but after the manual payout a lot of users pending balance will be 0 (indeed the majority, right now with 8 blocks there are over a thousand address in the qeue and just 5500 hashing accounts, this weekend with 60 blocks in the qeue, almost everyone should have been in the qeue).

The question is, what does "stable" look like.  Large numbers of addresses enter the queue from relatively small recent earnings.  Many of these have had a long time elapse since their last payout, and they get put at the top of the queue.

One of my accounts has almost 2 BTC in the unpaid shares (I forget their name for these).  A few lucky blocks will pay those unpaid shares to me.  There are several things going on.  It would be interesting to write a program to model "steady state" using realistic account data.  That data is pretty available from Eligius.

Shelved shares are just the same as normal shares for CPPSRB, it will reward recently unrewarded shares (from this block of olders depending on the luck of this block), and as I understand it will always awards 25BTC (still unsure about fees), so every block 25BTC will be awarded and 25TC will be paid, shelved shares does not change that.

So in a perfect world when everyone starts at 0 earnings and there is not minimum for payout, the payout queue will always be 0, if it starts with good luck then some BTCs will go to the tip jar, otherwise shelved shares will appear, but the queue will be always 0, due to "Eligius Payout Change Aggregation" maybe over the time it will increase but really slowly (the change address always receive a little more than 0,001BTC).

With minimum payout then the first blocks will not pay the full 25BTC as while 25BTC was awarded only the fastest miners will reach their minimum to be paid that same block, indeed this is what happened during the first blocks after the manual payout.

Several blocks started to put a big share of the block in the change address from block #300169:
http://eligius.st/~wizkid057/newstats/blockinfo.php/000000000000000003fb8ec85a29533067c9b4d56dec9ed595b8f29fcaac9ca0
http://eligius.st/~wizkid057/newstats/blockinfo.php/000000000000000021d157974a2f46d4b546c536551556d1b5bb88461d8cf642
...
until block #300198 (http://eligius.st/~wizkid057/newstats/blockinfo.php/00000000000000002a2f650a9cbc4ba83ea92a97914c4b89ce300e7630ef7beb) where we entered in failsafe for just one block and queue started to grow (at this point there were 70BTCs not paid since the manual payout).
After that point there are some blocks with some noticeable change 6.6BTC in total.

And I have found the problem there were another 3 blocks in failsafe on 12/05, those add another 75BTC to the queue for a total of more than 150BTC, the queue is not at 187BTC so maybe there was another block in failsafe in later days or just unpaid balances reaching the minimum.


Looking at the blocks there are 3 problematic blocks that doesn't seem regular nor failsafe but those were before the manual payout:
http://eligius.st/~wizkid057/newstats/blockinfo.php/000000000000000020361d05189b54ff412115486568c83c648b04e796fe58de
http://eligius.st/~wizkid057/newstats/blockinfo.php/00000000000000004c8d86203de06bb320ea83aca3f82fd703caeedcf276433e

Still usure on how the fees are used and how does the change address, offiline address work, I thought that offline was just for donations, but it seems that it is used to store BTCs when there are no address to pay in the queue.

[raskul]

Namecoin merged mining continues as always.  Namecoin payouts are currently suspended but will be re-started soon, starting with a back-payment all the way back through March sometime (?).  At that time, an attacker somehow managed an insertion attack which changed all of the Namecoin payout addresses to a single address.  I believe the attacker walked away with 5-10 BTC worth of NMC, although I could be mis-remembering.  This did not affect Bitcoin payouts at all, only Namecoin.  It is all documented here in this thread.  After this attack, Namecoin payouts were suspended indefinitely until wk could find the time to implement a new solution.

thanks, appreciated response.

[un_ordinateur]

The question is, what does "stable" look like.  Large numbers of addresses enter the queue from relatively small recent earnings.  Many of these have had a long time elapse since their last payout, and they get put at the top of the queue.

One of my accounts has almost 2 BTC in the unpaid shares (I forget their name for these).  A few lucky blocks will pay those unpaid shares to me.  There are several things going on.  It would be interesting to write a program to model "steady state" using realistic account data.  That data is pretty available from Eligius.

I believe that the queue will ALWAYS increase.

Imagine, if the queue is 3 block deep. Under normal circumstances, the queue slowy grows as user submit shares and ear reward at the same rate that Eligius finds the block, thus one block per 2 hours currently. In that case, indeed, in steady state, the queue slowly grows one block, then a block is found, it decreases one block, and repeats.

However, luck is not considered here: with luck, blocks may be found faster or slower than shares are submitted (share submission rate is fairly constant compared to block rate). Thus, the pool may sometimes blocks faster, and the queue shrinks, and may sometimes find the longer, and the queue increses. Over the long time it averages, but this introduces variance. But even in case of incredible luck, the pool cannot have a negative block queue length. It that were to happen (the queue is completely emptied) then the found shares are put aside for a manual payment, so when thing will "average", those lucky blocks will not take part of the averaging, and will push the average queue length up. (until they are manually paid)

In a more mathematical analysis, if we "start" the pool at a queue of length 0, it will grow fast initially, as the the odds it finds a block faster that the submitted shares is high. But when it will be a few blocks deep, that queue provides a "cushion" that makes unlikely the queue will empty again. The longest the queue, the unlikelyest it will empty. But the odd is never 0, only decreasingly small... So it will ALWAYS empty again sometimes, but in longer and longer intervals, and each times it empties, it will grow a bit. One can then calculate that the expected growth of the cue is that it's length will be proportionnal to the square root of the time elapsed since the last time it was emptied. The exact proportionnality factor will depend on network difficuly, hashrate of the pool, etc... (For the mathematically inclined, sqrt(ht) (where h is the hashrate and t the time) is the standart deviation of a poisson distribution, the distribution that describes the bitcoin behavior. Correct me if i've made a mistake.)

I did not consider the fact that user can set a treshold. That increases the odds that the queue will empty up, because it is entirely possible that the pool has more that 25 BTC worth of unpaid shares as a whole, but that no user has crossed it's treshold. (I believe it maintains the square root proportionality rule, just with an increased factor.)

But the main reason the queue grows longer than 10 blocks on eligius is when failsafe mode triggers.

[un_ordinateur]

Here, I did some simulations.

I did 1000 trials. We start with a queue length of 0; and then for each trial, I "simulate" the rate at wich blocks are found, and we see the queue length as the number of blocks found.


It's a big mess. But when we average things out, we get:


As we can see, it clearly correlates with an square root function.

[frisco]

In a more mathematical analysis, if we "start" the pool at a queue of length 0, it will grow fast initially, as the the odds it finds a block faster that the submitted shares is high. But when it will be a few blocks deep, that queue provides a "cushion" that makes unlikely the queue will empty again. The longest the queue, the unlikelyest it will empty. But the odd is never 0, only decreasingly small... So it will ALWAYS empty again sometimes, but in longer and longer intervals, and each times it empties, it will grow a bit. One can then calculate that the expected growth of the cue is that it's length will be proportionnal to the square root of the time elapsed since the last time it was emptied. The exact proportionnality factor will depend on network difficuly, hashrate of the pool, etc... (For the mathematically inclined, sqrt(ht) (where h is the hashrate and t the time) is the standart deviation of a poisson distribution, the distribution that describes the bitcoin behavior. Correct me if i've made a mistake.)

There are a lot of misconceptions in your analysis, the odds of hashing a block with positive luck is exactly 50%, thats the reason we can define good or bad luck, and how the difficulty works.
On the other hand finding a block with good luck does not shrink the queue as you may take into account the shelved shares that everyone has, so you can assume safely that unless we hit a extremely lucky streak and all shelved shares all cleared, we will never award less than 25BTC, so the queue will only shrink due to payment limit shenanigans or manual payouts.

Also can you share the code or pseucode of your graphs, I am not sure how are you doing the calculations (not saying they are wrong, just I don't see where does they come from).

Also it is fun to note that in with the last 2 blocks the queue increased another 6BTC with "bad luck"

[Luke-Jr]

the odds of hashing a block with positive luck is exactly 50%

No, it's more like 63%. Because the longer-than-average time is unbounded.

the queue will only shrink due to payment limit shenanigans or manual payouts.

Or transaction fees.

Also it is fun to note that in with the last 2 blocks the queue increased another 6BTC with "bad luck"

Uh, bad luck shouldn't increase the queue length.

[RoadStress]

Noob question: What does the Shares Rewarded means? Luck? I'm having less than 100% and I want to know why.

You will always have less than 100%, unless the pool gets extremely lucky (or you are extremely lucky with your timing).  It is impossible to have more than 100%, even if you or the pool gets extremely lucky.  It correlates with luck, but not entirely.  Even with normal-to-good luck, orphan blocks will bring you down to 98% or so.  In my time mining with Eligius, I ranged from a low of ~90% to a high of ~97%.

See link in my sig for an explanation of CPPSRB.  Remember, the basis of CPPSRB is PPS (Pay Per Share).  You will never be paid for more shares than you have actually submitted.  If you want this possibility, you should switch to something different like a PPLNS pool.

Thank you.

[un_ordinateur]

There are a lot of misconceptions in your analysis, the odds of hashing a block with positive luck is exactly 50%, thats the reason we can define good or bad luck, and how the difficulty works.
On the other hand finding a block with good luck does not shrink the queue as you may take into account the shelved shares that everyone has, so you can assume safely that unless we hit a extremely lucky streak and all shelved shares all cleared, we will never award less than 25BTC, so the queue will only shrink due to payment limit shenanigans or manual payouts.

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

[frisco]

the queue will only shrink due to payment limit shenanigans or manual payouts.

Or transaction fees.

Umm this is a official confirmation that the fees are not awarded to shares but used to pay and thus reduce the overall pending balances?

Since yesterday the qeue has gone up and down so probably it is stable at 190-200BTC with fees reducing the queue a little bit over time (it varies from block to block, but the average is around 0,10BTC per block)

[un_ordinateur]

Umm this is a official confirmation that the fees are not awarded to shares but used to pay and thus reduce the overall pending balances?

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.

[Luke-Jr]

the queue will only shrink due to payment limit shenanigans or manual payouts.

Or transaction fees.

Umm this is a official confirmation that the fees are not awarded to shares but used to pay and thus reduce the overall pending balances?

Ah, no, you're right. I had forgotten wizkid057 changed that.

[freebit13]

Just a friendly notice to anyone using nmc-wallet.com for their namecoin mining because people are still getting caught out; they are a scam: https://bitcointalk.org/index.php?topic=497899.0

Better change it before WK gets on the big payout 

[GrapeApe]

Is anyone else having stratum connection issues?

Edit: I keep leaking shares to my back up pool and sometimes cgminer says Eligius is dead... while the other pools are alive.

Nevermind seems to have been a local isp issue that's now resolved(?) strange thought that the Eligius connection is so sensitive and finicky, it was labeled as dead while others were alive.

[RealMalatesta]

Is anyone else having stratum connection issues?

Edit: I keep leaking shares to my back up pool and sometimes cgminer says Eligius is dead... while the other pools are alive.

Nevermind seems to have been a local isp issue that's is now resolved(?) strange thought that the Eligius connection is so sensitive and finicky, it was labeled as dead while others were alive.

Have seen a couple of hickups too.

[PlanetCrypto]

no issues with stratum here.
stats server response seems "noisy".

[AbiTxGroup]

I have 14 miners running on Eligius and the past couple of days it seems like one of them goes to its backup pool every few hours.  I had no problems at all last week, this started around Saturday and is still happening.  I use stratum.

[daddyfatsax]

I have 14 miners running on Eligius and the past couple of days it seems like one of them goes to its backup pool every few hours.  I had no problems at all last week, this started around Saturday and is still happening.  I use stratum.

Had this issue with my Bitfury rigs when the DDOS started a month or so ago. I had to switch to BTC Guild in order to make them act right.

[thejewelrytech]

I have 14 miners running on Eligius and the past couple of days it seems like one of them goes to its backup pool every few hours.  I had no problems at all last week, this started around Saturday and is still happening.  I use stratum.

I was having the same kind of problems with BFG stratum running blades and also with the get work protocol and pool seemed my miners were being hijacked  and bounced constantly.Oddly enough my antminer S1 running cgminer was never affected by it? But I think the attackers were doing some kind of DNS spoofing? Not entirely sure? But when after I changed my miners DNS settings from pointing and using my  DNS as the router 192.168.1.1 to a public dns like google 8.8.8.8  the bouncing and hijacking completely stopped afterword? So it leaves me to believe they were doing some kind of spoofing since ever since I made the change it has yet to happen again?So not sure if its a coincidence it worked and wiz did something to make the pool stronger so its not a issue? But its pretty common to have a router using a I.P of 192.168.1.1 especially for mining so it kind of makes sense that's how its being done and they figured out a way to spoof that with stratum.
 I could be wrong ?but as seeing i don't have these issues anymore after doing this it leaves me to believe that was the problem since its been well over a week without having any hiccups or these issues as before?So if your pointing your miners to your router for DNS try changing that and see if it helps.

[Toolhead]

Is Eligius down?

[wedgy2k]

Is Eligius down?

No up for me fine