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

Solo mining with it works fine. I'm doing so myself right now.  Please don't conflate issues in BFGminer's GBT support with "solo mining"

Currently it is not practical to solo mine with CSV; I would consider it unfortunate if it were to activate in this condition.
I have been working on addressing that problem first, and wizkid057 is mostly waiting for me at this time.

My todo list on this matter is:

☒ Add GBT upgrades to BIP 9
☒ Implement BIP 9 GBT upgrades in Bitcoin Core
☒ Backport BIP 9 GBT upgrades to Bitcoin Core 0.12
☐ Release Bitcoin Knots 0.12.1 with BIP 9 GBT upgrades (or alternatively Core 0.12.2 could be released with it, but this seems unlikely)
☒ Implement BIP 9 GBT upgrades in libblkmaker/BFGMiner
☐ Release BFGMiner 5.4.3 with BIP 9 GBT upgrades
(at this point, solo mining with CSV becomes practical)
☐ Port Eloipool to BIP 9
☐ Backport new CPFP code to Knots 0.12.1, or forwardport Knots features to Core master

wizkid057's steps for upgrading then are:

☐ Test Knots 0.12.1+CPFP or Core master+Knots
☐ Test Eloipool with BIP 9
☐ Deploy upgraded bitcoind + Eloipool

Edit: List being updated at http://eligius.st/bip9status.html

Unlike some miners/pools, I don't just throw "updates" into the pool's production environment without a good deal of testing, especially not changes to bitcoind.  I'm pretty sure Eligius possibly delaying deployment of anything at this point is quite a bit of an exaggeration, also, considering we're less than half of 1% of the network hash rate currently.  Regardless, the obvious anti-Eligius trolling is obvious, and I probably should just clean up the thread vs wasting time responding.  Best to set the record straight though, I suppose.

Currently, I'm focusing on the previously announced updates to the pool itself and the pile of changes coming along with that, while simultaneously testing that code, updated bitcoind implementations, a new web front end, and more.  With any luck I'll have the pool updates done and online before any soft fork matters anyway.  Worst case I'll just flip the existing pool core over to the updated bitcoind if I fall behind on the main core change over to the updated system.  Either way, it's not a big deal IMO, and I'm not rushing changes to the back end.  As much as I hope to grow the pool and get Eligius's position back to a higher percentage of the network hash rate with the work I'm putting in on these upcoming updates, I'm not delusional in thinking that right now Eligius has any real impact on the activation or non-activation of any forks.  So, I'm prioritizing my time accordingly.

I put part of the new real-time stats API online last night utilizing the existing pool core to start some public testing.  It's been written pretty much completely from scratch.  The public testing has helped me find and fix a few issues I was having with it when people started doing some poking around, so, thanks! More on that soon.

I'm definitely stretching my time pretty thin as of late, and I'm honestly not where I wanted to be on progress for the updates at this point.  I was hoping to be in a public beta phase by now, but I'm just not there yet.    At the same time, when it comes to crucial code, I'd much rather be safe and late than potentially screw something up that costs people, myself included, money.  

I have a lot of time slotted for this over the short term, so I'm hopeful that I'll make some serious progress!

Came here to say this. Update already.

Why is Eligius not supporting CSV? You could delay deployment for another 2 weeks. Always last to update.

Greetings Miners,

So, I've finally got a little something to show off with this epic project.

I've put up a small part of the new API in a sort of open beta.  I figure if anyone is so inclined they can poke around a little.

It currently just errors on anything even remotely invalid, so, check syntax.

Some examples:

Near real time worker stats (just using 17XcnEcWAZcma17NfYByygLXoj2P5kXxpa as an example):
http://api.eligius.st/wkapi/worker_stats?u=17XcnEcWAZcma17NfYByygLXoj2P5kXxpa
http://api.eligius.st/wkapi/worker_stats?u=17XcnEcWAZcma17NfYByygLXoj2P5kXxpa&format=text
http://api.eligius.st/wkapi/worker_stats?u=17XcnEcWAZcma17NfYByygLXoj2P5kXxpa&format=json
http://api.eligius.st/wkapi/worker_stats?u=17XcnEcWAZcma17NfYByygLXoj2P5kXxpa&format=text&show_offline=1


