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

[Subo1977]

Block ETA is now 19hrs and rising, when we go over 24hrs (pool rate under 200GH) mining will become totally unprofitable...
We need more power!

That would be difficult.

If I'm new to p2pool and i see something like this:
Pool Hashrate: 267.3 GH/sEstimated Time to Block: 19h29m Current Round: 1d11h5m

Pool L* (7 days, 30 days, 90 days): 50.4% 77.1% 90.1%

Why should i point my GH's to p2pool? at this time every share count and  every PPS Pool is better at this moment.

Why goes the L* so drastical down this time?   

[organofcorti]

Block ETA is now 19hrs and rising, when we go over 24hrs (pool rate under 200GH) mining will become totally unprofitable...
We need more power!

That would be difficult.

If I'm new to p2pool and i see something like this:
Pool Hashrate: 267.3 GH/sEstimated Time to Block: 19h29m Current Round: 1d11h5m

Pool L* (7 days, 30 days, 90 days): 50.4% 77.1% 90.1%

Why should i point my GH's to p2pool? at this time every share count and  every PPS Pool is better at this moment.

Why goes the L* so drastical down this time?   

Variance is always higher when a pool's hashrate is a smaller proportion of the network's hashrate. p2Pool is just as likely to be extremely lucky.

[K1773R]

the PPLNS system should be changed to the last 7 days.

[lenny_]

the PPLNS system should be changed to the last 7 days.

Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money.
I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners.

[organofcorti]

the PPLNS system should be changed to the last 7 days.

Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money.
I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners.

This is why PPLNS should always be in terms of the last n shares, not time. Difficulty and pool hashrate do not have an effect on the score variance if there is no termporal term in the scoring function.

[K1773R]

the PPLNS system should be changed to the last 7 days.

Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money.
I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners.

seems fine

[K1773R]

the PPLNS system should be changed to the last 7 days.

Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money.
I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners.

This is why PPLNS should always be in terms of the last n shares, not time. Difficulty and pool hashrate do not have an effect on the score variance if there is no termporal term in the scoring function.

then rephrase it, set the PPLNS number so its rougly 7 days

[organofcorti]

the PPLNS system should be changed to the last 7 days.

Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money.
I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners.

This is why PPLNS should always be in terms of the last n shares, not time. Difficulty and pool hashrate do not have an effect on the score variance if there is no termporal term in the scoring function.

then rephrase it, set the PPLNS number so its rougly 7 days

I know what you mean, and it would help in the short term. But id n was set to (for example) 2 x current Difficulty, then you'd never have to change it. The PPLNS shouldn't be any number of days.

What would happen if the pool's percentage of the hashrate increased significantly? You'd want to change the number of days back down in order to reduce the time it took to recieve payment.

[K1773R]

the PPLNS system should be changed to the last 7 days.

Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money.
I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners.

This is why PPLNS should always be in terms of the last n shares, not time. Difficulty and pool hashrate do not have an effect on the score variance if there is no termporal term in the scoring function.

then rephrase it, set the PPLNS number so its rougly 7 days

I know what you mean, and it would help in the short term. But id n was set to (for example) 2 x current Difficulty, then you'd never have to change it. The PPLNS shouldn't be any number of days.

What would happen if the pool's percentage of the hashrate increased significantly? You'd want to change the number of days back down in order to reduce the time it took to recieve payment.

increasing it to a longer N would also help little miners, if they get a share and there is no block found they get nothing and are pissed, i saw that already some times.

[organofcorti]

the PPLNS system should be changed to the last 7 days.

Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money.
I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners.

This is why PPLNS should always be in terms of the last n shares, not time. Difficulty and pool hashrate do not have an effect on the score variance if there is no termporal term in the scoring function.

then rephrase it, set the PPLNS number so its rougly 7 days

I know what you mean, and it would help in the short term. But id n was set to (for example) 2 x current Difficulty, then you'd never have to change it. The PPLNS shouldn't be any number of days.

What would happen if the pool's percentage of the hashrate increased significantly? You'd want to change the number of days back down in order to reduce the time it took to recieve payment.

increasing it to a longer N would also help little miners, if they get a share and there is no block found they get nothing and are pissed, i saw that already some times.

It might seem unfair, but on average it makes no difference. Smaller miners will experience variance more on this pool especially since the share difficulty is so high for them.

PPLNS set to shares rather than hours will result in reduced variance for all miners.

[K1773R]

yes but if the PPLNS N is changed that it is around 7 days (according to the diff rules of p2pool), then its not day nor time based.

[organofcorti]

yes but if the PPLNS N is changed that it is around 7 days (according to the diff rules of p2pool), then its not day nor time based.

