Bitcoin Forum
August 31, 2016, 03:58:58 PM *
News: Latest stable version of Bitcoin Core: 0.13.0 (New!) [Torrent]. Make sure you verify it.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [23] 24 25 26 27 28 29 30 31 32 »
  Print  
Author Topic: bit pit - (LP, ESMPPS, 8-decimal payout, SSL, API, 0% fee, Almost 0% Stales!)  (Read 74688 times)
Sukrim
Legendary
*
Offline Offline

Activity: 1764


View Profile
July 18, 2011, 06:43:10 AM
 #441

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.

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
1472659138
Hero Member
*
Offline Offline

Posts: 1472659138

View Profile Personal Message (Offline)

Ignore
1472659138
Reply with quote  #2

1472659138
Report to moderator
1472659138
Hero Member
*
Offline Offline

Posts: 1472659138

View Profile Personal Message (Offline)

Ignore
1472659138
Reply with quote  #2

1472659138
Report to moderator
God is in Control: Music Video
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1472659138
Hero Member
*
Offline Offline

Posts: 1472659138

View Profile Personal Message (Offline)

Ignore
1472659138
Reply with quote  #2

1472659138
Report to moderator
1472659138
Hero Member
*
Offline Offline

Posts: 1472659138

View Profile Personal Message (Offline)

Ignore
1472659138
Reply with quote  #2

1472659138
Report to moderator
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 18, 2011, 06:47:08 AM
 #442

Yeah, Im curious too about the exploits for SMPPS.
1bitc0inplz
Member
**
Offline Offline

Activity: 112


View Profile
July 18, 2011, 06:56:16 AM
 #443

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  Smiley

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 18, 2011, 08:08:17 AM
 #444

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
Jr. Member
*
Offline Offline

Activity: 53


View Profile
July 18, 2011, 10:28:27 AM
 #445

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.

1JrEZbuiK1BBakhtVo9PiMctNCEhtcQAR
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1862


Poor impulse control.


View Profile WWW
July 18, 2011, 10:48:44 AM
 #446


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

Quote
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  Wink

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.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
1bitc0inplz
Member
**
Offline Offline

Activity: 112


View Profile
July 18, 2011, 02:34:59 PM
 #447

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.

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
nixpins
Newbie
*
Offline Offline

Activity: 10


View Profile
July 18, 2011, 09:42:38 PM
 #448

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

Feeling generous? 12TNW8XkHef8gxzy3nD5eeemDzE17cmPDD
Need a TradeHill referral?  Use my code: TH-R16558
1bitc0inplz
Member
**
Offline Offline

Activity: 112


View Profile
July 18, 2011, 10:38:14 PM
 #449

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

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.

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
dominatro
Newbie
*
Offline Offline

Activity: 15


View Profile
July 19, 2011, 05:48:03 AM
 #450

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
Member
**
Offline Offline

Activity: 112


View Profile
July 19, 2011, 05:59:35 AM
 #451

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.

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
1bitc0inplz
Member
**
Offline Offline

Activity: 112


View Profile
July 19, 2011, 06:11:58 AM
 #452

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.

Mine @ http://pool.bitp.it - No fees, virtually 0 stales, what's not to love!
Chat with us @ #bitp.it on irc.freenode.net
Learn more about our pool @ http://forum.bitcoin.org/index.php?topic=12181.0
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1862


Poor impulse control.


View Profile WWW
July 19, 2011, 09:21:01 AM
 #453

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

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
July 19, 2011, 10:48:45 AM
 #454

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.

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
dominatro
Newbie
*
Offline Offline

Activity: 15


View Profile
July 19, 2011, 01:00:40 PM
 #455

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
Donator
Legendary
*
Offline Offline

Activity: 1862


Poor impulse control.


View Profile WWW
July 19, 2011, 01:46:16 PM
 #456

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.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
flower1024
Hero Member
*****
Offline Offline

Activity: 840


luck is just a share away


View Profile
July 19, 2011, 02:05:20 PM
 #457

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
Member
**
Offline Offline

Activity: 84


View Profile WWW
July 19, 2011, 04:23:08 PM
 #458

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.

Mine @  <http://pool.bitp.it>
Chat with us @ irc://irc.freenode.net/#bitp.it
Learn more about our pool @ <http://forum.bitcoin.org/index.php?topic=12181.0>
lowentropy
Member
**
Offline Offline

Activity: 84


View Profile WWW
July 19, 2011, 04:25:29 PM
 #459

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

Mine @  <http://pool.bitp.it>
Chat with us @ irc://irc.freenode.net/#bitp.it
Learn more about our pool @ <http://forum.bitcoin.org/index.php?topic=12181.0>
owowo
Jr. Member
*
Offline Offline

Activity: 43


View Profile
July 19, 2011, 09:06:00 PM
 #460

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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [23] 24 25 26 27 28 29 30 31 32 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!