Pool wide instant stats:
http://api.eligius.st/wkapi/pool_hash_rate
http://api.eligius.st/wkapi/pool_hash_rate?format=text
http://api.eligius.st/wkapi/pool_hash_rate?format=jsonp&callback=eligiushashrate


Responses are generated in real time, but the underlying data is updated about every 1 to 3 seconds.  So, something like a 5 second polling interval would probably be the fastest useful speed.

I've designed this interface from scratch, and it's lightning fast.

Since this is a bit of a beta test, obviously some things are subject to change, probably has some bugs, and may go down while I work on things.  

I'll be adding a lot more to this API, and eventually it will have basically all possible data available and the new stats will simply provide a front end for that data.

No, it's not in PHP, although I did write a function that outputs data similar to PHP's print_r when using "format=text" like with the existing api since it seems some people actually make use of that for one reason or another.

I have a lot more going on behind the scenes that I'm going to be rolling out soon, too, so stay tuned!


Updates:

12:09AM: New API down for a few while I fix a few things
12:21AM: Fixed a couple of bugs and a memory leak.  Should be good for now.
1:07AM: Still working out a few issues.  Thanks to those who are helping me locate them!
1:32AM: Seem to have fixed everything obvious.  Will check on things more as issues arise. Thanks!

Currently testing an S9 on Eligius if anyone is interested... Will let it go for about a half hour to get some data.

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


UPDATE:
30-Minute Test Results:

Thank you wizkid057 for your reply.

These are really exciting news. Looking forwards for the coming updates

I'll explain again.

