bit pit - (LP, ESMPPS, 8-decimal payout, SSL, API, 0% fee, Almost 0% Stales!)

[Sukrim]

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?

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.

[1714220940]

1714220940

[1714220940]

1714220940

[1714220940]

1714220940

[hugolp]

Yeah, Im curious too about the exploits for SMPPS.

[1bitc0inplz]

Yeah, Im curious too about the exploits for SMPPS.

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  

[hugolp]

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.

[Aexoden]

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.

[organofcorti]

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

edit 2 Fools! They take away total shares, but they do not take away time since start of round and average hashrate! BWA-HA-HA-HA-HAAAAA!

Easy enough to fix  

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.

[1bitc0inplz]

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.

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.

[nixpins]

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.  )

[1bitc0inplz]

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, 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.

[dominatro]

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?

[1bitc0inplz]

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?

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.

[1bitc0inplz]

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

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.

[organofcorti]

I just thought of another api hole. Was going to post it on bitHopper, but then I thought "why bother - bitpit will close the hole as soon as I post it" so I thought I'd go white hat and post it here first.

You need to remove your estimated shares from the api. As soon as a new block is found, they become 'unconfirmed', yes? So the 'estimated' goes to zero? Then a new block starts. So you set bitHopper to start when 'estimated'==0, and then hop off when after a number of shares using a guestimate of your hashrate (which using mperth's stats is more than '~50Ghps' 

Anyway I can see you're busy doing good work to get this place 'hopper-proof and thought you might like to close a hole before someone uses it. More than i did, I mean

[TheSeven]

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

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.

ESMPPS basically tries to pay (nearly) the same reward to all shares, no matter when they were found, whether you had a downtime, or whatever. Except for plain PPS with its rather obvious flaws, it seems to be the system with the lowest variance.

Shares and blocks will be completely decoupled in this system. The pool keeps track of all shares that have not been fully paid yet.

If you find a share, the pool will add it to a list of shares which have been paid 0% so far. If the pool currently has reserves from past short rounds, the shares will be paid immediately. Otherwise it will wait for a block to confirm, and once this happens, it will pick the shares that have been paid to the least percentage, and use the funds from the block to pay them more.
This means that it will first pay the shares from the current round (as these will be at 0% payout at this point) to the same degree as the least-paid previous shares. If there are still funds left after that, it will select those previous shares as well and pay them some more as well, and so on.

While, during an unlucky streak, this means that you might only be paid like 50% of the shares' value when the next block confirms, their payout will retroactively increase once the pool has more luck. This should in most cases happen within 2 to 10 rounds, and if everything works right, they should be around 97% of what plain PPS would have paid for them after that.

Regular 43% pool hopping won't increase your reward at all with this system. There is a new kind of hopping algorithm for ESMPPS that does work, but it would only increase your payout from ~97% to ~99%, so it's probably not worth the effort. During a discussion with various pool operators we also figured out a somewhat bulletproof way to detect (and ban) withholders, so they won't ruin the party either.

Finally, here's an example that shows the differences between SMPPS and ESMPPS:
Assumptions: The pool has fully paid all previous shares, there are currently no reserves, and we are at difficulty 1000000 (just an example). The pool currently has bad luck, and finds one block after 2000000 shares, and another one further 1800000 shares later.
SMPPS: The pool will first pay 50% of the shares of the first round, and transfer the second half of them to the next round. So the shares of the second round will be paid 36%, including the transferred ones. So the shares of the first round will end up with 68% payout, the shares of the new round with 36%.
ESMPPS: The pool will first pay 50% of the shares of the first round. After the next block, it will have 1.8m zero-paid shares, which will be considered first. As the lowest past payout is 50%, and there are enough funds to reach that level, they will be paid 50% as well. Now there are 5BTC left, which will be distributed to all shares in the least-paid category. After distributing those, the shares of both rounds will have been paid 52.6%.
If the pool now finds two lucky blocks in a row with just 200000 shares each, the payout ratios will look like this (skipping the math here):
SMPPS: After the third round: Round 1 shares: 84.1%, Round 2 shares: 68.2%, Round 3 shares: 50.2%
After the fourth round: Round 1 shares: 98.5%, Round 2 shares: 97.0%, Round 3 shares: 94.9%, Round 4 shares: 83.9%
ESMPPS: After the third round, all shares will have been paid 75.0%. After the fourth round, all shares will have been paid 95.2%.

For longer unlucky streaks, SMPPS can go down way below 1% payment for new shares, sustained thorugh several rounds, which would effectively kill the pool as nobody would want to mine under these conditions, even if it's known that it will recover one day. ESMPPS is much less vulnerable to this: Simulations showed it to always pay at least 7%, and it never dropped below 20% for more than five rounds in a row.
If there are withholders, they will further enlarge the SMPPS payout queue, so new shares will be paid even less, and this will never recover. This is no disincentive for withholders because they will have the last shares that will have been paid adequately, and it makes it really easy for them to kill the pool. For ESMPPS the same behavior will just decrease the payout ratio by about 1%, which is much less likely to kill the pool.

[dominatro]

I actually like the current system of proportional. I also don't poolhop, but I turn it off when there's a thunderstorm or power outage. I really find the stats useful, and since you could check that the time percentage I spend on this pool is >90% uptime, I think that should be tracked by the server, and full stats should be given to me and others with similar uptimes. If anyone abuses that information to go below 90% uptime, then any relevant stats can be removed again.

[organofcorti]

I actually like the current system of proportional. I also don't poolhop, but I turn it off when there's a thunderstorm or power outage. I really find the stats useful, and since you could check that the time percentage I spend on this pool is >90% uptime, I think that should be tracked by the server, and full stats should be given to me and others with similar uptimes. If anyone abuses that information to go below 90% uptime, then any relevant stats can be removed again.

....and then 'hoppers get a new account for the next block. Or have a very low hashrate account running constantly which feeds them the necessary api details. You could then track ip addresses, but then 'hoppers use tor or a dynamic ip that changes hourly. Even if you never publish stats, long polling lets you know when there's a block found and it is possible to use the time lag between polling reports to figure out which pool probably found it.

Proportional is just fatally flawed.  I'm sorry dominatro, because I  loved the excitement of a proportional system until i realised how much it cost me.

I'm glad you turn it off when there's a thunderstorm though.

[flower1024]

how fast does your db grow?
i tried to keep track of shares with couchdb, but i threw it at away after i realized that after only ten minutes it was about 3 mb.

[lowentropy]

I actually like the current system of proportional. I also don't poolhop, but I turn it off when there's a thunderstorm or power outage. I really find the stats useful, and since you could check that the time percentage I spend on this pool is >90% uptime, I think that should be tracked by the server, and full stats should be given to me and others with similar uptimes. If anyone abuses that information to go below 90% uptime, then any relevant stats can be removed again.

I really don't like ever taking stats down - hiding stats except for trusted miners doesn't really solve the root problem. We're doing it for the time being just to reduce hopping in the short term.

But I think you'll be happy with ESMPPS - it has a very low payout variance, much lower than with proportional. In other words, short vs. long rounds won't affect your payouts negatively except in the case of very long bad luck streaks.

[lowentropy]

how fast does your db grow?
i tried to keep track of shares with couchdb, but i threw it at away after i realized that after only ten minutes it was about 3 mb.

We don't store each individual share. That would be wayyy too much data

One reason proportional is nice is because it's so very easy to implement. You just need to store a shares count per user and round. ESMPPS has additional data storage needs, but still doesn't require storing every share.

FYI, the thing that ends up taking the most amount of data for us is actually the samples we use to estimate your miner hashrates. Good rate estimates require lots of samples

[owowo]

How about this: PROP but.
After a block has finished, remember the users that were connected to the pool with a "decent" hashrate at the time the block was found, then "close the doors" to new connections until the 43.5% point is reached, then open the doors to new connections. That way honest miners can reconnect before the 43.5% point, if they have downtime, because the pool "knows" them from the end of the round before.

With "decent" hashrate I mean a rate that is above a certain point to avoid hoppers having the 1Mh/s miner running just to be connected during the part after the 43.5% point.