Bitcoin Forum

Note that the poll accepts votes for multiple items, and you can change your votes at any time (Edit: not anymore, thanks to this forum being buggy...). Please only vote if you meet the criteria for the options! Feel free to ask any questions in the thread...

After much discussion, I am leaning toward this two-part plan (or something like it)...

---

1. Setup new Eligius-Hu pool

This will have the PPLNS×8 reward system: when a block is found, its reward is divided equally* across the last <difficulty> times 8 shares. The number of shares has been chosen to be <difficulty> times 8 so that there is a 99.9% chance of any given share being paid; on average, each share will be paid 8 times.

That means that at the current difficulty 2,190,865, a block found today would reward 0.0000028527545056404662 BTC for each of the 17,526,920 shares preceding it, regardless of what "round" those shares were found in. After 8 blocks, assuming they are all within those 17,526,920 shares since the share was submitted, that share will have been paid a total of 0.00002282203604512373 BTC (equivalent to 100% PPS). If the pool gets lucky or unlucky, we might find more or less blocks within that window, all of which the share is paid for. This does potentially increase variance a bit, but an 8 block window should be enough to minimize it.

This summary is slightly inaccurate, as the shares will be of dynamic difficulty depending on your hashrate, and the value of each share will depend on your share-difficulty and the current block difficulty at the time the share is submitted, to avoid being hoppable during difficulty changes, and gracefully scale to ASICs as they are available.

There will also be a few under-the-hood changes to handle ASICs on Eligius-Hu: (new) BIP22 mining protocol support, and elimination of the permanent eternally-growing share database. The elimination of this database means the current Artefact2 stats will not work with this new pool unless someone steps up to update it. wizkid057 plans to write an updated stats interface.

You can express your support for this new pool only if you plan to use it by voting for the first poll option ("new Eligius-Hu"). If you are a current Eligius-Ra miner, and plan to leave the pool because you don't like Eligius-Hu, vote "dislike Hu" (option 5).

The default pool for the mining.eligius.st hostname will be changed to Eligius-Hu about a week after it goes live (miners can specify an explicit pool to use with the ra.mining.eligius.st or hu.mining.eligius.st hostnames). If you plan to mine on either Eligius-Ra or Hu at that time, and think the default should be changed immediately upon its availability, vote "Hu default" (option 2). If you explicitly think waiting a week more is a good idea, you can vote "Extra week at Ra" (option 6). Regardless of these votes, hu.mining.eligius.st is currently functional as a redirect to Ra, and will switch to Hu immediately when it comes online.

---

2. Gradual shutdown of Eligius-Ra pool

Since PPLNS×8 does not allow for carryover of existing Extra Credit (EC), Eligius-Ra will continue to operate until the block subsidy halves to 25 BTC (I would need to rewrite the pool software to make it survive the 25 BTC drop). Because of the near Miners who have a lot invested in EC may wish to continue to mine Eligius-Ra until it has been paid to their satisfaction.

Due to the extreme improbability of Eligius-Ra catching up to 100% PPS in this timeframe, it is proposed that it be changed to "SMPPSAM" (ie, an Active Miners variant) until it closes: this would mean inactive miners on Ra would not receive EC until/unless all the active miners are paid an amount equal to their current earnings first. Miners who have EC on Eligius-Ra or plan to be mining on it at that time may vote to support (option 3) or oppose (option 4) the Active Miners rule.

Edit: Note that with the Active Miners rule enabled, ex-miners who have unpaid balances under 0.67 BTC will finally reach the 1 week inactivity and get their payout. Also note that when Eligius-Ra finally closes, all unpaid balances (not EC!) will be paid out regardless of the amount.

Please note that Eligius-Ra may not be updated to handle ASIC load!

---

Poll option G is for future use should someone propose any other changes: do not vote on it until it is defined. If you have any possibly better ideas, please do bring them up!

Is there an 'end date' for this poll? If any/all of these proposals are adopted, what are the timelines like?

This sounds like a good strategy.  I understand the desire to engineer the ultimate-in-fairness payout algorithm, but at some point it becomes too difficult for miners to figure out what 1 BTC of EC is worth (0.99BTC in my wallet? 0.97BTC? 0.0BTC if the pool goes away?) and that uncertainty itself is a cost.  Ensuring that any uncertainty is resolved after at most Dx8 shares is a big positive.