You have not been mining on a 100% straight PPS pool (since these don't really exist).

You have been mining under CPPSRB, which does NOT guarantee 100% shares rewarded, just like every other mining reward system in use today.

100% of your balance has been paid.

The specifics of of remuneration pay less Miner?

Calculator 3 months totals 1.6 BTC
my power 7.8 T/H
I was on the pool almost 3 months, and the pool  not paid in full

What is the specificity?

I've posted various updates since.

The only real obstacle has been time management.  Definitely taking longer than anticipated to get everything implemented in the time I've had available.  I have other obligations that demand my time, and as always unexpected things in life demanding additional time.  I put as much time as possible into dev for Eligius, but I can't justify any neglect of other obligations to do so.

That said, I'm finishing up a project this week (unrelated) that should open up my available time again so I can get things into the beta stage soon.  I'm trying to kind of run a lot of the new code in shadow mode behind the scenes using the current real mining data (no actual effect on mining at the moment) to make sure everything behaves as it should.  I'm also doing some higher rate testing on a custom testnet.  Admittedly, it's all of the testing that's probably taking up over half of the time spent.   Since I'm maintaining one of the things that makes Eligius unique, the coinbase payouts that include real time balance updates, I'm very careful to thoroughly test everything so that everything is properly accounted for in all possible scenarios.

The new near-real-time stats are also a parallel part of the project that are coming along great.  I'll most likely expose some of the new API for a public beta soon.  The up to the second worker data should prove useful I'm also working out some final kinks in the historical data API, which will have hash rate and balance stats for all Eligius miners from present back to approximately January 2012 with very good graphing resolution available for all workers.  I've designed the new real-time portions of the API from the ground up to be lightning fast.  I've tested it with entire clusters hammering it with tens of thousands of requests per second with no appreciable slow down.  It's been designed to be modular and the back end can expand resources as needed to manage loads.  This should allow me to keep the API 100% public as it has been, vs switching to some API key system.

I'm still excited about all of this.  Can't wait to show you guys what I've been cooking!

Edit: Deleted a post from a rude user (1Ko9M5GDH8UzXgg5SopA42FL5QqV3AsxP1) who doesn't seem to want to read nor understand mining and miner reward systems.  Specifically doesn't understand the concept of shares rewarded.

Hi wizkid057,

Sorry for asking, I'm not following this topic as I should be, so, I'm not sure if you had mentioned anything about the new system. I wanna know if there is any updates, obstacles, or expected date for implementation?

Hey. Great Pool but is there any nmc being payed out?
I get btc ok but have yet to recieve any nmc.

Well it's a hobby project, just for fun and gathering experience, not for a commersial product.
I want to use ESP8266 (and ESP32 later) for a standalone solar panel miner with some leftover 55nm Bitfury chips. It won't pay even for the MCU or the external SRAM required and will probably take months to complete it (if ever)

Basically a low memory embedded miner is probably the worst possible thing to make as a miner at this point.  It's cool to have them be independent of a PC I suppose, but hard coding mining protocols and the like is just a terrible idea.  These things are not going to stay the same forever, and the companies and designers that take such shortcuts will have incapable hardware at the end of the day.

Eligius's generation/coinbase based payouts are definitely here to stay, and I'm sure eventually other legitimate pools will adopt this practice in the future as well since it prevents the pool from ever having any significant amount of miner funds on hand in the event of some type of compromise, for one, and also prevents any real theft/loss from being possible in the event of a shady pool operator doing the wrong thing.  In my (probably slightly biased) opinion, pools that won't even consider it probably shouldn't be trusted with your hashes... but that's just me.

The generation transaction can possibly be as large as 1 MB, which would requires hashing the full 1 MB per 4 Gh.
Actually meeting this requirement turns out to be pretty difficult with modern hashing hardware, even with a dedicated high end PC, so I guess just "do your best" - it is possible (but not implemented yet) to use a midstate to optimise this if the extranonce is at the end of the generation transaction.
A good test would be to run BFGMiner with --benchmark-intense mode.
You should probably read https://en.bitcoin.it/wiki/Mining_manufacturer_tech_guidelines

Can you share the exact size, please. I am working on a low memory embedded miner and don't want to have it classified as poorly coded/developed . It's easier and better to plan for more memory, than extending it latter

There's one minor exception to this:  When the coinbase transaction is full (beyond the size that some mining hardware can handle without a performance penalty... mainly poorly coded or low memory embedded miners) a few smaller payouts near the bottom of the top block of the queue can be shifted out to the next block out of order in favor of some slightly newer but larger amounts due to other miners in order to better get the majority of the coinbase payout to miners vs Eligius's offline wallets.  This out of order replacement is limited to 5% of the addresses paid in the block, so for the most part queue position isn't adversely affected.  But it's a necessary exception to allow to make sure that the coinbase's block subsidy is best utilized and sent to miners vs being set aside for manual payouts.

Anyway, I'm still working on the new code for the pool and I've made some pretty good progress.  I've had to play catch up on some other responsibilities, but I'm still dedicating a good chunk of my schedule towards getting things done here.

My goal is to potentially recruit some tight lipped beta testers in about a week to help me test out some things in the sandbox (most likely via our IRC channel and some other private invites).  Assuming all goes well with the sandbox betas and live betas I'm shooting for a full pool transformation soon after.

Have I mentioned I'm very excited about all of this?

Some hints at upcoming features (disclaimer: may not all be available immediately):

• Ability to mine with all valid address types, not just version 0 addresses (1xxxx)
• Ability to change your payout address securely (!)
• Enhanced stats with worker and account data histories from present back to the beginning of time
• Live worker stats (give or take 10-15 seconds)
• Enhanced stats API
• Much more

That's just the tip of the proverbial iceberg.  

Probably 1/4 of the posts in this thread are about the payout queue. 

There are two rules:  payouts have to be above a certain threshold, and the oldest eligible payouts are at the head of the line.  The payouts always follow those rules, no software is broken, no shenanigans are perpetrated.  These rules seem to be good rules.

When a slow machine that has not been paid out in a long time finally passes the threshold, it goes to the head of the payout and everyone else gets bumped lower by one. 

after 4 blocks i received my payout!
but the estimated position sometimes is totally wrong!