There has been good progress made on that, and I have all those numbers you ask for in our database. Unfortunately this past week has got us sidetracked fighting off DDoS attacks 

For the stability of the pool, this dictates that we must spend some more time applying some of our lessons learned and attempt to reduce the effects of further attacks.

I do not want to attempt to guess when we will feel comfortable with our additional measures and be able to return to developing features. However, I completely understand the interest in trying to be transparent. If you (or anyone else) wants up to the minute details on those stats, do not hesitate to #bitp.it on irc.freenode.net and I'll be glad to give you all the information I can. Considering we haven't yet exposed that via the UI, it's the least I can do.

Good morning Bitcoin world!

I do believe you, and I am extremely sorry about the situation. I wish there was a way I could find out what all was lost during the downtime (for everyone), but unfortunately if the queue crossed the high water mark and started discarding new messages there is no hope of recovering those.

I know it doesn't make up for anybodies lost work, but if it's any conciliation, I am working right now on some steps to attempt and limit the impact of future attacks of this nature. I am not saying it will stop the attacks, as attacks of this nature of purely a cat and mouse game, but hopefully it will mitigate some of the symptoms.

I apologize for the downtime. We've been under some form of an attack (some form of DDoS I suspect) for going on a week. Last night was by far the worst, it brought the entire system offline. In fact, somewhere in the whole mess our accounting process locked up and was offline for about 6 hours.

I restarted it the first thing when I noticed it (when I woke up). It processed every share in it's queue. All shares in the queue were accounted for.

If shares are "missing" it could be for one of two things. Our pool was offline a lot, and therefore your expected share rate per hour would not be equal to what we were all actually getting.

If shares were missing for any other reason, it's probable that the sheer number of shares in the queue exceeded the high water mark. If  that is the case, then the attackers have screwed us all over pretty big 

sorry guys, our accounting piece lock up during last nights DDoS.

I've restarted it, and it is now catching back up with your share submissions. Nothing was lost.

On a plus side, the rapid accounting over 6 hours worth of shares made a hugh impression on Bitcoin watch  :

Wow, and long block solved and then another one right in a row! I should voice my concerns about long block more often, lol 

Come on long block, you sure are long 

Good question. It's mainly just the way we've got things coded right now. We need a fix schedule at which to run our reward disbursement algorithm, and block confirmation made the most sense as that is when the pool receives income, thusly maximizing the total possible payout. Additionally, when we first switched over to ESMPPS we had 0 buffer (obviously) so for the first round (at least) we had to wait for the block to get confirmed.

Right now, if a block is invalidated, the shares from that round are included on the next rounds payouts.

w00t!

That was a much deserved payout for everyone! Hopefully round 26 doesn't prove to take nearly as long 

We truly appreciate it. All of our members (part time or not) are really important to us. The fact that you try and jump in and help on the long rounds is really a good thing 


We can certainly add CDF to our stats bar. Right now one of our members has it in the unofficial bit pit IRC chat bot 

As for predictions of when funds will become available, that is something that is a little harder to predict. It's always 120 block confirmations after the round ends, but there is no way of knowing when a round will end.

Luckily we just ended round 25! Great job everyone!!! So, the shares from that round will be made available once the block reaches 120 confirmations.

Welcome! I'm always glad to see new people 


The buffer is fine. We've had several lucky rounds, and have a nice surplus at the moment. Getting this information displayed is a high priority for us, and something we're actively working on.

In regards to the full share price. ESMPPS will remember your full share price, and will always try and make that up to you if the buffer runs out. Shares never depreciate in value.

One thing to keep in mind, is that the graph shows exceptionally bad luck over a very short term. To get a true picture of how a payout method effects a user (and a pool) one must consider all possible outcomes.

When we were developing ESMPPS we created a simulator to plot the various possible outcomes of a payout system. It doesn't have a lot of these methods, because some we were not considering. But, it does currently simulate ESMPPS, PPPS, SMPPS and Prop (for a baseline). And, since it's open source, I highly encourage everyone to play with it and (perhaps) implement some of the above methods that are missing.

The URL is: https://github.com/lowentropy/pool_sim

I think your thread title is wrong, you pool has less than 18 GH/s, not 70 GH/s 

Indeed, congratulations all around 

Older versions of the Bitcoin app incorrectly calculate difficulty. The difficulty listed on bitp.it is the correct difficulty. Seemingly that site is either running an older version of bitcoind or is pulling from somewhere that is.

lol, perhaps he has alost not been to his only pool's website as well 

Great job everyone, another block well done 

I do not know much about your backend, but it sounds like we are two entirely different architectures. On my pool we use Redis (a no-SQL datastore) and Node.js. Additionally we have a single "getwork server". So, since Redis stores everything in memory anyway, we were able to really quickly re-perform the scoring algorithm on every share submission. Unless you centralize your share data in someplace other than SQL, I do not think our solution will be easy for you.

I am curious, why do you have multiple servers? Is it to allow for users to be closer to a server (e.g., geographic distribution), or are you doing this for performance reasons? If at all possible try and consolidate your getworks to a single server, and I think that will open up more possibilities to you.


I am not aware of any single post that fully describes ESMPPS, unfortunately. I'd love to write one, but I've just been pretty swamped lately.

ESMPPS does not depend on luck to even things out. In fact, that is one of the key differences between it and SMPPS. SMPPS pays out older shares first. So, if the pool gets behind on payment, then it neglects newer shares to pay back older shares. This creates a problem where new miners may have to wait several rounds without any payment before receiving any of their earnings. Obviously nobody wants to work for "free", so it would be a very disastrous thing for a SMPPS pool to go red.

ESMPPS solves this problem by putting all shares into "buckets", allocated by their percent paid.  A bucket is never paid more (percentage wise) than the least paid bucket. This allows for all shares to be paid the maximum amount possible, while not favoring older or new miners.

Take the scenario where a pool is always lucky. The pool would therefore always have a positive buffer, and therefore pay 100% of what a 0% "true" PPS would. However, you and I both realize two problems with this scenario. A, no pool will ever be lucky 100% of the time. And B, no "true" PPS can sustain a 0% fee.

So, let's look a a difference scenario. Say you pay out on invalid blocks, and have a 0.5% block withholder rate (e.g., 0.5% of your pools hashing power is "attacking" you by withholding any block solutions they may find). Assume the probability of a block becoming invalid is ~1%. Also, assume that "luck" nets out to 0 over a long period of time.

In this scenario, you will eventually reach a future where no bucket is paid past the 98.5% bucket. However, unlike *MPPS systems old and new shares are paid immediately up to the 98.5% range. This underpayment is remembered by the system, and if the buffer goes positive, the backpay is made up. Interestingly enough, even in this scenario the ESMPPS pool still behaves "normal" and outperforms any true PPS pool, provided that true PPS pool charges more than a 1.5% fee.

IMHO it's a pretty interesting dynamic, a pool that "self regulates" itself. This is, ideally, what a true PPS pool tries to accomplish when the pool operator charges a fee. However, in the case of ESMPPS it set by the probabilities of the situation itself, and if the situation takes a turn for the better then everybody wins. If the situation stays the same, it still outperforms true PPS.

You are correct.

If I am not mistaken, ACH transactions can be reversed 30 days after the fact. And, in certain circumstance, I believe their is even a larger window for which the ACH can be (at least in part) reversed.

Sorry about that  That is just one of those features we haven't gotten back around to yet.

If you'd like, you can contact us (or PM me) which worker(s) it is you'd like to remove, and I can manually assist you.