All that is really needed to keep people using the pool is a simple restful web query that returns the number of shares credited to a BTC address as a JSON dict.  That way people would know their work was being counted.

From there, including the total shares owed would I think allow people to compute BTC owed (the number of blocks mined and total BTC paid from eligius can be pulled from the blockchain).  Any other stats that are handy can be included in the JSON dict.  People could contribute scripts that pull the JSON stats and compute and output fancier stats.  Polling on a regular basis allows time graphs - and so on.

cgminer has an API, and there is a miner.php script included that makes nice looking colorful tables from the data.  Enable the API in your config (on localhost if concerned about security).  Run httpd and serve miner.php (with edits for the API address and port).

No, I meant to suggest a ditching the UI as a stop gap version of user stats for eligius..st.  But maybe the hard part is getting the raw data, not the UI.  But I often find the raw data easier to do that a polished UI.  But yeah, you're right.  Wizkid is the guy doing eligius.st.

Thanks for the update.  I can relate.  Sometimes rewriting is vanity work, and sometimes the original authors were unclear on the concept.  Having a test framework is 80% of the battle - so you are in good shape.

Ok, with cgminer-4.9.2, my AU3 (https://www.amazon.com/gp/product/B016CWBYJK/) gets 12.5Gh/s over several days.  With cgminer-4.10.0, it gets 8.5Gh/s over several days.  The older USB miners all get the same on both versions.  Both versions have all generic USB drivers enabled.  I get the same results on both my 256M arm controller and an x86_64 desktop running Fedora 25.  I'm also getting a lot more accepted hashes with 4.9.2 - several times more, which the modest increase in total hashing power doesn't explain.  [^1]

Conclusion: There may be a (subtle and hard to debug) problem with 4.10.0.  :-(

I will try to submit this to Fedora as an official package.  Fedora will ship using the system jansson lib.  4.9.2 autoconfig is unable to find the system jansson lib, but 4.10.0 does find it.  

Another question:

When systemd kills cgminer (either version) on the ARM system, cgminer spits out a summary as it shuts down which goes into the system journal.  Nice.  When systemd kills cgminer on the x86_64 desktop, cgminer just dies.  No summary.  No "shutting down" message.  Why?

[1]: over a 3 hour period, my tiny rig got 9 accepted shares, with a square root of 3.  So the changes in accepted work units are within reasonable variance for such a small rig.

The source for 4.10.0 helpfully provides api-example.php which shows raw summary data, and then php data structure parsed from the raw summary data.  All good, and works.

So, not being a php person I attempted to boil down what api-example.php does, and akaict it does this:

$ echo -n summary | nc 127.0.0.1 4028

Silly me, not only does that not work, but it crashes cgminer, and my 256M arm system running cgminer.  (Some sort of resource exhaustion - system is still pingable, but unable to accept new logins.)  Apparently, the slow readline loop to read result bytes one at a time is critical to avoid crashing cgminer.  Is this a known problem?

All I want to do is monitor the total hash rate with nagios.  I guess I can run php at each check...

I tried this on a x86_64 desktop (Fedora 25) running cgminer-4.10.0, and it works. On the arm controller, both versions crash with "echo -n summary | nc 127.0.0.1 4028".  So I guess it might be a timing thing, and that slow read loop is critical on tiny computers.  Maybe I can simulate it with python.

I tried with and without the embedded jansson-2.9 lib on X86_64 - it works on both.   The arm box system jansson is 2.6, so I used the embedded version.
----
Update: twice now, reading status via API from miner.php has crashed the arm controller.  So it is a timing thing, and it just happens much less often with the php client.  The next step will be to put some resource limits on cgminer via its systemd service.  If I can keep a login running when cgminer crashes, then we can do some debugging.

I don't expect to make a profit on cloudmining.  But I would like to use it as a slow way to convert fiat money to BTC.  As long as the conversion rate is competitive with BTM machines, I am happy.  Unfortunately, most cloudmining requires you to pay in BTC - and that is just silly.  It's like giving them a negative interest loan (as you correctly point out).

The other thing I want is to choose the mining pool my rented mining hardware is contributing to.  Then I can monitor the contribution of my rented rig (and whether and how long it is down).

Naturally there needs to be some sort of waiting period with escrow when paying by CC - until the transaction is final.

Both of those require that you already have BTC.  If I already had BTC, I wouldn't be looking to rent miners.  If you are trying to make a profit mining, you just have to suck it up and make a room for noisy fans.  (And a source of cheap electricity.)

It wasn't clear where this belongs, this is my best guess.

I want to rent mining hardware hosting.  No, I don't expect to "make a profit".  What I do expect:

o To pay via credit card.  Having mined BTC escrowed until the CC transaction is permanent is understandable.
o To choose which mining pool to use.
o An effective USD -> BTC rate competitive to BTM machines (which of course includes a healthy profit for the operator).
o Visibility of escrowed payouts during the escrow phase.
o After the escrow period, my chosen mining pool provides visibility of hashrate and makes payouts directly to my wallet.

I have mining hardware in my home, but at current difficulties, it is too noisy (fans).  I have used BTM machines, but they are becoming too invasive (not the operators fault - government requirements).  In person cash transactions have minimums that are too high.

I tried a small amount on genesis-mining, but the total lack of feedback makes me suspect it is a scam.  Plus, they don't let me choose the mining pool.  I have a (possibly irrational) loyalty to Eligius.

Paying for BTC mining rentals with BTC is counter productive - as it effectively donates BTC to the operator.  Mining rentals only make sense economic sense when paying with a currency different from the one being mined.  The operator might as well just keep all the BTC mined and skip the rental.  You are effectively making a negative interest loan to the operator!

The sender did not mention any identifying details, and in fact, there were a lot of random emails in the To: header (which is actually consistent with the premise).  I included the entire body of the email, less html formatting and a non-aol email address at the bottom, which was not authenticated in any way - and I didn't want to taint the reputation of the innocent.  (Surely the scammer wouldn't use his *own* real email?)

It just occured to me - maybe he generated a new bitcoin address for each recipient?  Would that be feasible?  It probably would be if he had an actual list - and would allow him to know who paid him off.

As a developer, my email is "out there" and is not changing.  At one point, I was getting 10000 spams/day (nearly all blocked by filtering).  *Known* spam is actually quite valuable (it can be used to automatically train software).  This is the first Bitcoin scam I've seen (and it was not recognized as spam by my software).  I was curious what the scammer is exposing by offering a Bitcoin payment address. 

This scam is particularly implausible because the scammer has no (easy) way of knowing who sent him the BTC.  

Yeah, that is usually good advice, but I like to tinker with email filtering software.   

The claims are not plausible, but this is the threat I received.  This is in the US.  Besides reporting to the FBI email fraud mailbox (FWIW), what should be done with this kind of thing?  I looked on blockchain.info, and no one seems to have sent any bitcoin (just 3 small transactions - apparently to test his/her wallet).   Assuming the scammer initiated the 3 transactions, do they provide any clues?

api.polmine.pl (and polmine.pl) are refusing connections on 8361, 8347, 8547 since 2015-Oct-20 15:34 EST

I was able to transfer BTC balance (NMC balance was too low).  But unless I missed some big API change not in their FAQ, they seem to be kaput.

When I try to use the api, the pogoplug running cgminer crashes.  I'm wondering if it has to do with running off a USB stick and cgminer using libusb.  I've been using since 3.8.  No console on pogoplug (without soldering a special USB cable - which I tried and failed).  cgminer does not run as root, so it really shouldn't be able to crash the system - unless it is one of those infinite thread/fork bugs.

Solo mining is like buying a lottery ticket.  Getting a block accepted is very rare - but if/when you do, WHOO HOO!  25BTC + fees !!

So yes, you would (almost) never have a block accepted.

Everyone should have solo mining configured as a backup, and test it occasionally.  This makes the bitcoin network resilient against the loss of one or more pools. 

Now, you are ahead of me.  I still haven't got solo mining configured.  I have some questions too.

Why does solo mining need a bitcoind?  What does it use the api for?
Does the bitcoind have to use the same wallet as the BTC address configured for solo mining?
Can bitcoin-qt also provide the API?
What if bitcoind is down?  Does cgminer disable solo mining?  (Just as for a pool that is down)
If cgminer is talking to bitcoind, can we assume it is working?  It would be a shame to find a block, and then lose it because cgminer wasn't actually configured correctly. 
Does finding a block modify the wallet in any way?  Or is bitcoind only used to talk to the bitcoin network?  Could I run a bitcoind with an arbitrary empty wallet?

Once my Antminer U3 has been running for a bit, it gets this about every 10 seconds:

 

 [2015-09-03 18:09:24] AU3 1: No valid hashes for over 2 secs, attempting to reset
 [2015-09-03 18:09:24] AU3 1 attempted reset got err:(0) LIBUSB_SUCCESS
 [2015-09-03 18:09:24] AU3 1: No valid hashes for over 2 secs, attempting to reset                    
 [2015-09-03 18:09:24] AU3 1 attempted reset got err:(0) LIBUSB_SUCCESS 

Despite this, the hashrate manages to stay around 60 - (about 5Gh/s worth of old erupters and antminers), dipping briefly after each reset.  Is it possible that the AU3 is simply getting hot and taking a break?  Is there something I should tune to make it work a little less hard (and reduce the log file entries)?  I am using all defaults.  I see people are tuning voltage and freq. 

I changed the urls to use stratum+tcp instead of http.  That is apparently a config format change.  Now getting 60Gh/s with no further config changes (includes 5Gh/s from older miners).

Thanks for the tip!

{
"pools" : [
   {
      "url" : "http://stratum.mining.eligius.st:3334",
      "user" : "1Dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
      "pass" : "none"
   },
   {
      "url" : "http://api.polmine.pl:8361",
      "user" : "CustomDesigned11427pogoplug",
      "pass" : "XXXXXXXXXX"
   }
],
"text-only" : true,
"no-submit-stale" : true,
"api-listen" : true,
"api-port" : "4028",
"api-allow" : "W:192.168.10.0/24,W:127.0.0.1"
}