Topic: Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB - page 176. (Read 1061436 times)

Website is up but stratum url is down for me, all my miners switched to backup pool now 

No up for me fine

Is Eligius down?

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.

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.

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.

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

Have seen a couple of hickups too.

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.

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://bitcointalksearch.org/topic/scam-scam-scam-nmc-walletcom-497899

Better change it before WK gets on the big payout 

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

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.

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)

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

Thank you.

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

Or transaction fees.

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

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"

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.

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.

thanks, appreciated response.