DT - Sorry the question was for Meni Rosenfeld, who designed PPLNS.
I did not invent PPLNS. (I did design some of its more accurate, largely unused variants though). Choosing PPS over PPLNS as a backup pool for hopping has no effect on expected return (assuming equal fees etc.). It does decrease payout variance, but whether this is significant is entirely up to the miner who needs to valuate what variance means to him. Variance is a thing, but it's not boolean - going with PPLNS over solo already can eliminate about 99.9% of solo variance (just for the parts when this pool is used; depends on pool's and miner's size), so eliminating what remains with PPS is generally not very significant, but preferable all else being equal. |
|
|
|
OK, I think it's a bit more clear. Variance is insane if you delve this deep. My brain doesn't enjoy comprehending this stuff. Now I don't understand why pools have score based or pplns systems if they don't change anything, nor do I understand how pool hopping could be profitable. You don't need to respond, this is something I should research myself if I truly want to understand.
Maybe you will be interested in Analysis of Bitcoin Pooled Mining Reward Systems. |
|
|
|
P4, hate to say it but you don't have a clear understanding of hopping, either. Where does a hopper go if they can't mine a prop pool from start to 43.5% (47%?)? Is that a question? Well doh, you go to any PPS or hop proof pool and make 100% PPS like anyone else mining there, until you get another opportunity to hop prop pools. Doh. The theoretical best you can do is 128%, If you only hope ONE pool. Really, prove it! What happens if you hop more than one? School me? Think about opportunity cost and the current universe of prop pools, not including Score. (oh and how do you determine that hop point?). Make sure to address that in your elaborate proof. , Appendix B (Pool-hopping in proportional pools). There's no limit to how much you can gain under the right conditions. By the way, "anti-hopping measures" by bitcoinpool et al are a joke. Deepbit's stats hiding isn't that effective either. |
|
|
|
Why would one switch between pools? If all pools were hop proof, there would be no reason for anyone to switch. Your argument also applies to any pool that has share decay. Slush for example. You do understand these rules are put in place to deter hopping, which is harmful to the constant miners?
No, his argument doesn't apply to either. There is no penalty for switching pools when using a hopping-proof method. I'm not sure I understand. If you mine at a pool that has decaying shares, and you stop, there is a chance you will not be paid for those shares at all. Which is the point. I would say that is a penalty. I believe at slush's pool it happens very fast (maybe they don't decay, but become worthless, and perhaps this has changed, I haven't mined at slush's in quite some time). With P2Pool it can take 24 hours, I think. If you stay in the pool there is the same chance that you will not get paid for the past shares. If there are several hopping-proof pools, and you roam between them freely, your average reward, and accordingly the reward over a long period of time, will be the same as if you have mined for a single pool. |
|
|
|
P2Pool can scale just fine. Once it gets to a point where the variance for P2Pool shares are too high for small miners, we can start a second P2Pool. There is also talk of small P2Pools that connect to larger P2Pools to address this, although I don't know how viable this is. But if you start a second p2pool, each instance will have a low hashrate and thus higher variance than a large centralized pool. The solution could be small centralized PPS proxy pools which connect to a large p2pool. Why would one switch between pools? If all pools were hop proof, there would be no reason for anyone to switch. Your argument also applies to any pool that has share decay. Slush for example. You do understand these rules are put in place to deter hopping, which is harmful to the constant miners?
No, his argument doesn't apply to either. There is no penalty for switching pools when using a hopping-proof method. |
|
|
|
The first chart shows a clear peak in pool hashrate for rounds about 274000 shares total, after which there is a gradual decline in average hashrate. The trend is fairly clear even with this very limited dataset. This is interesting since that's about the current hop point, which can be calculated as follows:
This peak makes no sense. Either hoppers are behaving in a very weird way, or the apparent climb to ~270000 shares is the result of sampling error. |
|
|
|
Yeah, 40% = average shares.
Is luck the percentile? ( exp (-shares/difficulty)) If so then shares = difficulty (which is the average shares) is 36.8% luck. But 36.8% is not average luck. If you take the different luck values and calculate the average, it should be 50%. |
|
|
|
you are still misquoting me in order to make your point... I was refering to THE math formula that would be in affect for x hasrate on prop and nothing else.
You are still falsely accusing me of things. The formula for what? For expected reward? For variance? For the probability that you will get more than 5 BTC reward in a block? For when there are no hoppers? For when everyone else are hoppers? I'll assume you meant "the formula for expected payout per share in a proportional pool when there are no hoppers". Yeah, this one doesn't change according to your hashrate. If you clarify what it is you want, we can find a formula for that. |
|
|
|
I question the wisdom of using sites like firstbits.com or encouraging people to focus on one's vanity address. We don't know much about who runs the site, first of all, which would allow them to change the addresses, or if their security practices are poor, to do that. A vanity address generator can easily generate a new address with the same short prefix as an existing one (such as BurtW), if you expect people to check the firstbits scheme closely enough to notice if there's a completely unrelated address on there.
I expect it's not actually that dangerous, but given how easy it is for me to generate another address starting in BurtW, I think we run the risk of people starting to assume (for no good reason) that if an address is recognizable, it must belong to the person mentioned in the vanity address.
We know that he has been in this community for over a year and a half, with over 4000 posts. That should count for something. Also, Firstbits follows a deterministic algorithm (with the blockchain as input), 1burtw will always map to 1BurtWEejbnKeBRsvcydJvsNztB1bXV5iQ. You can have Firstbits clones if you don't want to trust one particular server to do the computation. I don't think there's danger in that, as long as we make it clear that you need to use the actual firstbits expansion, not just any address with the same prefix. |
|
|
|
I really wonder why would Gavin visit the CIA? What interest would the CIA have in Gavin and Bitcoin? It just sounds so strange to me.
You have 28 pages of discussion spanned over 9 months to satisfy your curiosity. |
|
|
|
And, the choice between PPLNS and PPS has nothing at all to do with your own hashrate
I agree with everything but this. Ony in that you misquoted me. It was not pplns verse pps. It was Prop verse pps. And the reason for only really wanting to do it with atleast x amount of hash rate is just that for me the 'difficulty/luck gambling' is not worth it if I only have .1%(as example) of total hash power. Because on lucky rounds, which is what I'd be gambling for, my take would not be enough to make it worth the risk on long rounds. I know the math formula does not change for having more hash rate but on extremely short rounds, the variance time in individual shares combined with a low hash rate adds up. I've tested it before hopping was cool. Derek I referred to PPLNS because proportional is indefensible, and I wanted to give a comparison regarding the gambling aspect between two valid options. There's no "the math formula". Different things have different formulas. You are entitled to wanting a gambling aspects to your mining, and you can have formulas for what your bet will look like. But based on your other posts I think you are confused about how your hashrate affects your mining prospects. In particular, note that if your hashrate is low, the chance that you will not submit any shares in a short round and thus miss out on a jackpot, is completely offset by the fact that you could find more shares than average in a short round and win an even bigger jackpot. There is no reduction in expected payout per share for having low hashrate, only higher variance (which you might consider good if you like gambling). |
|
|
|
I'm probably going to switch to pplns. I was thinking about making n= 1/2 of the difficulty, or is that the high for n.
I didn't post anything in this thread so far, because I thought the OP here was pretty forthcoming and I didn't want to give you a hard time. But... Seriously? You start one pool with proportional. Everyone tells you that's wrong. You switch to PPLNS. You start another pool with proportional. Everyone tells you that's wrong. You say you've learned from your mistakes from the first pool and stand behind your decision for proportional. And now you switch to PPLNS again? WTF? PPS, PPLNS, SMPPS = guaranteed hop proof AND doesn't punish miners who disconnect.
SMPPS is not hopping-proof, and it has very serious problems regardless of whether one calls it hopping-proof or not. I'm obviously of the DGM persuasion and I know very little beyond the basics of PPLNS. I know Meni has done the math behind it and supports it as a valid, non-hoppable variety of payout schemes. As such, I trust his judgement in those matters far beyond my own.
PPLNS is probably a lot easier to implement than DGM I would imagine.
I should point out that that PPLNS has several variants, the naive variant which is what people usually refer to is approximately hopping-proof, but not completely. The hopping-proof variant I stand behind is what I call unit-PPLNS, which I think might be nontrivial to implement. Another good variant is shift-PPLNS, which can be made hopping-proof without too much trouble, and is suitable for a parallel architecture. But even the naive variant is much, much better than proportional. Right, so it would be fine for DGM to use a $block_reward = 40 instead of 50...
But now that I think about it, even if you changed the block reward it wouldn't matter. The score is independent of the block reward, it just divides up whatever you feed it as the reward appropriately, according to contribution.
I don't know how it's currently implemented in EMC but the accurate implementation is to use the block reward when calculating the score to award a worker for a submitted share. You can set block reward to 40 and hand out the rest in some other way. It's possible to change the jackpot value but you need to sum it up correctly. Actually, I would prefer Prop. If it were not for the hopping thing, you have that little gambling itch covered where finding blocks quick, pays better.... I would probably only do that if I had 5GH+ at present dif though.
Hopping-proof methods like DGM and PPLNS depend on the pool's luck, so you can have your gambling cravings satisfied. And, the choice between PPLNS and PPS has nothing at all to do with your own hashrate - variance in PPLNS depends on the pool's hashrate, not your own. Attempts to patch proportional by penalizing disconnections do not work. They do very little against hoppers, and can punish honest miners. |
|
|
|
And for those of you following the BIP16/17 debate, against my better judgement I upgraded the bitcoind's to the latest mainline git, and for the past several days, it's been basically destroying all the transaction fees, so they went poof. This is why I was and still am totally NOT in support of BIP 16 because of the timeline involved. It's a perfect example of why a less than 4 week timeline for a change of this magnitude is not viable. Fortunately, Luke alerted me to the problem today and I reverted to an earlier rev.
Gavin has pledged to personally reimburse all lost transaction fees and quickly fix the problem (he may or may not have done this already). |
|
|
|
1) Has anyone ever made some kind of percentile graph of the big pools (like deepbit, etc.) ?
slush has this for his pool here, I'm sure there are graphs for other pools as well. 2) Is there a max. time (or better max. number of operations) until a block will be found for sure (100%). Or could it happen that the time to mine one specific, nasty block could be millions of years?
There is no such max time. A block could theoretically take millions of years, the probability for that is positive though unbelievably tiny. The probability that a block will take at least N shares is roughly exp(-N/D) (where D is the difficulty). |
|
|
|
i think √(a*b) = √a * √b should still work with complex numbers, but the restrictions are more complicated.
With real number you restrict yourself to a positive solution, with complex numbers you will have to mess with dividing the complex plane or something like that.
Any single-valued inverse of the square function has a branch cut, and for the principal square root function the branch cut is placed on the negative real axis. When multiplying two numbers you have no guarantee of remaining on the same branch. If you treat it as a multivalued function you can have √(a*b) = √a * √b, but then you don't have -1*-1 = 1. (-1 = e^(i pi) and -1*-1 = e^(2i pi), which is different on this Riemann surface from 1). |
|
|
|
its a problem of notation
when you write sqrt(1) it is accepted that you mean the positive root
but there is a negative root as well (-1)*(-1)=1 -> sqrt(1)=+/-1
similarly sqrt(-1)=-/+i
That's not where the problem is. 1 has two square roots but the notation √1 refers to the positive one. Similarly √(-1) = i. The problem is that the rule √(a*b) = √a * √b simply does not apply when complex numbers are involved, any more than the rule x^2 >= 0 applies for complex numbers. The error in the derivation is the step √(-1 * -1) = √-1 * √-1. Of course, you still do have that √(a*b) is equal to either √a * √b or -(√a * √b). |
|
|
|
2. Verified Status (Level 1)
Copy of a Valid ID and Proof of residence (Utility bill...)
Do I understand correctly that "verified" status does not require an apostille? The original post in this thread made it seem like the new requirements apply also for "verified", which I think is what most of the negative reaction came from. For the kind of company that requires "trusted" status, the trouble of getting an apostille is trivial. You are correct, the Level 1 does not required an apostille. Our first announcement was actually more targeted for Level 2, sorry for the confusion By the way, I think the clarifications you have made throughout this thread are important, and should be visible in a more prominent location, such as the OP. Not everyone is going to wade through several pages of discussion. |
|
|
|
wow yochdog found 2 blocks in a row #164048(433) and 25 minutes later #164050(434) wat are the chances
I'm going to pretend this wasn't a rhetorical question. Given a block, the chance that it will be found by the same miner as the previous block is the sum of squares of each miner's hashrate, divided by the square of the pool's total hashrate. Extrapolating from the data available about top miners I estimate the former to be about 5700 (Gh/s)^2, so the probability is 5700 / 500^2 ~ 2.3%. If the pool finds on average 7 blocks per day, then the chance there will be an occurrence of this event (two blocks in a row by the same miner) in a day is very roughly 7 times that, which is 16%. |
|
|
|
2. Verified Status (Level 1)
Copy of a Valid ID and Proof of residence (Utility bill...)
Do I understand correctly that "verified" status does not require an apostille? The original post in this thread made it seem like the new requirements apply also for "verified", which I think is what most of the negative reaction came from. For the kind of company that requires "trusted" status, the trouble of getting an apostille is trivial. |
|
|
|
|
Show Posts
