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

[purelithium]

Thanks for the explanations, guys!

[1714267646]

1714267646

[1714267646]

1714267646

[1714267646]

1714267646

[matt4054]

First, let me point out that no donations are needed for this.  I'd much rather you understand the system regardless.

I'm not sure what you mean by "strobes", but I will attempt to explain your personal situation in as much detail as possible.

Lets first take a look at a historical graph of your mining hashrate and balance changes:
(...)
I hope this helps you understand the setup better and the details of your particular situation.

Thank you *very much* for this very detailed explanation. Now I'm convinced you are right

Ironically, a couple of hours after your reply, I see some shelved shares taken to estimated during lucky phase i.e. early in the latest round, for the first time in >2 weeks. Looks like I was impatient (and unlucky, as you pointed out) after all indeed.

Donations are never needed but always appreciated, I guess. You can count on the 0.2 BTC donation as promised, I will post txid in a few days, hopefully from my shelved shares

Thanks again for the time taken responding to this, I appreciate it.

[pikeadz]

stats are not updating for me.

[spooderman]

Can't connect to GBT or Stratum. Getwork worked for me for the last three weeks and now I can't connect to that

[wizkid057]

Can't connect to GBT or Stratum. Getwork worked for me for the last three weeks and now I can't connect to that

No connection issues on this end that I can see. Thousands of workers connected.

[spooderman]

Can't connect to GBT or Stratum. Getwork worked for me for the last three weeks and now I can't connect to that

No connection issues on this end that I can see. Thousands of workers connected.

So i see I wish I understood mining a little better. Using diablo on a mac pro. This might be why I have so many issues. Most pools I get nowhere with. Guild....slush etc. Only one I have any joy with is eligius' getwork, 50btc and bitminter. Bitminter was a no-no after the endless DDOSing.

I just get error messages and nothing happening when I try to connect to others.

Sorry I realise this should be somewhere else....anyone wanna send me somewhere I can get some help?

[purelithium]

You're gonna have to update your miner, I think... Give MacMiner a try (https://bitcointalk.org/index.php?topic=197110.0)

[wizkid057]

Greetings Eligius miners!

So, let me go over a few things. 

First, I've caught up the payout queue completely with txn 3b529c9505fedbe31323f98963ae7bb38b88bb66b95bee7a1c8ce2ad2c58ae86.

Pool has been doing pretty well!  CPPSRB has been serving everyone quite well.  100% PPS has been paid for all work for over the past month!

Unfortunately, there was a minor mishap last evening.  In the interest of continued openness with the community, and to make a long story short, last night the pool reward system code did not pick up on a block the pool found, 245236.  So, the reward system did not calculate anything based on the payouts in that block, and then block 245239 was found without it having knowledge of 245236, thus mostly doubling up on the payouts in the block.  (See 245236 and 245239.)

Quick summary: The pool overpaid some miners.  Fortunately, over 90% of the overpayment was recovered.  The remaining ~2.3 BTC I have covered out of pocket.  The error causing this has been corrected.  Overall, there is no cause for panic and business continues as usual. 

Here are the details.

