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

I am glad that you have become more proactive in the daily concerns of the pool

If the pool gets super lucky and pays off the entire share log so that there are zero shelved shares, then any excess earned from blocks that pay miners 100% PPS is kept in a buffer as sort of a rainy day fund.  While things continue, when the pool finds a block that was in an unlucky round the pool taps that buffer to still pay miners 100% PPS until that buffer is depleted, effectively overpaying miners for those rounds.

In no cases does the pool end up with anything extra to keep for itself or anything, it all gets paid to miners.

I love this pool. Thanks wizkid057.

I have a question about the payout. So, let's say the pool was lucky more than once, and paid all the share logs. and, let's say the pool kept doing well, and maintained being lucky +100% five or six times in a row or even more. Now, where does all the remaining balance of the reward go? I mean, is it possible that the miners get more rewards for their shares similar to PPLNS in lucky rounds if their is a remaining balance?

Change the value of a share?  It's based on the difficulty derived from the bits field of the actual share submitted, actually, so every share is perfectly valued for the work it was done for.

I think the question is: at what point do you change it?
Each share is within a network block, so each share should be valued as per the network block it was mining.
Thus the value should of course be at the point when the share was submitted.
(that's what I use on my shifts page - I also break shifts at a diff change to avoid having to resolve that issue)

A share is saved in the CPPSRB share log as work_difficulty/network_difficulty.  This is applied to the block subsidy, currently 25 BTC.  So 25*(work_difficulty/network_difficulty) currently.

This doesn't change when the difficulty changes later, so your shares don't get devalued.  100% shares rewarded means that luck has been decent and you've been paid 100% PPS for every share you ever submitted to Eligius.

Hope that helps.

There's a LOT of perverse pages on this forum Thankfully, not too many in this thread.

My apologizes  I should have asked the question a little different.

How it is possible to get 100% shares?

How do you value a share?

I knows it's PPS value is, of course, at the time the share was submitted, not later. Valuing a share later, with this last block change, will effectively devalue some of my shares significantly and thus boost the PPS % artificially right? Or is that incorrect?

Just trying to grasp the inner workings a little better. Any clarification would be great and again my apologies if this has already been answered on perverse pages.

Of course it's possible.................. just unlikely long term.

Can you get 100% shares? I didn't think that was possible.

Take a look here

http://eligius.st/~wizkid057/newstats/userstats.php/1NwhghHvQvcH3Jf97rBR8Wd3iVA2ikXYZ8

BTW what a nice day at Eligius 7 blocks so far today!

Correct.

It's worth noting that #s 1 through 3 are much less common than #4, however.   In the past four years and over 10,000 blocks there has only needed to be 174 manual payouts.  Less than one per week on average.

I only used the word eventually because it wasn't instant.  I didn't mean to imply some enormous stretch of time... in my head it was seconds .

So, if I'm reading your latest reply correctly, you'll have potentially 4 types of blocks:
1) A block with only a single coinbase transaction sending the 25BTC to your offline wallet
2) A block with only a single coinbase transaction sending the 25BTC to your miners
3) A block with all kinds of transactions, but the coinbase sends the 25BTC to your offline wallet
4) A block with all kinds of transactions and the coinbase sends the 25BTC to your miners

Any of the "offline wallet" blocks require you to, at some point in the future, do a manual payout run.  Otherwise, the miners get the virgin coins from the block generation.

Thanks again for taking the time to reply.

You are correct.  The actual aggregate bandwidth use is higher now than it was.  However, it's not much.  The 'template work' is very small and all miners are updated with a fraction of the bandwidth needed for a full blown update.  The benefit is that now I can stagger the second update to better level the bandwidth spike so that the pipes never gets close to saturation.

Just keep in mind that "eventually" in your post is actually in practice under 5 seconds.  I think at the high end it took ~12 seconds for the reward system to catch up.  Also, transactions and coinbase aren't tied together.  A work update is pushed when one or the other or both are ready.

