Topic: bit pit - (LP, ESMPPS, 8-decimal payout, SSL, API, 0% fee, Almost 0% Stales!) - page 10. (Read 80771 times)

I completely agree. In fact, it's various flaws is what lead one of our members (TheSeven) to devise a reward system inspired by luke-jr's SMPPS, but hardened against various known attacks. We've been refearing to this new system as ESMPPS, or Equalized SMPPS. TheSeven can probably do it better justice than I can, but essentially it is SMPPS but differs in how it repays shares it's obligations when reserve funds are less than it's total obligations.

We feel that this new reward system will help ensure fair payment for all miner's based on their shares submitted. With this change to ESMPPS we will also be paying out on invalid blocks.

We are currently working on writing the implementation of this new system, and will have more information about our intended roll out date once it's implemented and fully tested. We will, for sure, be rolling it out at the beginning of a new round, so there will be no worries about dual reward system during a round.

Despite us loving this solution, we are still wanting to hear everyone thoughts on this transition. Hopefully TheSeven can chime in and elaborate on the reward system itself in greater detail.

Other than disabling parts of our API, we have not changed anything in the past few days. We've been heads down working out what our future reward system will look like.

I am interested, though, if anyone else is seeing anything similar. I can tell you for myself though, my miners appear usual.

exactly 33 hours ago on the hour the power turned back on after a power outage and I lost 4% of my hashing power. Did something change in the pool at around this time or is my hardware damaged?  If it is caused by the pool, please change it back. Anyone else experiencing similar issues?

Yes, it is truly a cat and mouse game. One which we hope to end, for good, soon.

Today in our IRC channel, #bitp.it, we made some REALLY good progress discussing the various reward systems. I, personally, have a favorite now. That is more than I could have said even yesterday. Hopefully we can re-enabled the API and stats back to their former glory before too much longer.

I apologize to everyone for the degraded statistics, and I hope everyone understands it's an effort to help protect the earnings of our members while we make our transition to a cheating proof reward system.

Does the leaderboard display the shares for every miner in the pool? If so, that may be another source from which to find "Current Shares in Round".

(Unless, of course, you're already subtly modifying this. You could even only display non-anonymous users' shares, and give an artificially deflated "Current Shares" value, perhaps causing hoppers to help the pool for longer.  )

Yes, that is a consideration too. We're calling it xPPS, and we've included that in our simulator as well.

It does seem to do very well at resisting several types of attacks.

ARGH! Noooooooo! Curses, foiled again.

Good on you for considering an antihopping solution. I also prefer Meni's algo. I know it's harder to implement, but eclipsemc has it (and continuum had it) running successfully. It also reduces variance if you set it up right, but as pointed out you'd need to ask for donations.

One upside of smpps is that it's where 'hoppers go to roost when there's no suitable pool to mine - so you're guaranteed extra hashes as long as there are prop pools out there.

After doing my own research, I generally prefer PPLNS with a rather high N (either difficulty or twice difficulty), because it's immune to pool hopping, and doesn't show tons of variance for the intermittent miners. A smaller N (such as difficulty / 2) is equally immune to pool hopping, but will show a higher variance for intermittent miners.

If you'd use any scoring system, the only one that's shown to be pool-hopping proof is the Geometric system devised by Meni. Its biggest problem is that with the suggested value for c (0.001), the variance can be quite high for intermittent miners as well, but no worse than PPLNS with a lower N. (Interestingly, with a rather high c like 0.5, it smooths out a lot, but that puts a lot more risk at the foot of the pool operator.) Geometric's biggest weakness appears to be that creating a zero-fee pool with limited risk to the operator and low variance for intermittent miners is difficult or impossible. You can have two of those three, but not all.

I used to like SMPPS, but its potential vulnerability to withholding attacks doesn't give me tons of confidence in its long-term sustainability.

What about a SMPPS without negative memory? There would be some loses when there is a bad strike at first, but eventually, because of probability compensating, the pool would have enough saved to whether most bad strikes without going into negative.

I don't want to, entirely, get into the details just yet as we are still working out the specifics of the model. However, lowentropy and I have been creating a simulator to model the various reward systems. https://github.com/lowentropy/pool_sim

And, it would appear that since SMPPS is neutrally biased on it's reserves, even a single person withholding block solutions can push the pool into the negative over a (relatively) short amount of time. I ran a simulation with (IIRC) 1% withholders (per hashrate), and it only took 100 rounds before the median reserves were at approx. -28 BTC.

Now, 28 BTC isn't much... but, for a pool the size of bit pit (or, frankly any of the other pools using SMPPS) neither is 1% a large number. If you model 3% it's even worse.

Now, before anyone says it, yes we're aware that block withholders are a problem in *any* reward system. And, we're also aware that (technically) there is nothing you can do about it. However, practically speaking, a pool that is in-debt to it's elders is not a desirable pool for new comers.

Combine that with a spike in hash rate during an unlucky round, followed by modest decline in the pool's hashing rate over a (small) period of time, and you are left with a very bleak outlook.

Again, the models are still being worked on. And, it is entirely possible that we goofed the simulation. What I do know, is that the data is telling us something that something is not something we want to rush into with more information  

Yeah, Im curious too about the exploits for SMPPS.

Which ones are these exploits for SMPPS?

I personally prefer PPLNS to Scored (via exponentials I guess?) as variance is a bit lower from my understanding and it's far easier to explain. Also it can more easily give estimates.

Easy enough to fix  

We agree, it's not a solution. It's a band-aid. However, we don't want to rush into a new reward system that might be just as poor of a choice a Proportional is. So, in order to buy us a little time, we've disabled part of the stats.

What this does for us is create a situation where the hoppers can never be certain when to leave the pool. If they stay too long they will "lose money".

We're not out to try and screw them or anyone over, so my hope is that they will just view this as a less than desirable trait and remove our pool from the rotation. We'll be switching to a non-hopping friendly method soon enough, so it's probably not worth their effort at this point.

On the topic of reward systems; We've analyzed SMPPS and have some concerns about it. We fear that it might be subject to types of exploits far worse than Proportional, so therefore we are holding off on making a final judgment until we can fully analyze the situation.

However, two options we've not really discussed (in this thread anyways) are PPLNS and Scoring. Thoughts anyone?

But with the speed and the start time they can get a good enough stimate. What they really need is the start round time. If they dont know when the round started they can not pool hoop. If they know, they can stimated and even if they cant get an stimate getting early and leaving at some random point is still profitable. The point of pool hooping is to get in at the beggining of the round of each pool to get a bigger change of getting shares of the short rounds and avoid the shares of the long rounds.

yes, but their algorithm needs the pool's shares in order to calculate the right time to get out of the pool.
if the total shares are 'zero' , then the algorithm "thinks" that it is the always the beginning of the round!
at least that is how i understand the auto-hoping fanctionality

I went to another pool because of the pool hooping problem here.

I dont see how removing the "share in round" solves anything. As long as they know when a new block was solved they can jump in at the beggining. Or what am I missing?

EDIT: There you go: http://forum.bitcoin.org/index.php?topic=26866.msg374692#msg374692

Great job everyone, we solved another block.

We are still working out which reward system is the most desirable for everyone, but while we are working out those details it appears that wild fluctuations in our hash rate is actually causing a detrimental effect on our members.

So, while we are sorting out the details, we are going to be temporarily removing the "shares in round" statistic from our API. I apologize for the inconvenience, but it appears that it's come to this.

actually, i meant to reset the report of "shares", not the real total pool shares
that would keep the auto-hopers in the pool for ever

That's what I called "proportional + auto-hopping" when I was evaluating different ideas. Except it's 43%, not 50%