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

That's the % of shares that has been rewarded, with CPPSRB only 25BTC+fee worth of shares are rewarded every block, so on bad luck blocks some shares are not rewarded but on good luck rounds the most recent unrewarded shares are rewarded until 25BTC+fee is rewarded.

You can see a more in depth explanation on the link "Shares Rewarded" in the stats which links to:
http://eligius.st/wiki/index.php/Capped_PPS_with_Recent_Backpay

Looking to understand the "Shares Rewarded" %. Mine is at around 92% does that mean that only 92% of the shares submitted will get rewarded? Sounds like I would have low efficiency.

Thanks.

I would agree whole heartedly that it may have been unintentional IF Brucexie would agree to return the 430 or so BTC he and his group pocketed from this misadventure ( just on Eligius not to mention whatever other pools they have performed this attack on) and allow the whole sum to be distributed to those miners  who actually did the work and solved the blocks. If he and his group would do that I guess that would prove to me he / they had no intentions to steal my bitcoins or try to do harm to Eligius and the other pools they attacked.

Since I do not see such an offer and I do in fact see Wizkid planning to distribute the 225 BTC he froze. I guess we can see who it is that is dishonest here. Wizkid could have kept this all quiet and pocketed the frozen funds but he refused even when someone suggested he do so. Once again Wizkid showing his TRUE colors. I think what this is showing me is that my donation levels are set way to freaking LOW and I probably should go increase them immediately but its bed time and I am getting too tired to see the screen so I will have to worry about that another time.

Thanks Wizkid, Lukejr and all others who are instrumental in keeping Eligius the BEST if albeit not the biggest mining pool BAR NONE.

Sprayed a little WD40 on the web server, mixed some more oil and gas, gave her a few pulls... presto!

Should be back to normal in no time.

Migration to the new server is still in progress, also.

We have found block during that time -- just not updated yet.

When WK comes online he will sort out the stats page, but for now, be content that we are still finding blocks  in the background

Interesting.

Also hows that for luck. Elegius gets into a spat with some block withholders and now were on a 11.5 hour round...

https://blockchain.info/block-index/438659/000000000000000030f094dd2990a9e9edc4bf5176882091eeb9ae79e093fa93

Yes... this has been discussed a month or two ago, I think here in this thread.  In any case, it is known that some hardware only checks certain nonces due to the design of the chip.... e.g. maybe it only checks even numbers and skips odds, or only factors of 4, etc.  This is built into the design of the hardware.  It still checks X number of hashes per second, but it just skips certain nonces.

And then you have the efficiency issue.  All miners in a pool should be notified ASAP when a new block is found, and new work pushed to all of them.  Otherwise, the workers pull work from the pool on an as-needed basis.  If the pool found a block (i.e., a known good nonce) then it would have to have some way to push a normal-looking work payload to all miners in order to test them.  This just isn't going to happen, it will be easily detectible (just set up 3 addresses to mine to, if all of them get the same work at once then it's an obvious test) and also loses efficiency.  It is making miners work on an old block which has already been found, when they should be working on a new block.  It just doesn't make sense to do this.  Perhaps on a targeted basis, but certainly not for the whole pool, or even for all of the larger miners.

All in all, statistical analysis is the best way to discover block withholders.

Block 306010 by Eligius, but not on blocklist. Hmm

https://blockchain.info/en/block-height/306065

Timestamp    2014-06-16 05:24:12

I think one of the problems is;  there's no guarantee about which order the miner tries the nonce values in, and it might fail or decide not to try some subset of nonces of the winning one is one of... without being a "cheating" or withholding miner.

The other thing is sending miners some fake work units:  results in hashing power being wasted,  so great care must be taken for the "fix"  to  not have greater  expected total losses on average,  than the block withholding attacks that are likely.

I know the pool is working, but just wanted to let everyone know the stats seem to be stuck.  We've mined 2 blocks (306,049 & 306,065) since 306,013.  Payouts seem to be working as normal since I was included in the last payout, just doesn't seem to be updating that we've moved on to new blocks on the website.

How, by sending a winning nonce to all the largest miners in their pool to see if one doesn't return it?

At some point you could consider making it economically viable for miners to "spot check"  work units conducted by other miners,   and  if  another miner finds enough blocks the other mining operator apparently missed in the past,  then miner deemed to have originally witheld that solution.

Perhaps pools publishing detailed statistical datasets for every miner operating on their pool; including the listing of complete work units  they claimed to have exhausted.   And every time the pool solves a block, set aside 0.02BTC of the generation  (or some other fraction) towards a heavily secured "security/bounty fund".

Partially as a reward for reporting or correcting nefarious activity, in order to "crowdsource" audit work,  and partially as an 'insurance fund'.

Use a 90 or 180 day delayed payout mechanism to give some funds as reward to miners solving a block,  in order  to discourage small miners from witholding, since they will actually immediately lose $$$ in doing so.     And to distribute  the rest of the bounty fund (excluding a reserve of at least 100BTC)  as  payouts similar in concept to  "claimed insurance" to  reduce miners'  losses due to block witholding.

If any software developer designs an effective scheme of lower cost to operate that provides reliable automatic detection which is not easily defeated or provides permanent immunity against block witholding,  then the developer would be awarded 10 or 20 BTC,  from every pool to have such a fund,  and the size of the  security bounty / block "insurance"  premium  could then be reduced.

On the other hand...  if anyone who reviews a pool's public datasets and is convinced that a certain miner is conducting block witholding,  they can pay a   3 BTC fee  and specify  which  2016 block difficulty adjustment period,  or  6 BTC and specify their two sequential 2016 block periods, etc, in order to lay their  accusation.

In case the pool operator finds the proof of the accusation to meet the statistical requirements,  then the first to have reported the miner block witholding for each 2016 block period is paid from the bounty fund  the lesser of 20BTC from the bounty fund per 2016 period and half the pool's loss from that miner (Not to exceed  40BTC total to all accusers for accusations related to a specific accused miner or during a specific 30 days).

In either case, the pool operator keeps the 3BTC fee taken from the first accuser to lay the accusation,  in order to help compensate for investigation,  but may: at their discretion, refund some portion, if it was shown to be wrong but non-frivolous.

Clue would be to run tests only against miners which fell outside the standard deviation from regular miners. This would limit excess processing and wasted work, as only those under suspicion would end up being tested.

If this were done, you'd have to limit it to only miners of a certain size seeing as miner with my hashing power, a mere 85 gh/s, would probably have difficulty solving a current block in a reasonable amount of time to prove my software/hardware was working correctly.  Yes, I understand I might get lucky and solve block, but that would definitely be a something that could reasonably be predicted as to when.  Right now I'm showing a best share as 12.8M.  The other thing this would beg to question, is wouldn't this hash power be put to better work hashing on good work.  Seems like looking for statistical anomalies and watching them more closely, or auditing their work would be a better way to handle this.

I was thinking send it the same work description which another miner already solved and reported a block on.

Basically have the pool send work that only needed difficulty 1 to solve?  I guess that could work, but I'm not well versed on the inner workings of nonces and all the stuff... need one of those brainiacs to post on that

and randomize the WU.

I am not totally sure how mining works now, but couldn't a pool spot check miners by giving them work known to contain a valid block solution every now and then? I'd be easy to get evidence this way.

I think Pool ops need to add to the User Agreement that users found to be selfish mining forfeit any non-dispersed mining funds and are contractually obligated to return their ill-gotten gains.  Most other users would support this.

The problem is how can you prove it statistically except for looking at massive deviations (like 6 magnitudes off).