It does, thanks.  I was all kinds of confused about what you were actually sending if you didn't send the coinbase at least out to your miners.  Now I know how you're managing it: you send out what is effectively a "template" block that contains only a single coinbase transaction directing the 25BTC to your offline wallet.  Eventually you send the actual coinbase transaction with all of your miners who expect to get paid by this block, along with the set of unconfirmed transactions you'll include in your block.

I realize you're avoiding a bandwidth spike initially, but you're actually increasing your bandwidth needs overall, right?  Initial spike uses less bandwidth because it's transmitting a pretty small chunk of data to your miners.  Larger data transmission occurs shortly thereafter.  However, if you transferred the "actual" work only, then you'd never deal with that first "template" work.

Anyway... it is what it is.  Thanks for the reply .

Yes, I'm sending a 1 transaction coinbase-only block to the miners to get everyone on the same page.  Generally in under 5 seconds all miners receive a second work update (not restart, though, to prevent miners from wasting work) with a full coinbase and transaction set.

If someone finds a block based on the initial work you get a block like the one that we just found: https://blockchain.info/block/000000000000000001cfa3cab398b147e83ceac5342423e2f8d887fe3fd799a3

The coinbaser/generation transaction generally takes about 2 seconds to fully update and verify, due to some security measures, when a new network block is found.  The pool gets work out to miners before this is done generally, so, the coinbaser will instead pay the pool's offline wallet(s).  Once the transaction verifies (120+ confirmations), and I have a moment to do so, I do a manual payout to the payout queue.  You'll notice that the payout queue grows by about 1 block reward any time this happens.

If the reward system can quickly verify the status of the new block (was it an Eligius block or not, mainly, among other things), the quick block change work can actually have a small coinbaser paying miners, a highest balance descending list (I haven't seen this actually happen yet).  Since GBT miners can submit blocks to the network independent of the pool, the pool must check all network blocks against the reward system to see if they are Eligius blocks (yes, this has happened).  These days GBT miners are a smaller percentage of the pool, but they're still there.

Hope this helps.

Hi wizkid057,

I read through your explanation and was wondering if you would mind providing a bit more detail on the following statement you made:

If I am reading that correctly, you're sending out an empty block to your miners, getting them on the latest block as quickly as possible, and then sending out the full set of transactions and coinbase afterwards.

My question is, what happens if a miner happens to find a block prior to receiving the latest work/coinbase?

Thanks!

The first Eligius v4 block came out, #385974 .
Brillant ! 

You know, you're right about one thing.  I did make a personal vow to ignore you and to delete your posts in this thread.  Unfortunately, with my sanity on the line, I will now break that.

You're an idiot.  You're a complete total and utter fool sometimes (most of the time?).  You have no respect for anyone here whatsoever.  You twist my words and others to fit your own mindless scenarios and your imagination of how things are actually working with little or without any real knowledge or experience with the topics you pester me about. You follow me around this forum like a stalker and there is very little I can do about it, unfortunately, and it's really f*ing old.  Seriously, just crawl back into your cave and die because I'm beyond sick of this sh*t.  You don't find me following you around this forum posting against everything you write regardless of merit.  The fact that you feel the need to do this with me shows your true character and how your words have no value whatsoever.

Now to take out the trash by completely slaughtering your post.  I've no reason to delete it while it provides me with an opportunity to bring into the light how much of a troll you really are.


You "pointing out" the slow block change times from before means absolutely jack to anyone with a clue.  I've repeatedly explained exactly why you and others were getting the results you were getting, but you refused to listen or accept the actual facts.  For the record, again, the connection prioritization in place to mitigate the bandwidth spike on block changes was entirely the cause of this.  Because kano (and one other who tested and pointed this out in a much more respectful manner) never actually mined on Eligius for any length of time with any real hash power (generally none, resulting in a zombie connection at literally negative priority) his connections were never prioritized and were obviously delayed while actual miners were given work updates.  But no, the trolling had to continue despite the facts.  (TLDR version:  Don't call me a liar, asshole.)

