Topic: [OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 # - page 107. (Read 458518 times)

I got your PM

Hi wk! Excellent work going on here. Thanks for your continued efforts on THE best BTC pool.

Question - how can we log into Eligius site to review order status in the store? Placed an order for a few of the Eligius USB Erupters with Canary. Order confirmation page gives link to check order status, but requires authentication to access the page.

How can one log on to access this? I don't see anywhere on the site? 

Followed up with Canary via dm, but curious to log on anyway... advice?

Thanks!

--
ronin

I'm delighted to be able to provide this service for Eligius and look forward to handling your orders professionally and as fast as possible!!!

Since I'm responsible for logistics, please contact me with your questions.

Thank you all!

Eligius is now offering Block Erupter Sapphire USB miner collectables for sale in the new Products section.
All units come with Eligius branding (USB device info), and tested against DOA.
The price of 640 TBC (1.05 BTC) already includes US continental shipping.
These are fulfilled through CanaryInTheMine and currently only available in the USA.

This is actually a result of the yet only known unresolved issue with my payout queue setup that I've not had a chance to address yet, related to using transaction fees towards payouts.  I've responded to a few other posts related to this before.

You entered the payout queue normally when you reached 100 TBC, and you were in the list of payouts for the block.  But, you were the last one on the list and thus were not paid fully, and part of your balance remained unpaid at the pool.

I've been trying to come up with a way to address this that doesn't "waste" generated coins by sending them to the pool wallet.

Sorry about that.  I will put working a solution to this higher on my TODO.

-wk

Why did I enter the payout queue with only about .09 BTC balance? I've been mining constantly, so it's not the 7 day timeout.

Probably came from Slush's.  Seems they lost a heap of hashing power due to a few blips in the matrix.

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

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

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

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.
 

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

thx )

Thank you

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

Welcome back, Avalon? =D

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

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

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.

the round of death 

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

 

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.


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