That is a real bummer.  The Eligius statistics graphs are an awesome, awesome tool for debugging miner software, especially performance problems that appear and disappear intermittently.  I really hope the graphs stay.

Somebody may want to update the link in the announcement at the top of the stats page.

Eligius-Su? Wasn't that deactivated 6 months ago? The stats show the current server as Eligius-Ra.

Unknown right now. Depends on my free time.

As mentioned, wizkid057 will be writing new stats. Probably he will be using the superior dygraphs (http://dygraphs.com/) library too. If anyone wants to step up to update and/or maintain Artefact2's stats, I can easily help them get setup on the webserver...

Good idea, done!

Ouch, now I feel stupid. Fixed.

Edit: Note that with the Active Miners rule enabled, ex-miners who have unpaid balances under 0.67 BTC will finally reach the 1 week inactivity and get their payout. Also note that when Eligius-Ra finally closes, all unpaid balances (not EC!) will be paid out regardless of the amount.

Wow, a lot of hate for PPLNS? Why?

Might be something to do with your x8 implementation sounding somewhat novel and untested? It sounds to me like an interesting concept though.

At this point, Eligius is no longer the only pool that allows a miner to mine anonymously with just a bitcoin address - other than the stats graphs, I'm not sure what is unique about it now that may have been previously.

8xD is great, IMO, very low variance!

Do many other anonymous pools support getmemorypool, namely gmp-proxy.py? That may be another unique feature of Eligius (right now the biggest 'feature' is the EC drain  :( )

BTW, speaking of ASICs and gmp, can someone (Luke-Jr perhaps?) give estimates of bandwidth usage for getwork and using gmp-proxy on a per GH/s basis? Here is an old stack exchange article (http://bitcoin.stackexchange.com/questions/360/what-are-the-bandwidth-requirements-of-a-mining-rig)). Are there any plans for difficulty 10, 100, N, shares a la p2pool? How does bandwidth compare to p2pool?

Eligius has always used custom implementations; that much isn't new... All PPLNS needs to define N. Making it D×8 is still the same PPLNS logic, just with very low variance.

Well, there are other pools with almost all Eligius's features by now, yes, but I don't think any that have all of them. The closest is p2pool, and that has all the problems p2p entails and a very high variance. With Eligius-Hu, we will also be the first ASIC ready pool.

• Zero fee
• Zero setup
• Low variance
• ASIC ready
• Generated payouts
• Decentralized block creation
• Hopper friendly
• Open development
• ... probably others I forget off the top of my head

Yes, I forgot about the important ones - generated payouts and getmemorypool that streblo pointed out.

I haven't done any bandwidth measurement at all. My plan at this time is to send new work every 2 minutes via BIP22, and dynamically adjust the target based on each miners' hashrate to aim for 1 or 2 shares per minute on average.

Oh wow, sounds great! The bandwidth will be almost negligible even with TH/s! Excellent!

http://eligius.st/~twmz/ (http://eligius.st/~twmz/)

Currently, at the time of my posting this, 7 blocks worth of "paid" payouts which are owed, but haven't yet gone out in coinbase of the generated blocks... Then we have the artefact2 stats for all the pool miners (various "green" amounts, not the "pink" extra credit area)

For anything which is paid / unpaid (anything green-ish color that is below the 0.67 threshold) I'm wondering how will the current payout queue (as listed in twmz) be paid, as well as green "unpaid" area...

... as well as any miners stuck in inactive limbo. If there is already a 7 block backlog, is 8 blocks worth of shares going to be sufficient window to pay the various pool obligations? When the mining switches over, who gets paid what first, and what happens if the pool can't meet obligations within 8 blocks?

Which pay amounts will be "oops, lost forever" (shares which are 8 blocks or more old)?

... maybe I'm just not understanding the transition from current balances owed (non-pink / non-EC) to the new "only shares in the last 8 blocks" will be implemented.

Or maybe an easier question (one I can articulate better) If someone is mining less than 0.67 BTC in any 8 block window, what happens to their shares?

twmz's page includes "estimated" earnings for the next block, so it's not too useful here.

Whatever is "unpaid balance" is yours and guaranteed to be paid out eventually, no later than a month after the pool closes (but probably sooner), regardless of amount.

This is all too confusing :-)

I'm a miner with around 900Mh and I constantly mine on Eligius on same fixed address all the time without any interruption and have been for many months.

Given this, does it matter at all which way I vote here?

Will

Yeah well it's not working. People seem to be against HU (according to the polls)

But nobody's willing to say why; makes me wonder if it's just the trolls who want Eligius dead.

Or people just don't want to gamble on an untested payment strategy?

PPLNS is untested? Really?

Now SMPPS, when we originally switched to it, THAT was untested.

How many pools use PPLNS as you have proposed, using the values you've proposed?

PPLNS isn't DGM. The value doesn't change how it works.

p2pool and 5 other pools according to https://en.bitcoin.it/wiki/Comparison_of_mining_pools



Is there something wrong with tuning the lone parameter of this algorithm?  That's a far cry from a whole new payout system, which is what you were making it sound like (and which it is not).

X-Roll-Nonce.

Works wonders for my cell phone bill.

PPLNS is ok if new blocks are found frequently.
With another miner I had the case that no block was found for a long time, then my network stopped working (weekend). Until the network started functioning again I was passed the N value, the block has been found and I got nothing from it.
That is why I got back to PPS.

I hope this goes ahead as is, but if it's just N = 8 that has people skittish, then it's just a discussion about a preferable N.

At N = 8, it will take (at current hashrate) about 3 days for each share to be paid in full - this is the cost of the minimal variance. Since Eligius miners are used to much longer periods of time to payout it shouldn't seem like a downside at all.


The expected value of any share under PPLNS is the same as that share's value as a result of a PPS reward. The difference is variance, and variance at this pool under N = 8 will be very low. I think (but I'm not sure) that this would make it suitable for intermittent mining.

Congrats on taking this huge leap, Luke-Jr. It's not the easiest thing to do, changing a reward method that has become associated in chief with you and your pool, but your miners will thank you for it.

that problem wouldn't have happened where n=8x difficulty.

Shame on you for saying "trolls" and "wanting eligius dead" in the same breath as you quoted me.

1) I voted a "support" option for the eligius-RA system (effectively, a new system which sounds very much like wizkid's proposal which was sought-after by myself, and several other voters)
2) double shame on you, because I already asked plenty of questions on IRC, and more than one person in this thread has expressed specific concerns.
3) here, have some reasons that I myself don't like Eligius-HU one bit.

