[OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #

[SleeperUnit]

I've been mining on this pool for about 36 hours with 2gh, how long before I should be worried that I didn't set something up correctly and wont be paid out?

Assuming that everything but the stats is still working correctly and that the payout queue is still only a few blocks deep, then at 2GH/s you should get payed roughly every 3 or 4 days of mining. The first payout could take an extra day because you don't have much EC yet.

[klear]

Thanks!

Can't wait for the stats to be up...

[wizkid057]

After quite some time I have new stats up and running in a not-so-pretty fashion, eventually to replace the Artefact2 stats.

They are available here: http://eligius.st/~wizkid057/

Yes, they are not pretty, but, I wanted to get something online before the weekend because I will be out of town and unable to work on them until Wednesday.

However, everything there should be working.  Please email me or send me a message here or some other form of communication if you find a major flaw that cant wait until Wednesday.

I hope to make these into the best stats available for a pool.

I really need to dedicate a full few days to dev to get these perfect, but, I don't have that time to spare right now, so, just slow and steady.

Thanks for checking out the new stats! Bear with me as I work to make these stats much more presentable and awesome.

-wizkid057

P.S. - I'm not above asking for some donations towards development if you can spare it: 17RGKaQHSC882xpB84MEA7i52zbwh9AFkR --- Thanks

[gigica viteazu`]

thank you wizkid057

[muyuu]

Cheers Wizkid, BTC1.337 going your way.

[Luke-Jr]

An update on the backend side... We are now the second pool to implement BIP 34 (block height in coinbase). Compatibility for BIP 22 (getblocktemplate, for decentralized mining) has also been brought up to the current draft, including support for BIP 23's "Basic Pool Extensions".

For the time being, Eligius will remain backward compatible with our old BIP 22 draft implementation (getmemorypool) as well.

Eloipool's gmp-proxy is not updated, and I do not plan to update it. Instead, I plan to enable Eloipool itself to run as a fully functional BIP 22/23 client and provide the same basic behaviour gmp-proxy did before, plus be able to use all its usual pool functions. This basically means you can run sub-pools under any other BIP 22/23-compliant pool (including nested sub-sub-pools).

Additionally, after I finish with the pool updates, I plan to implement a MIT-licensed library for BIP 22 and 23, which I will then use to enable BFGMiner to achieve a whole new level of efficiency, necessary and in time for the anticipated ASICs within the next month.

As for reward systems, we are still running on SMPPS. CPPSRB seems to have fairly good reception, so that seems like what we'll be migrating to in the coming week(s).

[aspirez]

Can someone explain what exactly is Extra Credit?

[SleeperUnit]

Can someone explain what exactly is Extra Credit?

from: http://eligius.st/wiki/index.php/Shared_Maximum_PPS

"Miners accumulate Pay-Per-Share as usual. When a block is found, the pool counts the total unpaid PPS credits. If there are sufficient pool funds earned to pay them all in full PPS, that happens. If not, the miners are paid proportional to available funds. Remaining pool funds accumulate toward future payouts. The difference between a miner's actual (SMPPS) earnings and PPS earnings is retained as "extra credit", and considered in future blocks."

[wizkid057]

Just a quick update on the new stats at http://eligius.st/~wizkid057/newstats/

Still finishing up the backend scripts so that the stats are updated correctly and smoothly without bogging down the web server.  Should be done most of that tomorrow.

After I'm happy the backend is functioning properly I'll start working on the appearance aspect.

Enjoy!

-wk

[organofcorti]

Just a quick update on the new stats at http://eligius.st/~wizkid057/newstats/

Still finishing up the backend scripts so that the stats are updated correctly and smoothly without bogging down the web server.  Should be done most of that tomorrow.

After I'm happy the backend is functioning properly I'll start working on the appearance aspect.

Enjoy!

-wk

Good work - the table at http://eligius.st/~wizkid057/newstats/blocks.php is simple, and easier on the eye than the old table. It's also good to have the round start date/time there. I have a couple of little quibbles though: Round duration is not easily machine readable, and you're not including stats for orphaned blocks.

Since you're setting this up right now, can I make a couple of suggestions:
1. Would it be possible to provide a csv table of round data? It would make providing stats for the weekly pool stats and the Mining Pools threads much easier than the current HTML scraping method.
2. From a stats point of view there's no reason not to include shares for orphaned blocks and reasons to include them. Unless it's just not possible?

[Luke-Jr]

...and you're not including stats for orphaned blocks.
...
2. From a stats point of view there's no reason not to include shares for orphaned blocks and reasons to include them. Unless it's just not possible?

Orphaned blocks simply don't exist, so they don't really have stats... Shares go toward whatever the next block is found, regardless of any orphans in the meantime.

[organofcorti]

Orphaned blocks simply don't exist, so they don't really have stats... Shares go toward whatever the next block is found, regardless of any orphans in the meantime.

I understand. For an invalid block I'd see the point of doing it that way. But for a valid but orphaned block I wonder how that might skew your (shares/round) stats though? The block was solved, just not accepted by the network.

I would expect this to have the effect of artefactually increasing the mean round length in your results and making pool luck appear worse (if you use mean shares/round/D). Also, it would make your average weekly hashrate looked higher than it actually is (calculated using total shares/total round duration) - unless duration is also added to the next block? I acknowledge these effects would be minor since the average % of orphans is so small.

Anyway, any chance of a csv of round history?

[wizkid057]

Orphaned blocks simply don't exist, so they don't really have stats... Shares go toward whatever the next block is found, regardless of any orphans in the meantime.

I understand. For an invalid block I'd see the point of doing it that way. But for a valid but orphaned block I wonder how that might skew your (shares/round) stats though? The block was solved, just not accepted by the network.

I would expect this to have the effect of artefactually increasing the mean round length in your results and making pool luck appear worse (if you use mean shares/round/D). Also, it would make your average weekly hashrate looked higher than it actually is (calculated using total shares/total round duration) - unless duration is also added to the next block? I acknowledge these effects would be minor since the average % of orphans is so small.

Anyway, any chance of a csv of round history?

Orphans (now known as Stale) just dont count for anything.  Its basically as if they never happened, so, as far as stats go, its almost pointless to keep track of them.  The shares contributed towards them just continue the round.  Duration is also continued.  See the block # 197915 in the new stats as an example.

CSV round history?  I'll throw that on the TODO list.

So, got the backend pretty stable and we were able to clear up the existing shares database to make things more practical now.

Tomorrow I will work on aesthetic updates and get the new stats up to par with what artefact2 was providing.

Thanks again for the support!

-wk

[organofcorti]

CSV round history?  I'll throw that on the TODO list.

Cheers!

[wizkid057]

Thanks to all who have donated to stats development so far!
I've actually made a new donation address for them that is more appropriate: 1StatsgBq3C8PbF1SJw487MEUHhZahyvR

In stats news, cleaning up the back end is taking a lot more time than I have original thought, but, its coming along.

I went ahead and started a git repository for the stats.  You can check out my progress and such here: https://github.com/wizkid057/wizstats

If you notice any blatant errors in the code or other bugs, or have a feature request, go ahead and open up an issue and i'll do my best to get to it!

Overall, the stats are coming together.  

Latest changes:
I've fixed the 3hr/12hr hashrate averages on the graphs to be shifted to the correct position (harder than you think).
Added 3rh/12hr averages to the main pool hashrate graph
Added current values of pool hashrate and round shares to the main page.
Few bug fixes, including user stats reporting incorrect hash rates
Added header/footer to each page with a link back to the main page

Thanks again for the support!

-wk

[stevegee58]

Does the Tor hidden service for the mining portal still work at xg3mjrqqxal4i5g7.onion:8337?

[stevegee58]

Wow it looks like this is the longest block ever for eligius at 80+ hours.

[muyuu]

Stats are down.

[DrGuns4Hands]

Can someone please explain the difference between CPPSRB and RSMPPS to me?

[Luke-Jr]

Can someone please explain the difference between CPPSRB and RSMPPS to me?

RSMPPS still uses the notion of mining "rounds", and divides the earnings of a long round proportionally among all shares in that round (assuming no buffer to cover the difference). CPPSRB is more like PPLNS: the last N unpaid shares are paid. It has no notion of specific rounds; if it takes more shares than average before a block is found, the earlier shares just don't get paid by that block (and remain on the "unpaid shares" stack for potential future short blocks).