Orphan rates have been on par and normal despite kano's trolling.  Eligius has been around for quite a while and has mined well over 10,000 blocks through just the latest and longest running revision.  Just Eligius-Ra, the revision that began at the beginning of 2012 and will have been running for four full years in a couple of months has the following stats: Confirmed blocks: 10128 blocks --- Stale blocks: 231 blocks.  For those of us capable of doing math, this comes out to 2.2% stale blocks.  Just looking at data I have from my own bitcoind, the network wide stale block rate is higher than 2.2% just based on stale blocks that reached my own node (and were reorged).  Since it's impossible for my node to have seen every stale block from every pool and miner, it stands to reason that the network wide stale rate is much higher than 2.2%.  Looking at the block change latency of some of the major pools it's pretty obvious that it would be.

Kano's own pool has been running about a year, roughly 25% of the time that the current version of Eligius has been online and has mined 368 blocks as of this writing, a whopping 3% of the blocks Eligius has mined and has data on.  I don't know about you, but I'm reasonably certain Eligius has much more valid long term statistical data.  So while kano's young pool may have about 0.5% stale rate over 368 blocks, let's check back in about 30 years when that total block count catches up to what Eligius's today and see where things actually stand.  Kano saying Eligius's orphan rate is high is like a guy at the roulette table who is up a few % after a few hours going around telling people that this roulette table must be better. lol.  Pretty sure I'll stick with legitimate long term stats on the topic when discussing it.

Why I did anything about it was to get rid of the connection prioritization method that was in use and to level the bandwidth spike that was happening on block changes.  New method allows a small bandwidth spike to get all miners on the new block, followed by a staggered updating of full work and coinbase on miners spread over the next several seconds.  This way latency stays as low as possible since at no point are things saturated.  As an added bonus, even zombie connections with low priority get block changes pretty much instantly which makes it all the simpler to just give kano the finger.  Especially since with the latest updates Eligius is getting block changes out to even the lowest priority miners a full 0.5 seconds faster than kano's pool averaged over the last several days.  We'll just ignore the fact that Eligius has exponentially more miner's connected.

Overall, and as I mentioned in my post above, Eligius's block changes *are* in fact faster than they were using the previous code (mostly just Eloipool's p2p-based speedup).  The issue previously was that eloipool would quickly get the new work out to some miners and immediately be trying to send full work+coinbase to miners before everyone was on the same page, resulting in a saturated outbound pipe and only prioritized connections (basically ~90% of the pool's hash rate) getting the work in the best time possible.  Slower miners and zombie connections would be delayed slightly as the saturation subsided.  Now the initial work change is even faster AND I stagger the second update to not cause a massive bandwidth spike.  Win-win, and nothing to do with kano.  So my post "means" exactly what I said it means: Improved reliability and responsiveness for all Eligius miners.

I'm still looking for these pools 10x the size of Eligius that have (or had) faster work change times... the only pools that are 10x larger than Eligius or more are the four large Chinese pools.  Two (maybe three?) of these do unsafe headers-only mining.  One of them has block change times that are so horrible they should be getting 10% stales.  The one I thought did headers-only mining is actually 4x slower at block changes than Eligius, so... yeah, not really sure where this comment actually comes from.  Let's also keep in mind that Eligius's coinbase transaction is generally about 6KB, where basically every other pool (besides p2pool, which doesn't really have bandwidth constraints) has a coinbase transaction that is less than 0.2KB.  Combine that with Eligius constantly trying to mine max sized blocks and work updates start to get quite bandwidth intense when all miners need updating.

As of right now the block change benchmark stats show Eligius as the fastest non-headers-only mining pool on the list.  Admittedly, kano's pool is #2 trailing Eligius by only a half-second on average.  Slush is close following by about a second, and the rest are multiple seconds behind Eligius.

And I'm not sure where you get the "something like 30 servers" nonsense, either.  The actual number of machines Eligius uses is not public info, for one, and it is well below 30.  Imagine how awesome things would be if we did have 30 servers though.