You mean set n to ~ 9 x Difficulty? (that's seven days shares at the moment)

[K1773R]

yes but if the PPLNS N is changed that it is around 7 days (according to the diff rules of p2pool), then its not day nor time based.

You mean set n to ~ 9 x Difficulty? (that's seven days shares at the moment)

something like this yes, but we would have to test it first since it means holding a bigger sharechain -> more memory/traffic being used

[rav3n_pl]

Not necessary bigger share chain, if we put higher diff and longer long pool share chain can be same length aka consume same memory.
Make it 5 days long and 50sec longpool. It will be the same like it is now. Diff of next share need to be calculated every share from last 10/20 shares.

[lenny_]

Good idea. It will be exactly same as it is now, but 5x greater chance to have block and payout within 5 days, especially matter for small miners. And LP 50sec will greatly decrease orphan+DOA ratio. Right now there is no point to mine on p2pool unless: we have GPU only with low intensity + we have fast CPU + fast Internet and local node on it. I tried remote nodes with many configurations, with GPUs, many FPGAs, result was always tragic.

[gyverlb]

Note that if you change the target time between share and don't change N in PPLNS you won't change variance at all (the difficulty will rise in the same proportions than the time covered by the PPLNS window) : you will only make payments increase slower when someone begins mining on P2Pool (which is not a big selling point) and decrease slower when it stops (better, but people want instant gratification not promises for the future).

If you make N bigger, variance in mining rewards won't be as high for small miners but it won't change much for people with 10+GH/s as their variance for payment amounts is already low. The variance due to the low global hashrate can't be solved by tuning N or time between shares but only with more hashrate. Several Avalon customers (myself included) have stated that they will run them on P2Pool, so this problem should go away in the following months if Avalon delivers.

If N is bigger this will probably have some CPU/disk costs too.

A solution to make p2pool more friendly for small miners might be to automatically adjust a miner's difficulty according to the aggregated hashrate of the Bitcoin address it works for. The difficulty would be set to keep share submission around an healthy rate (always higher than the minimum difficulty set by the current P2Pool global hashrate and around a level where variance in payment amounts is considered acceptable if its higher than the minimum). In a later hardfork of the sharechain P2Pool could even enforce a limitation on the number of shares for each payment address in the PPLNS window to make sure a big miner can't circumvent this and take all the place in the sharechain.

There's already code supporting arbitrary high share difficulty for big miners but it's only used on a voluntary basis. I hope its not difficult to implement automatic difficulty change on top of it: this might help attract more small miners (it seems the most of the big ones are still here) by lowering the difficulty they would get on P2Pool.

[gyverlb]

Good idea. It will be exactly same as it is now, but 5x greater chance to have block and payout within 5 days

If you are reacting to rav2n_pl post just before yours, I think you are mistaken. Read my previous post: if N remains the same in the PPLNS system payment amounts variance will not change unless big miners leave more place in the sharechain by using a greater difficulty than small miners.

, especially matter for small miners. And LP 50sec will greatly decrease orphan+DOA ratio. Right now there is no point to mine on p2pool unless: we have GPU only with low intensity + we have fast CPU + fast Internet and local node on it. I tried remote nodes with many configurations, with GPUs, many FPGAs, result was always tragic.

The only FPGAs having problems are the ones from BFL in Singles and early Minirigs, I have 16 Spartan6 and don't have any problem on P2Pool with them. But you are right for a local node: P2Pool efficiency takes a hit (although a small one if you have good QoS settings) when you use a high latency connection between the miners and the P2Pool node.

[lenny_]

I don't care about variance. I am patient (wise?) enough, to not follow "luck" drama.
I tried Icarus, CM1 and Ztex on remote nodes - result was 10-15% doa/orphan. Absolutely not acceptable. On local p2pool indeed I have nice results, but I cannot afford to run another spare computer 24/7 with Phenom II onboard just to get bitcoind latency lower. I just want to mine on remote nodes like I do with any other central pool. Increasing difficulty is only one solution for this.

[gyverlb]

I don't care about variance. I am patient (wise?) enough, to not follow "luck" drama.
I tried Icarus, CM1 and Ztex on remote nodes - result was 10-15% doa/orphan. Absolutely not acceptable. On local p2pool indeed I have nice results, but I cannot afford to run another spare computer 24/7 with Phenom II onboard just to get bitcoind latency lower. I just want to mine on remote nodes like I do with any other central pool. Increasing difficulty is only one solution for this.

In fact it's not a solution at all for this.

Increasing the target delay between shares is the only way to reduce the DOA rate when you have latency between miners and node. But if you do so and don't want to increase variance in payment amounts, you'll have to wait longer for them to stabilize: if N is constant in PPLNS and time between shares is higher, you must mine proportionally longer to reach the full payment amount.

If you do this then most newcomers will be discouraged as first payments will be low for more time. This doesn't help p2pool grow (and make global income variance lower).

[lenny_]

So what's your solution for 10-15% rejects?