[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[smooth]

BTW it's kinda a bummer the max share chain is only 3 days. The SPREAD is 3 blocks worth of work, so that would normally mean any share someone finds should get one or more payouts. Is the reason we have a max share chain length at all to prevent abuse? I'd think the share chain should expand as much as needed automatically to store SPREAD worth of payouts...

If you pay shares on every single block you have proportional payout (subject to pool hopping abuse), not PPLNS.

[1714145377]

1714145377

[1714145377]

1714145377

[smooth]

Oh, but you're forgetting... There is some way to flip a switch. Not quite tomorrow, but hopefully soon enough....

A development project in progress is not "flipping a switch."

[forrestv]

Oh, but you're forgetting... There is some way to flip a switch. Not quite tomorrow, but hopefully soon enough....

A development project in progress is not "flipping a switch."

Eventually, as a result of development, there will be a switch to flip.

[smooth]

Oh, but you're forgetting... There is some way to flip a switch. Not quite tomorrow, but hopefully soon enough....

A development project in progress is not "flipping a switch."

Eventually, as a result of development, there will be a switch to flip.

Thank you for your efforts. One question I would ask is what work is being done to make p2pool more attractive to large miners. That is the real solution here. More blocks helps everyone.

[organofcorti]

No. It's not 'noticed because someone is looking for it' (which is what I think you meant with your analogy?). It is noticed because the 95% confidence interval for income as a fraction of expected income is much wider for lower hashrates than for higher hashrates.

Yes, as a fraction of expected income but ask yourself why that even matters. If you expect to get 0.003 BTC and you get 0.002 BTC (or even in one instance 0 BTC for that matter) how is your life impacted in some major way?

Of course it matters. It matters to people who are hobby miners who try to optimise their equipment. It's hard to optmise if you only see a share every few days.

You're also assuming everyone is a hobby miner with no concern for profit. Just because someone can only afford a low hashrate miner doesn't mean they can treat the investment as a "hobby cost". Lots of countries are poorer than the US.

Daily variance does not reduce your profit.

Only true over long periods of time. The greater the variance, the longer the time. You could have much more than expected for a long time. But then you could have much less than expected for a long time.

People are constantly on here talking about how pools with significant fees are "better" for small miners. That is false. In fact they reduce profit.

I have no opinion on the matter. Giving it some thought though, I think if you have such a low hashrate that you can't be sure you have optimal settings for your miner, then you may need to mine at a larger pool just to see if your optimisations have worked.

Even in the case of looking at mining as a "paycheck" most people getting actual paychecks get paid once a week or every two weeks. Looking at your earnings every single day and expecting them to be some nice flat number every single day is stupid and counterproductive.

I don't know that anyone is arguing that they expect the same amount every day. However, your paycheck is the same each fortnight. If you only receive one payment a fortnight from mining, I can guarantee it will vary significantly each fortnight.

To be clear: I am not arguing that p2Pool should be made more minable by smaller miners. I am explaining to you how CDFs vary significantly for different hashrates. Someone with a large hashrate might see a +/- 1% variation in earnings per week. Someone with a small hashrate might see earnings change to 0.01% or 1000% of the previous week's earnings. I think you're not understanding how significant that is.

[irrational]

this:

Daily variance does not reduce your profit.

Only true over long periods of time. The greater the variance, the longer the time.

and:

Even in the case of looking at mining as a "paycheck" most people getting actual paychecks get paid once a week or every two weeks. Looking at your earnings every single day and expecting them to be some nice flat number every single day is stupid and counterproductive.

I don't know that anyone is arguing that they expect the same amount every day. However, your paycheck is the same each fortnight. If you only receive one payment a fortnight from mining, I can guarantee it will very significantly each fortnight.

To be clear: I am not arguing that p2Pool should be made more minable by smaller miners. I am explaining to you how CDFs vary significantly for different hashrates. Someone with a large hashrate might see a +/- 1% variation in earnings per week. Someone with a small hashrate might see earnings change to 0.01% or 1000% of the previous week's earnings. I think you're not understanding how significant that is.

To tie the second bolded text back into your first bolded text, it's not so much the +/- swing, it's that with smaller hash rates you're "rolling the dice" less often, and thusly (as you alluded to in the first bolded text) might not levelize for a VERY long period of time.

I'm sure you knew that, but since they were separated in your post I figured I'd point that out in case others didn't pick up on that.

[roy7]

BTW it's kinda a bummer the max share chain is only 3 days. The SPREAD is 3 blocks worth of work, so that would normally mean any share someone finds should get one or more payouts. Is the reason we have a max share chain length at all to prevent abuse? I'd think the share chain should expand as much as needed automatically to store SPREAD worth of payouts...

If you pay shares on every single block you have proportional payout (subject to pool hopping abuse), not PPLNS.

I think you didn't understand my point. If the window (N) for PPLNS is large enough then shares should get paid on every block as well. That doesn't make it the proportional. The problem right now is the share window is shorter than the time to find a block, so some shares don't get any payments at all, in spite of SPREAD being set to 3. (That is, the payment window is 3 * difficulty.) As I understand it, the share chain length overrides the spread, so the payment window will fluctuate based on however much work fits in the share chain instead of the most recent N.

[smooth]

I have no opinion on the matter. Giving it some thought though, I think if you have such a low hashrate that you can't be sure you have optimal settings for your miner, then you may need to mine at a larger pool just to see if your optimisations have worked.

If you are mining on a public node, you can measure how well you have "optimized" your miner using the pseudo-shares (reported by your miner) and the overall efficiency of the public node. There is no real difference between pseudo-shares and real shares from the point of view of an external miner using a public node (other than a difficulty of course).

If you are trying to optimize your own p2pool node with a tiny hash rate, you are certainly not doing it to maximize return on investment, because you can't possibly justify the cost a p2pool node (and full bitcoin node) for a tiny hash rate on an objective basis.

[organofcorti]

To tie the second bolded text back into your first bolded text, it's not so much the +/- swing, it's that with smaller hash rates you're "rolling the dice" less often, and thusly (as you alluded to in the first bolded text) might not levelize for a VERY long period of time.

I'm sure you knew that, but since they were separated in your post I figured I'd point that out in case others didn't pick up on that.

Sure. If you take an extreme case, you can show that as long as difficulty doesn't ever drop below current difficulty, it's more likely that mining at a pool will return any amount of reward compared to mining solo - if the income chunks are large enough, one chunk may be greater than the expected earning of the small hashrate miner. In this case, it would be more probable than any amount of bitcoin could be earned at pooled mining than solo.

This reductio ab adsurdum also applies to p2Pool, but to a much lesser extent.

[smooth]

BTW it's kinda a bummer the max share chain is only 3 days. The SPREAD is 3 blocks worth of work, so that would normally mean any share someone finds should get one or more payouts. Is the reason we have a max share chain length at all to prevent abuse? I'd think the share chain should expand as much as needed automatically to store SPREAD worth of payouts...

If you pay shares on every single block you have proportional payout (subject to pool hopping abuse), not PPLNS.

I think you didn't understand my point. If the window (N) for PPLNS is large enough then shares should get paid on every block as well. That doesn't make it the proportional. The problem right now is the share window is shorter than the time to find a block, so some shares don't get any payments at all, in spite of SPREAD being set to 3. (That is, the payment window is 3 * difficulty.) As I understand it, the share chain length overrides the spread, so the payment window will fluctuate based on however much work fits in the share chain instead of the most recent N.

There is no length that is necessarily guaranteed to be long enough. If you are saying to extend the chain until blocks are found, that is exactly what proportional payout does.

If you are just suggesting to extend the chain to some other fixed length like 7 days or 30 days or something else, that is another story, with its own tradeoffs. For example, even people with large hash rates will see very small payouts for a long time when first starting.

Even 7 days probably won't be long enough soon.

[smooth]

To be clear: I am not arguing that p2Pool should be made more minable by smaller miners. I am explaining to you how CDFs vary significantly for different hashrates. Someone with a large hashrate might see a +/- 1% variation in earnings per week. Someone with a small hashrate might see earnings change to 0.01% or 1000% of the previous week's earnings. I think you're not understanding how significant that is.

It's significant only insofar as people make it out to be significant. If a hobby miner's earnings vary from $10 to $0, that might well be less significant than a larger scale miner whose earnings drop from $5000 to $4000 but who spent many thousands of dollars on mining gear and has an electricity bill of hundreds or thousands of dollars per month. A $10 shortfall is a $10 shortfall, and can't ever make more than a $10 difference. You can't change that at putting some scary percentage number on it.

In any case, as I suggested earlier, the focus on very small miners is misguided. What p2pool needs is more large miners. Adding a few thousand 5 GH miners won't make any real difference. Getting KnC or whoever that was to mine their 1000 TH on p2pool instead of eligius changes the whole picture.

[organofcorti]

BTW it's kinda a bummer the max share chain is only 3 days. The SPREAD is 3 blocks worth of work, so that would normally mean any share someone finds should get one or more payouts. Is the reason we have a max share chain length at all to prevent abuse? I'd think the share chain should expand as much as needed automatically to store SPREAD worth of payouts...

If you pay shares on every single block you have proportional payout (subject to pool hopping abuse), not PPLNS.

I think you didn't understand my point. If the window (N) for PPLNS is large enough then shares should get paid on every block as well. That doesn't make it the proportional. The problem right now is the share window is shorter than the time to find a block, so some shares don't get any payments at all, in spite of SPREAD being set to 3. (That is, the payment window is 3 * difficulty.) As I understand it, the share chain length overrides the spread, so the payment window will fluctuate based on however much work fits in the share chain instead of the most recent N.

There is no length that is necessarily guaranteed to be long enough. If you are saying to extend the chain until blocks are found, that is exactly what proportional payout does.

If you are just suggesting to extend the chain to some other fixed length like 7 days or 30 days or something else, that is another story, with its own tradeoffs. For example, even people with large hash rates will see very small payouts for a long time when first starting.

Even 7 days probably won't be long enough soon.

Time based PPLNS is a bit unstable. It's a variance vs time-to-maturity trade-off. If p2Pool's PPLNS was only share based, then you'd see consistent variance in total earned, but a varying time to maturity (how long it take a share to leave the PPLNS window).

[roy7]

There is no length that is necessarily guaranteed to be long enough. If you are saying to extend the chain until blocks are found, that is exactly what proportional payout does.

If you are just suggesting to extend the chain to some other fixed length like 7 days or 30 days or something else, that is another story, with its own tradeoffs. For example, even people with large hash rates will see very small payouts for a long time when first starting.

Even 7 days probably won't be long enough soon.

I'm saying let the sharechain grow as large as needed to hold the full PPLNS window size, like all normal PPLNS pools do.

I'm not sure if I'm doing the math right here, but -ln(1.0 - .95) = about 3. So 95% of all blocks should be found within 3 * difficulty shares worth of work. That is, only 5% of shares should result in no payment at all. organofcorti please chime in if I did this wrong.

But if the share chain is capped at 3 days worth of shares regardless of the difficulty of finding a block and regardless of the amount of work stored in the chain, instead of always at N = 3 * difficulty, then the size of N for the PPLNS payment window shrinks and the % of shares resulting in no payment goes up. This doesn't happen in traditional PPLNS pools, N remains fixed and the % from above remains fixed.

Caveat: I don't know the inner workings of how p2pool juggles the share chain size and spread variables to come up with it's minimum share target difficulties.

[roy7]

In any case, as I suggested earlier, the focus on very small miners is misguided. What p2pool needs is more large miners. Adding a few thousand 5 GH miners won't make any real difference. Getting KnC or whoever that was to mine their 1000 TH on p2pool instead of eligius changes the whole picture.

p2pool already works well with large miners. Cointerra's products work wonderfully with it. It isn't a technical challenge, it's a marketing/advertising/perception one. Why don't the bulk of CT users mine with p2pool instead of some other pool? That's the question. If I owned a huge farm, using p2pool would be an automatic choice.

[smooth]

p2pool already works well with large miners. Cointerra's products work wonderfully with it. It isn't a technical challenge, it's a marketing/advertising/perception one.

Yes that is the question. I'm not sure you can flat out dismiss "technical" concerns. Maybe things like graphs and so forth are important. There may be other feature issues. For example, I know a few people have mentioned automatic splitting of payouts for farms with investors and group buys as being an attractive feature of ghash.io. I'm personally using the fee function in p2pool for that, but that only gives a two-way split, and it means I can't really open up my node for public use, which I might otherwise do. (There are no public nodes in my geographic area as far as I can tell.) Marketing and awareness are also important of course.

[roy7]

Yes that is the question. I'm not sure you can flat out dismiss "technical" concerns. Maybe things like graphs and so forth are important. There may be other feature issues. For example, I know a few people have mentioned automatic splitting of payouts for farms with investors and group buys as being an attractive feature of ghash.io. I'm personally using the fee function in p2pool for that, but that only gives a two-way split. Marketing and awareness are also important of course.

I chatted with someone on #p2pool once who did a probabilistic payout model for a group of people who mined with him on his private node. That's more random for the people you are paying than if you collect the coins yourself and then pay them evenly. But of course that does open yourself up to wallet theft, etc. I'm a big fan of paying directly to people and not holding coins whenever possible.

So for example, if you had 10 investors who own 10% each of the pool, then you wouldn't use the incoming miner addresses at all. You'd customize the payout code so each of those addresses had a 10% chance of being chosen as the one going into the p2pool share chain (like the way fees work). The problem is if investors get upset than investor A is being paid more than B, since it's random. A more advanced approach could record the payments actually paid out to the investors on the blockchain to their group buy addresses, and mine to the investor address who has received the least payments. Sort of a payment round robin approach, so one investor can't get too far ahead of another due to randomness. (Adjusted as needed of course if miners don't have equal ownership stakes.)

So someone in your example might find that useful. But it'd be easy enough to code without needing it as an official function for everyone.

Edit: I'm always trying to think of ways to run p2pool public nodes profitably. The proxy pool project is pretty cool and I ported that to vertcoin but didn't make a payment backend system yet. However your comment about farms/group buys wanting a feature to break out their payments in arbitrary ways more complex than just 'everything to this address' could be a value added feature worth implementing.

[smooth]

Yes that is the question. I'm not sure you can flat out dismiss "technical" concerns. Maybe things like graphs and so forth are important. There may be other feature issues. For example, I know a few people have mentioned automatic splitting of payouts for farms with investors and group buys as being an attractive feature of ghash.io. I'm personally using the fee function in p2pool for that, but that only gives a two-way split. Marketing and awareness are also important of course.

I chatted with someone on #p2pool once who did a probabilistic payout model. That's more random for the people you are paying than if you collect the coins yourself and then pay them evenly. But of course that does open yourself up to wallet theft, etc. I'm a big fan of paying directly to people and not holding coins whenever possible.

Yes it is added variance. This is accepted in understood by the participants in my case. In practice the payouts seem to be fairly close (it is shares that are being split probabilistically and over the payment window the number of shares is fairly large). As you said it reduces the changes of wallets being compromised and other problems.

I don't really agree that "you could code it yourself" is a good answer to a missing function that could attract more miners. I obviously don't know how many miners this particular function would attract.

[roy7]

Yes it is added variance. This is accepted in understood by the participants in my case. In practice the payouts seem to be fairly close (it is shares that are being split probabilistically and over the payment window the number of shares is fairly large). As you said it reduces the changes of wallets being compromised and other problems.

Were you the one I chatted with about it on #p2pool? It's been long enough I don't recall who it was now.

[smooth]

Yes it is added variance. This is accepted in understood by the participants in my case. In practice the payouts seem to be fairly close (it is shares that are being split probabilistically and over the payment window the number of shares is fairly large). As you said it reduces the changes of wallets being compromised and other problems.

Were you the one I chatted with about it on #p2pool? It's been long enough I don't recall who it was now.

No not me. I'm only splitting two ways so the fee function works for that. I did consider at one point that if I needed to split more ways I would find the fee function (random split) in the code and modify it, but I haven't needed it yet.

[organofcorti]

To be clear: I am not arguing that p2Pool should be made more minable by smaller miners. I am explaining to you how CDFs vary significantly for different hashrates. Someone with a large hashrate might see a +/- 1% variation in earnings per week. Someone with a small hashrate might see earnings change to 0.01% or 1000% of the previous week's earnings. I think you're not understanding how significant that is.

It's significant only insofar as people make it out to be significant. If a hobby miner's earnings vary from $10 to $0, that might well be less significant than a larger scale miner whose earnings drop from $5000 to $4000 but who spent many thousands of dollars on mining gear and has an electricity bill of hundreds or thousands of dollars per month. A $10 shortfall is a $10 shortfall, and can't ever make more than a $10 difference. You can't change that at putting some scary percentage number on it.

In any case, as I suggested earlier, the focus on very small miners is misguided. What p2pool needs is more large miners. Adding a few thousand 5 GH miners won't make any real difference. Getting KnC or whoever that was to mine their 1000 TH on p2pool instead of eligius changes the whole picture.

I'm not following, bud. Are you going off on a tangent here? Or maybe what you address in this post isn't really my concern? I'm not saying it's bad, or wrong, just not my concern.

Either way I'm fine with that, but I want to be certain you weren't still discussing the difference between large and small miner variance.

In case you are, or in case there are other readers as confused as I, you can think about it like this: the number of p2Pool shares a miner submits per time period is an approximately Poisson distributed random number. This means that the standard deviation of this number is proportional to the square root of the mean. As the share submission rate increases, the standard deviation only increases as the square root of the mean, so a miner with a greater share submission rates has, proportionally, a much lower standard deviation.