The cause was an extremely rare race condition between the pool server->database->reward system made possible by our recent growth and the need for multiple eloipool instances.  Code has been put in place to prevent this from happening in the future, as well as a few other potential problem conditions.  (Technical details:  Eligius uses a postgresql back end.  One table is used to store every incoming share in a row, using a automatically incremented sequence number.  Eligius is running 15+ instances of the eloipool open source pool software, all of which have a connection to the database and are inserting rows in a BEGIN INSERT COMMIT style.  We average somewhere around 1000 inserts per second.  As it turns out, there can be an initial collision of sequence numbers.  This is always corrected.  However, there is a rare case where two inserts try to use the same sequence number, they both fail because of it, and get issued new ones, skipping the original.  This causes a brief delay as everything recovers from the collision, and the original insert gets processed several hundred rows after it was supposed to.  In our case, the reward system had already read back the chunk of rows where the block-winning-share was eventually inserted, but before it was completed, resulting in data returned omitting this particular row in the eyes of the real time reward system. I could find very little documentation on this "feature", but, it is expected that there will be gaps in postgres serial sequence numbers  For the correction, the reward system code now checks to make sure that any blocks that contain Eligius payouts that appear on the network are flagged and verified as being reconciled with the reward system.  It also attempts to wait on any gaps in the postgresql sequence numbers and rechecks data near any missing ones.  The combination of the two fixes will prevent this situation in the future.  As an added bonus, the pool software now provides it's current best previous block hash to the reward system and the payouts are verified to match before being valid.).

The reward system missing the block/payout resulted in an over payment of most of the miners included in block 245236's payouts.  When this was noticed, I shutdown the reward system to investigate.  With the payout system disabled, this allowed time for some of the miners who were included in this over payment to continue to mine and slowly correct the over payment.  Luckily, we found five blocks in that time frame.

As of the time the reward system was brought back online and all was reconciled, the total over payment amount came to 6.995 TBC (2.30075557 BTC).  I have personally absorbed this final over payment amount out of my own funds.  Last night, however, I had braced for the worst (all miners affected leaving the pool and not offsetting the over payment) and semi-expected a full 25 BTC shortage, which I would have needed to pay to cover miner payments.

Here is the final remaining list of miners that were overpaid.  Some portion of the over payment was able to be applied to these miners' shelved shares so that the over payment did not result in a huge over payment with regard to work-completed.  However, the payments of those shelved shares is not part of the normal block reward and thus is included in the total over payment amount above.

Code:

0.01373157 BTC - 1DkXMqzxJ4mrZhT25ET48wzxLK7Z5dLDTC
0.02435758 BTC - 1PzV9kHvB2vU3np2Ei1YxvPAS8HZppJ5UX (0.02435758 BTC applied to shelved)
0.04976031 BTC - 15oQaoMxK9d6DGVFSSnJUYEjPsd77X1KPB (0.04976031 BTC applied to shelved)
0.07145660 BTC - 12EDsoSowtFgcZPAdhB74AwPkcu9mhy37P (0.07145660 BTC applied to shelved)
0.09235259 BTC - 1Duder7vFJVmvq3SrixDCY1knShZ7LEF8R (0.00980343 BTC applied to shelved)
0.09556698 BTC - 19d6exSEyAPDXLLe3W3ucexpVXUABFeFsy (0.09556698 BTC applied to shelved)
0.10163246 BTC - 12tKVT4KupVY2sVzSX4jnBWC9ZjzFHbtQg (0.01093716 BTC applied to shelved)
0.11408797 BTC - 1CLr2aR8DrjRxSgQbhim3BNeeZHY2Ug26B (0.11408797 BTC applied to shelved)
0.12780791 BTC - 1ALkgvSRuAGuVtyUVGfncuRxmHa7gUVQQt (0.12337554 BTC applied to shelved)
0.12923071 BTC - 1Mcc4H1MRVWxGNGSZ7RiYsKFboeV2jU2Kt (0.00711126 BTC applied to shelved)
0.15235391 BTC - 1ELFX9sovv4LbsmEV3ivbVZS7s5Dr5Sj8f (0.00241371 BTC applied to shelved)
0.15360348 BTC - 1Q8eAfxs5fuTWJE2hLoyYspzU5TrRWQeFf (0.01646416 BTC applied to shelved)
0.50090432 BTC - 1Foh62T2GcMNj9wh3nqc7bSD1EhsQ5BKpe
0.67390918 BTC - 1Q56RJLDotSBGD2386juC4ffefxG3Zx3KV
Total Overpaid: 2.30075557 BTC

If any of these miners are kind enough to come forward and return any portion of this over payment, please do so, and it would be greatly appreciated.  I There are no negative balances on Eligius as a result of this.  If anyone is kind enough to return any of these over payments, or is otherwise willing to donate to the cause, again, it would be greatly appreciated and you may send said funds here: 1oopsyR7UB3kA1cr6ka7bDLnYbFRBnHmN (yes, oopsy...)

I apologize to everyone for this issue.  It is fortunate that the majority of the miners at Eligius are honest and continued to mine even after the over payment, and I thank you all for that.  To those who did benefit from this mistake I do welcome you back and will not penalize you if you decide to continue mining at Eligius.  While the mistake was obvious, and I would hope that no one would intentionally take advantage of the pool, it also was not the fault of any miner, so, I can not hold anyone else accountable for the error besides myself.  It is also fortunate that the error was caught quickly.  It is also very fortunate that the form of Eligius's payouts (payments directly from the coinbase) limits the potential impact of these over payments to at most, one block reward, where other reward systems at other pools can (and have) lost hundreds of BTC to errors.

To summarize again:  Business as usual now.  I have fronted the coins for the over-payment out of my own funds (not the pool's).  The error was the result of a rare race condition that was not taken into account in the reward system code.  The code has been corrected.  There was no compromise of any pool systems in any way.  No miners were negatively affected by this.

Thank you all for your continued support of the pool!  I think there are great times ahead for us!

-wk

[BitMinerN8]

Sent 1 BTC for all your hard work and to help with this situation. Thanks for running a great pool.
https://blockchain.info/tx/f434da12572c82f97c22c8d2a56bb2f7bd16e34c5afd31c5441747f975011671

 

[freshzive]

the round of death 

[GrapeApe]

My stats have not been updating the last few hours. A couple of blocks have been found and no change. I see post like this and it almost always works  itself out so I'm not that worried about it but I thought I should point it out.

[wizkid057]

My stats have not been updating the last few hours. A couple of blocks have been found and no change. I see post like this and it almost always works  itself out so I'm not that worried about it but I thought I should point it out.

Just one of the new failsafes I implemented the other day being a little overzealous. No worries. I'll have everything straightened out when I get home in a couple of hours.

-wk

[GrapeApe]

My stats have not been updating the last few hours. A couple of blocks have been found and no change. I see post like this and it almost always works  itself out so I'm not that worried about it but I thought I should point it out.

Just one of the new failsafes I implemented the other day being a little overzealous. No worries. I'll have everything straightened out when I get home in a couple of hours.

-wk

I knew you had it under control.Thanks for all the hard work...

[meisenst]

#1   1AYdAw8CcrQ2wx55LTbFHRn5bxgNZhaRLW   2,351.78 Gh/s   5913719   20.2971%

Welcome back, Avalon? =D

[spooderman]

You're gonna have to update your miner, I think... Give MacMiner a try (https://bitcointalk.org/index.php?topic=197110.0)

Thank you

[dunup]

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

thx )

[tryexcept]

Maybe I'm missing something but:
What is the policy about IP logging, i.e. how long after one mines there and then stops these logs get deleted ?
From http://eligius.st/wiki/index.php/FAQ it doesn't say.
 

[wizkid057]

Maybe I'm missing something but:
What is the policy about IP logging, i.e. how long after one mines there and then stops these logs get deleted ?
From http://eligius.st/wiki/index.php/FAQ it doesn't say.
 

All shares submitted are logged in a database, and the row contains the username, IP, submitted share data, and some other related columns (accepted, was a block, difficulty, etc).  This data, as of now, has never been deleted and is instead dumped, compressed, and archived periodically.

This database is also replicated to the open-access web server, but without the IP column, so only myself and/or Luke-Jr would have access to the IP data.

-wk

[Luke-Jr]

Maybe I'm missing something but:
What is the policy about IP logging, i.e. how long after one mines there and then stops these logs get deleted ?
From http://eligius.st/wiki/index.php/FAQ it doesn't say.
 

All shares submitted are logged in a database, and the row contains the username, IP, submitted share data, and some other related columns (accepted, was a block, difficulty, etc).  This data, as of now, has never been deleted and is instead dumped, compressed, and archived periodically.

This database is also replicated to the open-access web server, but without the IP column, so only myself and/or Luke-Jr would have access to the IP data.

Although there is a policy to not disclose the information without due process of law (see FAQ for details).

[wizkid057]

Maybe I'm missing something but:
What is the policy about IP logging, i.e. how long after one mines there and then stops these logs get deleted ?
From http://eligius.st/wiki/index.php/FAQ it doesn't say.
 

All shares submitted are logged in a database, and the row contains the username, IP, submitted share data, and some other related columns (accepted, was a block, difficulty, etc).  This data, as of now, has never been deleted and is instead dumped, compressed, and archived periodically.

This database is also replicated to the open-access web server, but without the IP column, so only myself and/or Luke-Jr would have access to the IP data.

Although there is a policy to not disclose the information without due process of law (see FAQ for details).

Probably should have mentioned that, but, figured it was obvious.

FAQ Here: http://eligius.st/~gateway/faq/i-represent-law-enforcement-and-we-are-investigating-crime