For starters, Eligius-HU is largely undocumented, and not explained well in the OP.

What is the size of a share anyway? How many hashes is that?

I ask because the entire bitcoin network is usually between 7k and 8k blocks per month, of which, eligius only finds 100 or so... how does this arbitrary value of "8x difficulty" fit in for our rate if we suddenly mine more or less percentage of the bitcoin network's blocks?

The current "second proposal" doesn't really explain the math which will determine the size of the window over which each miner's recent shares are counted for the purpose of payouts.

Also, my original paranoid questions which I suspect others may have had similar concerns about not getting paid for the previously submitted shares under the Eligius-RA PPS system.

This last concern ties in with my first new question -- Eligius-HU system is going to arbitrarily change the size of a share to be dynamic based on hash-rate, so that nobody's math will be able to know what is going on with the new algorithm.

tl;dr

Basically, Luke-Jr, you did a terrible job explaining things and then wonder why there's a negative response. 

((edit: Can still click "Quote from <<name>>" to view the cited posts / context))


Yes, but only slightly. My CPU mining & GPU (nVidia) rigs are only slightly slower than ASICs. The variance can be disregarded because I deserve to be paid just as much per share. (( this is obviously satire on my part. I really don't understand, and even if Eligius-HU is fully explained, this "dynamic difficulty" will scare me, in addition to the other concerns ))

(( edit 2)) Just noticed, luke, you quoted me out of context:


What I meant was that the votes don't seem to be justifying the change(s) after the fact (was that really the plan?)

When I first read up on PPLNS, I didn't think I would like it. The reasoning being that with my limited mining capacity and the fact that this is my main PC and therefore can't be expected to mine full time, I Imagined the unfortunate scenario where I keep submitting shares that don't make the cut and therefore don't get payed out. I understood that other shares would get payed out multiple times and that my earnings should still average out to full PPS value but I just didn't want to face the prospect of some of my work going unpayed.

At that time, I figured that N would have to be rather large for me to stay on such a pool. I decided I would leave if N was less then difficulty and was really hopping it would be closer to 2 x difficulty. With N = 8 x difficulty, every single share returned to Eligius within the last year would have been payed at least once. As far as I can tell, only Eligius-De was ever unlucky enough to have blocks go longer then 8 x difficulty.

Alright so I guess I can live with PPLNS but what about the current system, how's that working out for me? So I just did some calculations based on the last 10 blocks on stats page for my address and here's what I found.

Over the last 10 blocks I got payed at an average rate of 0.00001716 BTC / Share. At current difficulty, the expected pay rate is 0.00002282 BTC / Share.

So the current system is costing me 25% of my expected earnings because the pool had some bad "luck" over the past couple months. Until we can catch up and start a new buffer, no sensible person should mine here because of what is essentially a 25% fee to pay off people that already quit mining here.  Yes, there is still the very remote possibility that the pool's luck will swing around and pay out all that EC but I'm not going to hold my breath.

With PPLNS, past luck has no impact on future payouts, so there is no bad time to join such a pool since "luck" only affects payouts on the previous couple days worth of shares.

When Eligius-RA shuts down, some people will probably want this configuration:

primary configured mining pool: ra.mining.eligius.st
fallback mining pool: something other than eligius.st (HU)

Please do not hijack ra.mining.eligius.st as a redirect to the new HU system

Simply shut the IP address down or whatever, allowing people to gracefully switch. Doing it this way will allow people to use "active mining" variant of backpay on their existing extra-credit balances before you drop everyone like they've gone out of style.

This policy is one I am recommending because the OP didn't specify what would happen when Eligius-Ra ultimately becomes unavailable.

Regardless of this policy recommendation, I'm just going to use my existing, unmodified configuration which points everything at the mining.eligius.st address, because I have no desire to see the pool "die" or whatever.

With Eligius pool(s) since I've joined, I've had a very good sense of community, and I get along well with many of the active participants, contributors and developers (all the scripts and features that make it nice, irrespective of any BTC backlogs or political issues with the selected payout system)

I didn't  know you voted "dislike Hu", nor did I meant to imply you were a troll (I wouldn't have responded at all if I thought you were).

The OP tries to explain it in language everyone can understand. It sounds like you want some low-level technical details here... but those aren't entirely worked out yet.

Huh?

Where's the question?

imsaguy's post is an example of a troll I ignored. I figured the troll nature of it should have been obvious considering he said the same nonsense about wizkid057's last poll too.

Was not asking for your low-level code, nor for any specific reference implementation in any language whatsoever... The technical details could be in a high level language, pseudocode, or even a list of goals and logical assertions about how various system states and cases will interact, and what the intended result will be.

The implication which you just made: "things are going to be changed" (details that still need worked out) between now and the final implementation is the main reason I am against the Eligius-Hu change. I am of the opinion that a system which is not clearly defined or explained... No. Just no.

((edit retracted))

I personally agree to HU, but Luke-Jr please, we have a serious business here. Maybe you should make some simulation of HU based on current mining capacity, compare with RA's, forecast for future ASIC miners and show us the resulting data. I cannot say that some people are too paranoid or even xenophobic for new setup, maybe some of us don't agree because it's new or don't know the data. Thank you.

So Luke-Jr, you say you want explanations why people vote "dislike HU". I am one of them.

While PPLNS is a well-understood payout system, it has itw own set of flaws, mainly high variance. Even at 8xD. (And counting which shares will have been paid at least once is nonsense, because that's equivalent to merely 12.5% PPS payout.) I dislike variance, and that's why I was at Eligius until things started to go bad (which I predicted months ago, but nobody would listen). I'm very willing to pay a 1-3% cut for true PPS payouts, and also accept modeare payout delays if the pool has bad luck. What I don't accept is share-based variance.

Another problem is that current EC credit will likely go unpaid to a large percentage in the end, which basically screws Eligius' most loyal miners!
(I'm personally mostly unaffected by this though, I've realized what was going to happen early enough.)

Sure, the current situation doesn't look good, and we need a change to fix that. The root cause of all this trouble is that for various reasons (orphan blocks, possibly withholders, ...) a true 100% PPS payout isn't sustainable in the long run by definition, but Eligius' non-equalized SMPPS payout model tries to pay each share 100%, regardless of what is feasible. If it can't, it will start to neglect more recent shares at the benefit of less recent ones, which leads us to where we are today.

So which payout level is sustainable in the long run? 95%? 98%? 99.5%? This depends on a lot of factors, and only time can tell.
What we need is a payout system that takes this fact into account.

I can think of two possible models:

• 95%-CPPSEB
  Assuming we're certain that 95% PPS payout is sustainable in the long run, one option would be a 95% Capped Pay Per Share with Equalized Backpay system.
  This basically means that, if the round was sufficiently short, each share of that round will be paid 95% PPS immediately. If the round was longer, it might be paid less. If the round was shorter, the excess credit is used to increase the PPS percentage of older shares (the ones that were paid the least).
  This increases the chance of immediate 95% payouts for active miners, while ensuring that after some time all shares will have been paid almost equally much, however much is feasible in the long run (this dynamically adjusts itself).
  
  Old EC from the current system could be carried over. If this route is taken, new shares would basically get a 5% fee at first, which is used to pay off old EC up to 95%. Once that point is reached, the payout level of all shares will slowly be increased to whatever is feasible.
  
  See this link (http://eligius.st/wiki/index.php/Capped_PPS) for more details on CPPS-based reward systems.
  
  
• ESMPPS(AM)
  Equalized Shared Maximum Pay Per Share is a system that basically works like Eligius' current reward system, just that it prefers the least-paid shares instead of the oldest ones. It will thus first pay the shares of the current round until they have been paid as much as the least paid previous shares. Then the remaining block reward will be used to increase the payout percentage of the least paid shares (including the shares from the current round).
  This will show similar dips to CPPS* or PPLNS (just that for the latter they wouldn't be brought up to speed later) during long rounds, much better than with SMPPS in EC mode. So even if our luck would be down to 50% for a month, all shares would be paid about 50% PPS, and as soon as luck gets better, those shares will be backpaid by more recent higher-luck blocks. In the end this should end up paying about >98% PPS (whatever is sustainable, dynamically adjusting) to all shares after a while. Recent shares might see slight temporary dips, but not worse than with PPLNS, which doesn't even fill those dips later.
  
  Even though this should not be necessary with an ESMPPS system, one could extend it to prefer old shares of currently active miners to keep people loyal. It would just use 90% of the block reward to pay shares of currently active miners (considering at most equally many old shares of a miner as he has mined in the current round, like it was proposed for Ra), up to a payout level of 100% PPS. The remaining 10% would be distributed across all old shares to eventually pay out all EC if luck permits. If not all of the 90% can be allocated to active miners, the remainder will go towards all shares as well.
  
  Old EC from the current system could be carried over in two ways:
  
  • Consider every old share at its current payout state. This means that the system will try to reach equal payout levels on all shares, independent of when they were found (before/after the switch to the new model).
  • Consider every old user/address at its current payout state. This means that the system will at the beginning prefer users that have been hit particularly badly by the current "EC mode sesion". Old users which have been paid an average of 98% PPS during their whole "eligius career" wouldn't be paid any of their EC until all users which had a worse "career" have been brought up to speed. I consider this approach more fair, and it will get the PPS percentage for newly mined shares into the 90+% area much faster than the alternative above.
  
  See this link (http://eligius.st/wiki/index.php/Shared_Maximum_PPS#Equalized_SMPPS_.28ESMPPS.29) for more details on ESMPPS.
  
  

One additional advantage of these models is than (unless the AM addition is applied, which I don't consider necessary), these models are ready for a situation where transaction fees become predominant compared to the block reward, as it allows for >100% PPS payouts if transaction fees are included in the rewards, and luck + fees allow for >100% PPS.

Sure, if the switch to one of these models would have been performed much earlier, they would recover from the current situation much easier, but I don't think it is too late yet.

I simulated the ESMPPS model like a year ago when I was cooperating with another pool owner on finding a good reward system. The results looked pretty good. Sadly the pool it was invented for didn't really take off and never had more than like a dozen gigahashes, before it was finally shut down. I'm fairly certain that the reward system wasn't to blame though.

I demand that, before a switch to PPLNS is performed, these two models will at least be simulated and analyzed.

Feel free to contact me with any questions about these two proposed systems, preferably in #eligius on irc.freenode.net (http://webchat.freenode.net?channels=eligius).

I simulated all these reward systems a year ago: http://eligius.st/~luke-jr/samples/800MH-3/

The problem with 95%-* systems is that it has no potential to ever be any better than PPS with a 5% 'fee', but still has the risk of the pool hitting long unlucky streaks. Everything else equal, why would anyone pick 95%-CPPSEB over 95%-InstantPPS?

Just guarantee that any outstanding extra credit will be paid, and then implement whatever you want. And tell people when you
have made up your mind what you think is best.

Then people can accept the changes, or go somewhere else.

As long as all the people who have outstanding extra credit gets paid. The problem is if somebody who have been doing work is going to be dealt
the short stick and not get paid in this switch.

Well, that is one sample. But to decide on the feasibility of any reward model, you'll definitely have to take several different situations into account. I usually simulate at least 1000 runs and look at best/worst/average case and their probabilities afterwards.
Psychological questions are also surely a factor, not every miner will decide purely rationally based upon what's expected to result in the best payout in the end. Some prefer higher payouts, some prefer less risk. Some even mine PPS on deepbit.


Because what I proposed in fact has the possibility of being better. If there is any backpay total payout cap at all (only really needed for -AM), that would still be 100%. What I propose is to cap immediate payouts at 95% and use the remainder for (possibly >95% or even >100%) backpay. This is just to prevent shares from "overshooting" above the long-term sustainable payout rate and increase the amount of backpay to finally increase the chance that all shares meet up at the (~98%) final sustainable payout level.

This is very good to note. :)

Whatever new model will be used, the old EC from the current system should be carried over, as TheSeven already pointed out.
Not doing this will punish the loyal miners and will damage the image of Eligius. Because who is to say that the model will not change again in the near future and will the loyal miners again loose their EC?
I for myself will consider this risk when evaluating the various pools next time.

PPLNS doesn't have EC.

Nor does this fear of losing EC make much sense, rationally speaking:

• New miners are losing out pretty bad under the current SMPPS system, and PPLNS will be a welcome change to them.
• Old miners have already made more from SMPPS than other reward systems would have paid for the same luck, at the expense of these newer miners.

It seems the complaint more-or-less boils down to, old miners want new miners to continue subsidizing them in times of bad luck. I do realize this is probably not the intention of the old miners, but I think they (and everyone) need to carefully look at the logic behind this and realize that's how it works out in practice.

Also, please keep in mind that I am in the same boat. I have quite a bit of EC piled up myself, and am not very happy with recent luck trends or the direction we must take to move forward either.

You got a point there. However this is not entirely correct:
- The group that profits most are the old miners who anticipated that this would happen and left like a month ago, after the pool was already deeply buried in EC, but still able to pay most of their EC until today.
- Those old miners who did stay at the pool might not have lost too much if you consider the pool's luck. But they still partially subsidized the former group, which shouldn't have happened.
- The new miners, who joined the pool after the EC period had started, and are mining until today, obviously got badly screwed. These are group that IMO deserves the EC payback most.

Exactly that is the reason why I prefer an ESMPPS model that ports over the old EC, but not considering old shares, but old users instead, so that the users who joined after the beginning of the EC period will be paid back first. While this model might not be appealing to new miners during the first couple of days, I think this model will provide sufficient incentive to stay at the pool for anyone who has EC because things are very likely to get better for them the longer they stay.

That's a good point (about the old miners who left), I'll have to ponder things more.

Disagree. Don't put words in my mouth. PPLNS is NOT a welcome change to me.

As a new miner (having joined during the time of bad luck / much backpay owed) I would like to point out that this change (non-backpay / non-active-miner PPLNS) will not do as much for the current active miners in the pool as compared to an "active miner" variant of PPS.

It sounds like you're more concerned about extra credit rather than the reward method. Under PPLNS, you wouldn't have extra credit owed, so what Luke-Jr writes is correct - new miners would be better off under PPLNS.

Concerns about the extra credit being unpaid should be a completely separate matter to the new reward method. Don't confuse the two issues.

I am exploring other options as well. What do you all think of CPPSRB? With this system, the most recent <difficulty> shares get paid full PPS, but shares are only ever paid once. If your shares fall before <difficulty> in a long block, they get put in the "extra credit LIFO stack (http://en.wikipedia.org/wiki/LIFO_(computing))". So for example, if we have a long block followed by a short one, the long block might pay only the last 90% of the shares submitted, but then the short one will pay all from its round plus however much from the previous round it can. This is the system the BitPenny pool has used for months. CPPSRB can also be reconciled with existing extra credit by just throwing it on the stack initially.

I'd just like to point something out. Regardless of anyone's opinion of "better" (PPS versus PPLNS, vs solo mining VS payout algorithm X) There have been votes... A few weeks ago, I thought that the issue of backpay was a moot point. People seemed to indicate that "active mining" variant is desired (for PPS)

Previously voted and discussed:

https://bitcointalk.org/index.php?topic=97282.0 (https://bitcointalk.org/index.php?topic=97282.0)

• (( previous poll )) CPPSBAM is a form of PPS that everyone already voted for (works fine)
• (( previous poll )) SMPPS w/EC limited to active miners (( another payout that keeps Eligius-Ra running with owed backpay, without changing from PPS, though once again, only pays backpay to "active miners" ))
  
• the current vote: Support Ra AM /// 24 (22.2%)

Support exists for a modified PPS variant...

PPS which has extra credit enabled, and extra credit must first pay the active miners before anyone else's backpay.

Between the two votes, is there evidence of an overwhelming majority whom are STRONGLY OPPOSED to PPS with backpay? (active-miner variant or otherwise)

OK, I'm not going to pretend I fully understand the subtle differences between RSMPPS and CPPSRB.  I do feel that either of these should make for an agreeable compromise between the current (demonstrably broken) SMPPS and any of the AM variants. As someone that plans to keep mining here long term, I would of course prefer to cut off the inactive leaches by going full AM, I would be content to switch to one of these "recent" versions.

Also, I thought one of the major reasons to change reward system to PPLNS was to get rid of the infinitely growing shares database. I don't see any of these PPS variants helping in this respect. Then again if keeping the shares database also means we keep the current stats, then that would be a nice plus, at least until we have a new stats system in place, tested and tweaked to work with whatever reward system is in this pool's future.

Whatever the final decision may be, I hope something can be done before even more miners switch to another pool.

Well, the problem with the share db is that it's HUGE and just gets bigger - it even includes the proof-of-work for every share. The data needed to support CPPSRB is relatively small, and can be sparse-deleted for every block we find (when I upgrade the server kernel to 3.0+).

I would like to start by thanking luke-jr, i have been mining with eligius for a while now, but not long enough to be one of the lucky ones (i'm around 90% work paid), and have felt well taken care of and respected by him.  i have been watching the last 2 polls, but because of forum restrictions i have not been posting. 

i think that people feel that we need to do active only (was always winning the polls) ec payouts soon, because at this point we are just digging a hole (i've been getting a lot of ec recently), and when asic comes out luke-jr would like to be on a new system.  the pools in the last week have even been going up in favor of the new system, and i feel that this could be just to get us away from mining for people who have left eligius.

Yes. Exactly.

Luke: pretty please? Let's switch to some sort "active mining" PPS for now.

Someone have code for this?

I already offered to reverse engineer and implement a new one. Please send it in a standards compliant way this time.

xz is fine, but why was it encoded without any headers?

seriously. what is this? it wasn't recognized by any tool I piped it into.

/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4FpaGs5dABGIQkeKIzPDdw8z/VhnH14++zRWlqT74u2K
6d9qY+BVnYK2iw3W+YZ5vVEVEgJIIt7TEoOOq780Hbx2heEaWLCaNh/E5sEl21ZILx0kb3T5fBMr
Mibd6Ge9gg6QjnCmN39kQx+GmX6BWZEw2Ly274ERFLxqwbWVmhLM2Ja+l5RTgpEEw4bBiuj3Y4vC
QM2CVsY4hQVNK8+kpIHqKS0L0NkYdiCcmZKmpDxYM9bRtyrOEHlF/l/oxhFNNCgJgMXel7oQ5YLP
+8k6E5nO7xHUEVq4+4vKtQRfJCkXjUgEE5irab4s/+ufTmlFzJ1Xfo9V1ADKb/9fMsFivHinLDLZ
OkuHvjgOjNGpqXRD8lo/L2zq6lt8BiNuzxH0oSSwCxTLB6FDpTm7lbK6sfgC7JVpPahq7FvI1uoQ
0HmHZQEEuH3PIl/MQ6yKLIintBWXnHaaCZ3bB66urgvooPKkvgH4G1H3QUCSqvzsYC+6wi+E/Rwl
e5jONkzxcW (snip)

just like, email it or something. my PGP key is well known (feel free to check with the OTC database if you're not sure what my email address is)

Seriously... You can see what that is at the first glance. No idea where you got that base64 encoded blob from, but what you pasted above looks like this if you decode it:

what the... how'd you do that?

‎Monday, ‎July ‎23, ‎2012, ‏‎luke "sent" (posted a link to that encoded crap)

at me and I was unable to decode it.

what tool did you use?