Having thoroughly explained why your post is complete nonsense, if you post here again with anything other than, "You're right, I apologize." or something similar, I'll re-up my resolve and just revert back to my delete-on-sight tactic of maintaining my sanity.

TLDR version:  kano is a troll, as always.

Edit: Apologies to those coming here for actual updates and relevant on-topic discussions.  See my update above as the latest pool news: https://bitcointalksearch.org/topic/m.13104399

Edit: Deleted a response by kano without reading it.  Skimmed, did not appear to be an apology.  Looked like some nonsense about orphans again.

Yes no doubt you will now delete this post ... but I think you need to point out to your users what your post means.

Your post means that in the past year (or very likely a lot longer but I've not directly checked this) the pool block changes have been slow.
I've pointed that out in various places on the forum and in the bitcoin git.
Both luke and you have lied about it, saying it wasn't true.
Yet your orphan rates over the past many years have been high and quite clearly stated that your block change times were slow.

In reality, it would seem the only reason you did do anything about it is coz I kept pointing it out ... and it was true.

Yes I do know who wrote the benchmarking log changes to cgminer that you are referring to above helping you see what I said was true.

Also, remember, there are pools 10 times the size of this pool, still able to send out work ... so using that as an excuse was also deception
You have something like 30 servers that should be able to send out the work of a single server only a 30th of the size of your pool ...

Working on a new round of back end updates this week.

In the meantime, I figured I'd share one of the latest improvements from the last round of updates.  Eligius now gets block change related new work out to all miners as fast as possible without cutting corners (no headers-only mining).  Even with hundreds of thousands of miner connections at times (I know, it's ridiculous...) Eligius gets updated work to all miners faster than virtually every other public pool (not counting those that cheat and unsafely don't verify blocks before pushing new work).

The effect is that Eligius miners are updated and working on the latest verified data more quickly and thus less of a chance of working on outdated or stale work.  Stale work rates have dropped nearly to zero and I've all but removed some previously instated connection prioritization that was in place to get new work to higher hash rate miners faster since the newly designed setup is effective even without that in place.

Eloipool already does some speedups along these lines, when configured correctly, but my updates have improved upon even the original speedups, so much so that Eligius's block change times are faster than even some other pool softwares running on pools with connection and user counts multiple orders of magnitude less than Eligius where something like pushing new work to miners should be a piece of cake.  Admittedly patting myself on the back a bit here, but I think it is a decent accomplishment.  The previous method was good, but wasn't the absolute best it could have been.  Now it's pretty much there, without cutting important corners like a couple of pools are doing.  Again, Eligius mines only on top of fully validated blocks.

Once I've fully validated and cleaned up the code I've been working on to make this possible I plan on releasing it under an open source license.  There are actually some more improvements I plan on making on this before that happens, shaving even more time off of the work update process.

Some special thanks goes to some others for help with benchmarking block change times across the network and across other pools.  I'm not sure if they want to be mentioned by name or not, but will edit accordingly if they desire.

I'm doing my best to make sure Eligius maintains an important place in the bitcoin community as a reliable pool for all while sticking to the original ideals behind it:  No registration, no fees, as much transparency as possible.  I'm proceeding with work to improve the web front ends to a more modern and aesthetically pleasing look as well.  Some back end updates are taking a bit of priority over that, but still moving forward.  Keep in mind that Eligius is a 0% fee pool that is run entirely by volunteer work and donations.  I dedicate a good amount of my free time to keeping things running smoothly here, and I intend to continue to do so.

I'm open to suggestions for improvements as well, so please don't hesitate to contact me if you have an idea that could make Eligius better than ever, especially if you're volunteering to help with making that idea happen.  I try to answer all emails and messages, but sometimes I just get too many and don't have time to answer every single thing.  So, I promise I'm not ignoring anyone when they contact me and I'm not offended if you try again later on if you don't hear back.

Next up on the back end updates list: Physical relocation of the web server to improved hardware.