|
I wouldn't buy anything from him without escrow.
Just saying.
|
|
|
|
A *MPPS pool with a positive buffer is always better than one with a negative buffer if all else is equal. I'm not denying that. RSMPPS makes it better, but it's still a problem.
All payout methods has their own problems. If there was a perfect one, we wouldn't be discussing this anymore. But in my opinion, *MPPS pools are more fair and RSMPPS does the best job at not causing miners to quit when the buffer goes negative.
Well, the only problem with geometric scoring is that it is not really user friendly (hard to understand for average users), and a bit processor intensive for the server. The only problem with PPLNS is a little weirdness around difficulty changes. If you account for this with some pretty easy scoring, it works perfectly. And I think PPLNS is quite user friendly. So I contend that there is better out there. |
|
|
|
If you think -7.5% and our current difficulty luck is suspicious, I'd recommend you stay quiet if anybody ever asks your opinion on probability and statistics. Everybody is quick to jump to conclusions when luck is negative.
I don't see anybody saying "I think he's adding fake blocks to make us happy" when Deepbit has had 12% positive luck during this difficulty while being MORE THAN TWICE our size, considering according to your post you think that having 2.0-2.4 Th/s should make such a huge luck (positive or negative) should be "extremely unlikely.", which would infer having 5.1 TH/s should make it even more "extremely unlikely."
It isn't our current luck that has me concerned, but our luck going back. I won't go into details because I don't want it to be implemented, but there is one specific way to cheat that would be very easy to pull off. It would be nearly undetectable and the only symptom would be bad luck. The problem is, going back 2 months there has been constant bad luck, not some up some down. I'm questioning, but not accusing you. I don't know you, and I have come to realize that a lot of people in bitcoins are inherently dishonest. Unfortunately, there is really no way for the miners to act as a check on the pool, so we have to make these judgements. As someone who spends a decent chunk of his workday in the guild's IRC channel, I have to say that I have no worries about Eleuthria being dishonest. |
|
|
|
In the other you are guaranteed less than full payout for quite a long time, since you have to pay off unpaid shares which others have accumulated. You are getting less than proportional in this case, right? This is true of SMPPS and, to an extent, ESMPPS, but it is not true of RSMPPS or CPPS* which prioritize the present and future over the past. Ok, so let's talk specifically about SMPPS and ESMPPS then. The catch is, the fact that you are a new miner in my above example is irrelevant. Because if you have a lot of shares built up at an SMPPS pool, it still behooves you to switch to the other SMPPS pool, because you are going to make your owed money back at the first pool whether you mine there or not. So if you switch, you get full credit for your current mining efforts, and then you get some trickle from the other pool finding blocks. The problem is that everyone will do this, and the pool will die. I am not familiar with CPPS* so I cannot comment on it. RSMPPS is an improvement, in my opinion. However, if the block buffer <= 0, there is still a non-zero chance you could fall into the negatives, and thus, not get paid in full for the next block (if it has to roll over to future blocks). Therefore, as soon as the buffer hit zero, it would behoove you to switch to another pool where you are guaranteed full payout. Let me know where your complaint with my logic is. |
|
|
|
In a *MPPS pool you get paid the expected payout in the best case and less in the worst case.
On Prop. you get paid far more than expected in the best case and far less in the worst case (which evens out if there are no hoppers). Not quite. All variations of *MPPS will pay you extra for formerly underpaid blocks, making them even out even without hoppers. In the scenario where the pool never evens out, neither would proportional. Empirically, perhaps you are right. There could definitely be cases where you will be underpaid for long portions of time in a proportional pool. See BTC Guild currently for an example. They have had bad luck the last several difficulties. But that doesn't matter, because it should even out in the long run. There is no reason not to mine there (other than the fact it is proportional, and seems to be DDoS'ed a lot because it is big). However, I want to paint a scenario for you. If there were two pools, both *MPPS, one with a 20 block buffer, and one with a 20 block deficit, which would you mine at if you were a brand new miner? In one pool you are guaranteed a full PPS payout for quite a long time regardless of when the pool finds a block. In the other you are guaranteed less than full payout for quite a long time, since you have to pay off unpaid shares which others have accumulated. You are getting less than proportional in this case, right? Does anyone disagree with this? |
|
|
|
|
To clarify, this may be what people are missing.
You think that it is fair because at worst, you end up getting paid as if it were a proportional pool.
However, proportional pools are fair because you get the benefit of short rounds to even out the pain of the long rounds.
PPS is fair because you get paid 'what you deserve' even during long rounds, but you actually lose out on short rounds.
So a pool that gives you the payment of a PPS pool on short rounds with the payment of a proportional pool on long rounds should be avoided at all costs.
And that is exactly what a *MPPS pool is if it is significantly 'behind'.
|
|
|
|
Not to throw in a conspiracy theory, but I have been questioning btcguild's honestly as of late...
The "luck" of btcguild has been:
Luck this difficulty (1690906) 1937899 shares (-12.7%) (weighted down 54% since in progress = -6.9%)
Luck at difficulty 1563027 1690231 shares (-7.5%)
Luck at difficulty 1379223 1384144 shares (-0.4%)
Luck at difficulty 876954 875473 shares (+0.2%)
Given the hashrate > 2 Th/s, being consistently low on luck makes me think something is up. I understand probability, and the fact that there are up days and down days, but this shows a 2 month average of -5.4%. This should be extremely unlikely, and makes me wonder if BTC Guild isn't holding back a good percent. Any math majors out there want to calculate the probability?
I think the -7.5% is not real because it includes the DDOS attack time. I actually suspect that sometimes something happens during the server changes because we always seem to get bad luck when one occurs, but I dont suspect eulethria honesty (hopefully I wont have to eat my words). The bad luck should be independent of DDOS because no shares are submitted during that time. We've just been unlucky. |
|
|
|
|
I signed up for your list already!
|
|
|
|
So I may have missed something in the last three pages, but I don't see how this really fixes anything.
You correctly pointed out the issue with SMPPS, but even with your system, I don't see the difference.
Let's say you are running a RSMPPS pool that 'is behind'. I am a miner that is looking to be paid fairly.
There is another SMPPS pool out there that 'is ahead' (or some other cheat proof pool, or solo mining, or whatever).
Which am I going to choose?
This round there is a 50% chance that we will solve a block in < N time (where N is difficulty).
There is also a 50% chance that we will solve a block in > N time.
If I enter the 'fair pool' (cheatproof or SMPPS that 'is ahead') my expected earnings from mining here are exactly what they should be.
If I enter the RSMPPS pool, my expected earnings are lower because:
+ If we solve the block in more than N time, I will be underpaid for my shares
+ Not only that, but if we solve several blocks in a row slowly, it makes it even less likely that I get paid what I am owed in a reasonable amount of time.
+ Not only that, but a logical person would never mine at a *SMPPS pool that 'is behind', because of point 1 and 2, so they would quit and you would actually end up NEVER getting paid.
Does this make sense, or am I missing something?
You argument is flawed b/c if you assume that you are solving blocks slowly for an extended time, you will get paid just like a proportional pool. How is that worse than a normal prop pool? Yeah, sure it might take a while (until pool gets lucky) for you to get paid your total PPS reward, but at least there's a chance you will get paid. The problem with any *SMPPS pool is that if there is a bunch to choose from, you would always choose the one that has a positive buffer. So it may lead to pool hopping due to buffer size. RSMPPS does a better job in alleviating that but not fully. Because in a proportional pool you get paid far more than you do in PPS on short rounds. |
|
|
|
|
Me personally? If it is DOA, or somehow obviously doesn't work when you get it, you just pay return shipping and I'll give you your $111 back.
But I think there might be a 2 year warranty through Sapphire. I don't know if it is easily transferable, or how that works though.
|
|
|
|
|
Does a Sapphire work? I bought it from Newegg two months ago. It works perfectly.
I have flashed the Bios to make it boot at 975/300. I can flash it back to normal if you are going to put it in a Windows system.
I can drop it in the mail tomorrow if you want.
Thanks,
Kyle
|
|
|
|
|
If you do traditional PPLNS (without scoring) it is still quite fair (compared to things like *MPPS and Proportional), and it doesn't obfuscate anything. It is incredibly simple.
I would love *MPPS as a miner, because I know exactly which pools to mine from, but I would never run one, since it will just take one bad string of luck to put you out of business if your miners are looking to maximize profits.
|
|
|
|
The case was sold, I have all test benches now. Easier to cool them. They are all multi gpu units. 2 dual card units and one 3 card unit that has not been built yet. They are only 3 months old so Im not going to give a crazy discount, especially if youre trying to piece it out. It makes more financial sense to keep mining and get the $ each week than piecing them out one by one.
I actually want to know something like this: CPU1: 3x5830 Sapphire 2gig flash drive Sempron 140 Antec 1000W power supply MSI xxxxxx motherboard CPU2: blah blah blah |
|
|
|
No matter what reward method is used, when a pool is down to zero buffer on a long round, it must either underpay or create debt for the pool owner. That is an inevitable fact of pooled mining. Nothing can stop it. *MPPS attempts to mitigate it by offering to make up for the loss later.
This is only true for PPS systems. If you do something like the PPLNS that Meni and I have talked about, the variance is pushed to the miners, and not the pool owner. Discarding transaction fees (as most pools do) you will get exactly what you deserve over the long run, with no worries about being underpaid or about the pool owner going bankrupt. |
|
|
|
|
Can you give the specific specs of each system?
|
|
|
|
Recently, I've been trying to find a pool that has the most fair payout system that deters pool hopping. Slush system works ok but it's really bad for people that are not doing this 24/7. Deepbit deters pool hopping but the delayed statistics is annoying. I came across Eligius' Shared Maximum Pay Per Share (SMPPS - http://eligius.st/wiki/index.php/Shared_Maximum_PPS) model. This model works well but I believe there is a flaw. When the pool is running lucky, all is good. But when the pool is running unlucky, there is less incentives for people to join the pool because they know that they will not get their full PPS reward because a part of the earnings will need to be shared with other users that were owed rewards from previous unlucky blocks. This could potentially lead to a vicious cycle where if the difficulty increases and the pool's hashrate does not increase to match, the pool will earn less BTC and would not be able to cover the previous debt. For example, imagine if a SMPPS pool is unlucky and currently running a 100 BTC deficit. Why would I want to join this pool? For every 1 share I contribute, I would have to likely share it with 2 others for the 50 BTC earned. Let's say the next round is an average round. The pool earns 50 BTC, but since the deficit is now 150 BTC, I will only get a third of the payout right away and need to wait for the rest… assuming I will eventually get them. So why not just join a SMPPS pool that is currently lucky? That way, I will get all the PPS rewards that I contribute. I believe this leads to pool hopping not due to long rounds, but due to lucky/unlucky pools. I have a proposal for a better PPS system that I'm calling Recent Shared Maximum PPS or RSMPPS. The idea is simple. It's basically SMPPS, but instead of paying out the reward to all unpaid PPS proportionally, RSMPPS will favor recent blocks. So it will first proportionally pay out the unpaid PPS for the current block (the one that was just found). If there are any remaining rewards, it will pay them out to the next recent block that has unpaid PPS shares. It will keep doing that by paying out unpaid PPS shares from earlier and earlier blocks until all 50 BTC are paid out. If there are any left, it will keep those for the next unlucky round. This system will have no disadvantage for new miners joining the pool, because rewards will be first paid to the people that actually worked on the current block. So there's no debt burden on new users. And old unpaid PPS shares will get paid out if the pool gets lucky enough. With this system, it's possible for the pool to never get lucky enough to pay out really old unpaid shares. I think that's fair. What do people think? So I may have missed something in the last three pages, but I don't see how this really fixes anything. You correctly pointed out the issue with SMPPS, but even with your system, I don't see the difference. Let's say you are running a RSMPPS pool that 'is behind'. I am a miner that is looking to be paid fairly. There is another SMPPS pool out there that 'is ahead' (or some other cheat proof pool, or solo mining, or whatever). Which am I going to choose? This round there is a 50% chance that we will solve a block in < N time (where N is difficulty). There is also a 50% chance that we will solve a block in > N time. If I enter the 'fair pool' (cheatproof or SMPPS that 'is ahead') my expected earnings from mining here are exactly what they should be. If I enter the RSMPPS pool, my expected earnings are lower because: + If we solve the block in more than N time, I will be underpaid for my shares + Not only that, but if we solve several blocks in a row slowly, it makes it even less likely that I get paid what I am owed in a reasonable amount of time. + Not only that, but a logical person would never mine at a *SMPPS pool that 'is behind', because of point 1 and 2, so they would quit and you would actually end up NEVER getting paid. Does this make sense, or am I missing something? |
|
|
|
Is it just me, or are stales going steadily up? I was at .3% stales, then it went up to .5%, and now I am at .8%. At what point should I start to get concerned?
I'm at 0.45% for the past 13xx shares, but almost all of that was from the last 315 shares due to my ISP resetting my ADSL connection so it seems alright on my side. Could definitely just be noise. |
|
|
|
Is it just me, or are stales going steadily up? I was at .3% stales, then it went up to .5%, and now I am at .8%. At what point should I start to get concerned?
stales look about normal to a tiny bit higher for me. 0.13% last 15 hours or so. Totals 7,630.73 MH/s 112020 (148, 0.13%) 2042092 (13341, 0.65%) Yeah, I am just the slightest bit higher as well perhaps. But well under most other pools. |
|
|
|
|
I am waiting to see the pictures. I am from DC, which is a bit far, but if I am interested, perhaps we can meet in the middle.
|
|
|
|
|
How many left, just out of curiosity?
|
|
|
|
|
Show Posts
