Pages:
Author

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

legendary
Activity: 1148
Merit: 1001
Radix-The Decentralized Finance Protocol
the base of economy and profit is how you can outsmart other people in a way that develops society!
Thus, it is only natural to try to find ways of maximizing the profit and let others "die" Cheesy

Corrected it for you.
hero member
Activity: 607
Merit: 500
the base of economy and profit is how you can outsmart other people!
Thus, it is only natural to try to find ways of maximizing the profit and let others "die" Cheesy
donator
Activity: 2058
Merit: 1007
Poor impulse control.
yep, just like I thought, it's difficult to see if the hopping is good or bad for pools or hoppers... too many parameters in the equation.
hurray for bitp.it changing their payout system, will have to see if theirs is better altough

No, hopping is provably good for hoppers and pools and provably bad for non-hoppers. And yes there are a bunch of parameters but luckily people much smarter than me laid the groundwork!
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
yep, just like I thought, it's difficult to see if the hopping is good or bad for pools or hoppers... too many parameters in the equation.
hurray for bitp.it changing their payout system, will have to see if theirs is better altough
donator
Activity: 2058
Merit: 1007
Poor impulse control.
It seems counter-intuitive that hopping actually gains more BTC for your users, but in many cases especially for smaller pools it happens.

This was purely one thing: luck.

There is one other thing though - you're getting a 100ghps boost for part of the round which must increase the average hashrate for the round. This in turn significantly will decrease the average time to solev a block and so on average decrease variance. I think this is what muyoso meant.

You could probably work out what the average  pool hashrate increase was - for a short round it would be significant (which makes short rounds take even less time) and for long rounds it would have less of an effect.

But even though rounds are being solved more quickly there are fewer shares per miner as opposed to no 'hopping and so less coinage. That's too much to pay for an increased average total hashrate and the low cost easy to calculate nature of proportional. 'Non hoppers still lose out.
hero member
Activity: 504
Merit: 500
FPGA Mining LLC
It seems counter-intuitive that hopping actually gains more BTC for your users, but in many cases especially for smaller pools it happens.

This was purely one thing: luck.
member
Activity: 112
Merit: 10
Also, let me just say that your site is EXCEPTIONALLY good.  I really like the layout and the design.  Simple and elegant.  Fantastic work.  It would be awesome if you would add on the Round History page the amount earned per solved block next to the status column and a total at the bottom. 

Thank you,

we appreciate the compliment.

Disagreement aside, those changes you are talking about are the type of thing I'd love to get back to coding  Smiley

Honestly, I'd love to see the round history show who solved it, how many shares it too, the "luck", and (like you said) perhaps some payout stats.
member
Activity: 84
Merit: 10
If I had to guess, I would say that people mining at your pool made more when the pool was being hopped than they did when it wasn't.  Sure they may have gotten a slightly smaller payout per block, but this 50Ghash pool discovered 9 blocks in under 5 days.  That is ridiculous for a 50Ghash pool.  Almost 2 blocks a day.  I don't have the statistics obviously, but I'd bet miners at this pool absolutely made more per 24 hour period while the pool was being hopped than they will/have without the hopping.

Actually, it's reduced our member's payouts to approximately 75% of what they would have been. We're else do you think the hopper's take their additional income from  Wink

And its more than doubled the NUMBER of payouts.  Average time to generate a block with 50Ghash would be 37 hours.  In the 5 days where your pool found 9 blocks, you regularly would have only found ~3.24 blocks.

Its your pool and I respect whatever you want to do with it.  It seems counter-intuitive that hopping actually gains more BTC for your users, but in many cases especially for smaller pools it happens.

Also, let me just say that your site is EXCEPTIONALLY good.  I really like the layout and the design.  Simple and elegant.  Fantastic work.  It would be awesome if you would add on the Round History page the amount earned per solved block next to the status column and a total at the bottom. 

member
Activity: 112
Merit: 10
If I had to guess, I would say that people mining at your pool made more when the pool was being hopped than they did when it wasn't.  Sure they may have gotten a slightly smaller payout per block, but this 50Ghash pool discovered 9 blocks in under 5 days.  That is ridiculous for a 50Ghash pool.  Almost 2 blocks a day.  I don't have the statistics obviously, but I'd bet miners at this pool absolutely made more per 24 hour period while the pool was being hopped than they will/have without the hopping.

Actually, it's reduced our member's payouts to approximately 75% of what they would have been. Where else do you think the hopper's take their additional income from  Wink

Here is a simulation using parameters in line with the hash rate flucturations our pool was receiving:


Code:
=== Prop ===

                         | Average       | Median        | Min           | Max           | Variance          
-------------------------+---------------+---------------+---------------+---------------+-------------------
Honest Earnings          | 720.8945      | 721.8807      | 690.2052      | 739.4789      | 78.5162          
Hopper Earnings          | 1848.3674     | 1842.9480     | 1783.1904     | 1947.1667     | 1126.3150        
Honest Shares            | 28326150.0621 | 28356810.6817 | 25249228.2421 | 30468502.4626 | 1278454932311.3887
Hopper Shares            | 31161689.6574 | 31166729.5802 | 29928070.3722 | 32233605.3469 | 178450276113.6692
Honest Payout Percentage | 76.4419       | 76.4535       | 71.7608       | 82.0071       | 5.6908            
Hopper Payout Percentage | 177.9985      | 177.1536      | 166.3651      | 195.1847      | 23.3973          
member
Activity: 84
Merit: 10
If I had to guess, I would say that people mining at your pool made more when the pool was being hopped than they did when it wasn't.  Sure they may have gotten a slightly smaller payout per block, but this 50Ghash pool discovered 9 blocks in under 5 days.  That is ridiculous for a 50Ghash pool.  Almost 2 blocks a day.  I don't have the statistics obviously, but I'd bet miners at this pool absolutely made more per 24 hour period while the pool was being hopped than they will/have without the hopping.

A person with 1Ghash would have made around 3.24 bitcoins during the same 5 day period if the pool wasn't hopped with an average round time of 37 hours for 50ghash/s at the difficulty of 1563027.  That same person ACTUALLY made 3.75 bitcoins while the pool was being hopped over the 5 day period before you started messing with the API.
member
Activity: 112
Merit: 10
How about this: PROP but.

I do think that you will enjoy our new reward system. The great thing about it is that it will reduce your variance. There is nothing to not love about that.

As for Prop., I'm afraid that was off the table for the moment we started discussing alternative reward systems. Proportional is just inherently flawed. The fact that it's payouts are predictably variant is enough to game it. I could continue to hide stats until I'm blue in the face, and they will be tit-for-tat with our changes. I've already wasted a week keeping them at bay, and in that week no new features have been coded.

I'd rather be coding features than hacking up our API, leaderboard, etc.
legendary
Activity: 2618
Merit: 1007
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.

This means you will screw all miners with hash rates below a "decent hash rate" + force hoppers to have a "decent hash rate"+1 MH/s.
Also there is no measure of hash rates to a pool - it is only an average over a certain time. If you out of bad luck don't happen to find any shares in this period of time, you seem to have 0 MH/s to the pool, even if you in reality have 1 GH/s.

Congratulations to be another pool stepping away from block limited proportional scoring!
newbie
Activity: 43
Merit: 0
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.
member
Activity: 84
Merit: 10
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 Smiley

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 Smiley
member
Activity: 84
Merit: 10
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.
legendary
Activity: 1428
Merit: 1000
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.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
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.
newbie
Activity: 15
Merit: 0
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.
hero member
Activity: 504
Merit: 500
FPGA Mining LLC
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.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
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'  Wink

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 Grin
Pages:
Jump to: