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

[gmaxwell]

Here is Jupiter with .97.  Compare to here https://bitcointalk.org/index.php?topic=18313.msg3307821#msg3307821

Is it also run 440GH/s on "normal" pools? Looks like flushwork takes like 1 sec

No.  480-510GH/s.

IIRC the graph number minus DOA, but you get some of the DOA back because everyone else has them too. Should check with forrestv, also note you are 110% efficiency in that p2pool output, meaning you're outperforming the pool on average latency wise and are expect to get 110% of what you would expect based on your hashrate.

Is the CGminer claimed hashrate lower with p2pool then elsewhere?  If so, something about the hardware design / firmware / or miner driver is brain damaged.

[1713573857]

1713573857

[1713573857]

1713573857

[1713573857]

1713573857

[1713573857]

1713573857

[1713573857]

1713573857

[1713573857]

1713573857

[gnar1ta$]

Here is Jupiter with .97.  Compare to here https://bitcointalk.org/index.php?topic=18313.msg3307821#msg3307821

Is it also run 440GH/s on "normal" pools? Looks like flushwork takes like 1 sec

No.  480-510GH/s.

IIRC the graph number minus DOA, but you get some of the DOA back because everyone else has them too. Should check with forrestv, also note you are 110% efficiency in that p2pool output, meaning you're outperforming the pool on average latency wise and are expect to get 110% of what you would expect based on your hashrate.

Is the CGminer claimed hashrate lower with p2pool then elsewhere?  If so, something about the hardware design / firmware / or miner driver is brain damaged.

Considering that my efficiency is over 100% and I generally pay up to a 3% pool fee elsewhere, I've left the Jupiter on p2pool - it's averaging out to 450GH/s so I shouldn't be too far off...if my understanding of efficiency is correct 

The CGminer hashrate actually behaves opposite on other pools.  It always reports lower than p2pool reports, but reports higher than other pools.  On BTCGuild and Ozcoin CGminer shows 530GH/s and the pools 480-510.

[SpAcEDeViL]

really good explanation

share diff is determined such that:
1) a p2pool share is found every 30 seconds
2) no single miner is expected to generate >5% of the shares (difficulty is adjusted up to keep the total number of shares lower, just for them)

One more thing, the share chain isn't always 8640 long. It's 3x the expected work needed to find a block, or 8640, whichever is less. So right now it's ~45 hours, so a little under two days. (I believe that's what the code says, please correct me if I'm wrong)


All the math aside, what matters is that the expected payout using p2pool is greater than that of any other pool -- even for small miners. The variance, however, is bigger.

Thats confuse me. I have mine for 2 Days (Friday and Saturday) with 14 GH on mine p2pool node smileandgo.de:9332
The Node makes no pool shares. My miner have make over 32k accepted shares to the node.
And i become no payouts to my address or to the node address

[gnar1ta$]

Thats confuse me. I have mine for 2 Days (Friday and Saturday) with 14 GH on mine p2pool node smileandgo.de:9332
The Node makes no pool shares. My miner have make over 32k accepted shares to the node.
And i become no payouts to my address or to the node address

You need to find a pool share. Think of it as a p2pool block maybe. When you find one your payout should be higher than an equivalent PPS payout to make up for the time you didn't find a pool share. That's how variance work - and you will have a lot of variance at that hashrate. What's your expected time to share?

[maqifrnswa]

really good explanation

share diff is determined such that:
1) a p2pool share is found every 30 seconds
2) no single miner is expected to generate >5% of the shares (difficulty is adjusted up to keep the total number of shares lower, just for them)

One more thing, the share chain isn't always 8640 long. It's 3x the expected work needed to find a block, or 8640, whichever is less. So right now it's ~45 hours, so a little under two days. (I believe that's what the code says, please correct me if I'm wrong)


All the math aside, what matters is that the expected payout using p2pool is greater than that of any other pool -- even for small miners. The variance, however, is bigger.

Thats confuse me. I have mine for 2 Days (Friday and Saturday) with 14 GH on mine p2pool node smileandgo.de:9332
The Node makes no pool shares. My miner have make over 32k accepted shares to the node.
And i become no payouts to my address or to the node address

You haven't found a p2pool share yet. The 32k shares you see are simply shares reporting back to the node for statistics. The current p2pool difficulty is 138k. So you are expected to find one p2pool share after ~138k difficulty 1 shares.

The entire network finds a share every 30 seconds, not just you.

When you find a p2pool share, it pays out a lot more than a difficulty 1 PPS share, but you find them less frequently. Larger and less frequent payouts means higher variance.

It's possible that you will get 0 payouts for each share you find if the whole pool doesn't find one in ~2 days after you found yours, but it's also possible that it finds 6 (and pays you 6 times). On average, you get paid more than a PPS scheme. But variance is larger, especially for smaller miners.

It's up to you to choose how much variance is worth to you.

[Polyatomic]

really good explanation


Thats confuse me. I have mine for 2 Days (Friday and Saturday) with 14 GH on mine p2pool node smileandgo.de:9332
The Node makes no pool shares. My miner have make over 32k accepted shares to the node.
And i become no payouts to my address or to the node address

You will eventually get a p2pool share. Im sending you positive vibes.

[zvs]

is there some logical reason that (any) share found directly before a new block is orphaned?

i have my node set to ignore the 'punish', since otherwise it'd be penalized for being fast.

all i can think of is to prevent these nodes that have the huge getblocktemplate + network latency from spitting out invalid shares based on the old block?  what other reason would there be to punish a share that is made before the new block  (and thus valid) ?

[SpAcEDeViL]

Hy,

thanks for the replays on my post.

Now i have mine for 5 days... no share. So i give up yesterday. "expected time to share was 11 - 14 hours)"

I see too many push "new work for the worker" and my miner become so many HW errors from this.
On a central pool the new work comes after minutes and not after seconds... less HW errors.

And when my miner diff is auto set to diff 3 or 2... so i cannot create a share over the pool diff... thats impossible or??...

Why not the node collect the miner shares and create a  big node share, and all on the node, thats make shares to it, become btc from ne node btc adress, when its higher then 0.01 btc on a week, or when its higher than 0.10 on a day? or the node owner can set this?

Can i set a node fee? so when a miner create a share from my node i become 0.05% fee? 

[forrestv]

is there some logical reason that (any) share found directly before a new block is orphaned?

i have my node set to ignore the 'punish', since otherwise it'd be penalized for being fast.

all i can think of is to prevent these nodes that have the huge getblocktemplate + network latency from spitting out invalid shares based on the old block?  what other reason would there be to punish a share that is made before the new block  (and thus valid) ?

Yes.

First, it's at least necessary for shares found after a new block is found to be orphaned, in order to not reward people for doing useless work. A preference for shares pointing to newer blocks that overrides the "first share received is the one to build on" rule was added to the P2Pool protocol.

There is no way for the P2Pool protocol rules to know whether a share came before or after the block - they can only see that there is a share pointing to a newer block at the same height of the (to be orphaned) share.

So, all the nodes could potentially only orphan shares that come after the block change, but there's nothing that prevents someone from orphaning all the shares they can, which would give them a slight advantage. So, I decided that nodes should be "maximally aggressive" and orphan others' shares whenever they can. This is at least fair, but it has the disadvantage of increasing the pool's orphaned share rate.

Future changes that make the P2Pool protocol rules more aware of how the Bitcoin blockchain works could potentially improve this, but for now, this is the way it has to be.

[maqifrnswa]

Hy,

thanks for the replays on my post.

Now i have mine for 5 days... no share. So i give up yesterday. "expected time to share was 11 - 14 hours)"

I see too many push "new work for the worker" and my miner become so many HW errors from this.
On a central pool the new work comes after minutes and not after seconds... less HW errors.

And when my miner diff is auto set to diff 3 or 2... so i cannot create a share over the pool diff... thats impossible or??...

Why not the node collect the miner shares and create a  big node share, and all on the node, thats make shares to it, become btc from ne node btc adress, when its higher then 0.01 btc on a week, or when its higher than 0.10 on a day? or the node owner can set this?

Can i set a node fee? so when a miner create a share from my node i become 0.05% fee?  

new work for worker: p2pool sends new work to worker every time a p2pool network share is found, around every 30 seconds versus 10 minutes for the bitcoin block chain (although new work is generated more frequently than 10 mins as it adds transactions to it)

Errors with new work: some hardware manufacturers ignore standard miner commands and throw away all the work when there is a block change. This adds negligible wasted work when blocks are 10 minutes, but lots of wasted work when blocks aer 30 seconds. Many manufacturers released updated firmware that fixed their mistake, but not all have.

Difficulty: You can set your diff higher by using the user name "username+{difficulty}" so if you want difficulty 16 shares returned to your node, just use "-u username+16" command line argument.

Node collection: This can be done and bigger miners are encouraged to do this to help out the smaller ones. You can do this by using the username "username/{difficulty}". So if I want to return one HUGE share that is worth 10x a small share, I log in with "-u username/1400000" I find a share 10x less frequently, but when I do it pays out a lot. people who find 50+ shares a day can do this and see a negligible change in variance and payout while encouraging smaller miners to keep mining by reducing small miner variance.

Node fee: Yes you can set a node fee by starting p2pool with the "--fee" argument. Run p2pool with "--help" to get info on how to set it up. What it does is randomly assign that percentage of shares to your default address so when a share is found, you get credit for it - not the person that logged in and found it.

[mdude77]

Someone has a small bit of hash pointed at ZVS's server nogleg.com with the name "Mindlesss.worker1".  If I understand p2pool right, you'll never get paid for your work as your worker name has to be your payout address.

M

[gnar1ta$]

Node collection: This can be done and bigger miners are encouraged to do this to help out the smaller ones. You can do this by using the username "username/{difficulty}". So if I want to return one HUGE share that is worth 10x a small share, I log in with "-u username/1400000" I find a share 10x less frequently, but when I do it pays out a lot. people who find 50+ shares a day can do this and see a negligible change in variance and payout while encouraging smaller miners to keep mining by reducing small miner variance.

Maybe this should be set automatically by p2pool like the difficulty to keep the share difficulty lower and keep smaller miners on the pool?

[lenny_]

Node collection: This can be done and bigger miners are encouraged to do this to help out the smaller ones. You can do this by using the username "username/{difficulty}". So if I want to return one HUGE share that is worth 10x a small share, I log in with "-u username/1400000" I find a share 10x less frequently, but when I do it pays out a lot. people who find 50+ shares a day can do this and see a negligible change in variance and payout while encouraging smaller miners to keep mining by reducing small miner variance.

Maybe this should be set automatically by p2pool like the difficulty to keep the share difficulty lower and keep smaller miners on the pool?

Yes, I really think this should be implemented. P2pool share should not be found by a miner more frequent than every 30 minutes. If it happens, p2pool node should automatically adjust real share difficulty to higher number, so share time is still estimated to be 30 minutes.
Right now having about 400 GH/s will give you p2pool share every 30 minutes. But we have miners here with 1000GH/s and more, they are finding share in less than 10 minutes. If they could increse their share time, small miners will have chance again to mine with p2pool.

[zvs]

Someone has a small bit of hash pointed at ZVS's server nogleg.com with the name "Mindlesss.worker1".  If I understand p2pool right, you'll never get paid for your work as your worker name has to be your payout address.

M

that's correct

it looks like I picked up someone else's share earlier (i'm at 0.0003 now)

maybe p2pool should come with some 'instructions' tab on the web interface?  i guess a lot of people have added something like this themself, but maybe should just be included as part of standard server

Yes.

First, it's at least necessary for shares found after a new block is found to be orphaned, in order to not reward people for doing useless work. A preference for shares pointing to newer blocks that overrides the "first share received is the one to build on" rule was added to the P2Pool protocol.

There is no way for the P2Pool protocol rules to know whether a share came before or after the block - they can only see that there is a share pointing to a newer block at the same height of the (to be orphaned) share.

So, all the nodes could potentially only orphan shares that come after the block change, but there's nothing that prevents someone from orphaning all the shares they can, which would give them a slight advantage. So, I decided that nodes should be "maximally aggressive" and orphan others' shares whenever they can. This is at least fair, but it has the disadvantage of increasing the pool's orphaned share rate.

Future changes that make the P2Pool protocol rules more aware of how the Bitcoin blockchain works could potentially improve this, but for now, this is the way it has to be.

OK, that makes sense...  but wouldn't it be more fair to delay this punishment until the share after?   Right now, probably 90% or more of the shares being penalized are being done so unjustly

ed; forgot to add, i'll send whatever that errant share makes (if anything) to 1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23 (forrestv address)

[maqifrnswa]

Node collection: This can be done and bigger miners are encouraged to do this to help out the smaller ones. You can do this by using the username "username/{difficulty}". So if I want to return one HUGE share that is worth 10x a small share, I log in with "-u username/1400000" I find a share 10x less frequently, but when I do it pays out a lot. people who find 50+ shares a day can do this and see a negligible change in variance and payout while encouraging smaller miners to keep mining by reducing small miner variance.

Maybe this should be set automatically by p2pool like the difficulty to keep the share difficulty lower and keep smaller miners on the pool?

Yes, I really think this should be implemented. P2pool share should not be found by a miner more frequent than every 30 minutes. If it happens, p2pool node should automatically adjust real share difficulty to higher number, so share time is still estimated to be 30 minutes.
Right now having about 400 GH/s will give you p2pool share every 30 minutes. But we have miners here with 1000GH/s and more, they are finding share in less than 10 minutes. If they could increse their share time, small miners will have chance again to mine with p2pool.

p2pool does this by default, it readjusts share difficulty for miners to make sure no miner has > 5% of the shares in a given window:

https://github.com/forrestv/p2pool/blob/0460c6cf03b8da4a5accb5ac26606e596a5571ff/p2pool/work.py#L251

Code:

desired_share_target = min(desired_share_target, bitcoin_data.average_attempts_to_target(local_hash_rate * self.node.net.SHARE_PERIOD / 0.05)) # limit to 5% of pool shares by modulating share difficulty

[gnar1ta$]

Node collection: This can be done and bigger miners are encouraged to do this to help out the smaller ones. You can do this by using the username "username/{difficulty}". So if I want to return one HUGE share that is worth 10x a small share, I log in with "-u username/1400000" I find a share 10x less frequently, but when I do it pays out a lot. people who find 50+ shares a day can do this and see a negligible change in variance and payout while encouraging smaller miners to keep mining by reducing small miner variance.

Maybe this should be set automatically by p2pool like the difficulty to keep the share difficulty lower and keep smaller miners on the pool?

Yes, I really think this should be implemented. P2pool share should not be found by a miner more frequent than every 30 minutes. If it happens, p2pool node should automatically adjust real share difficulty to higher number, so share time is still estimated to be 30 minutes.
Right now having about 400 GH/s will give you p2pool share every 30 minutes. But we have miners here with 1000GH/s and more, they are finding share in less than 10 minutes. If they could increse their share time, small miners will have chance again to mine with p2pool.

p2pool does this by default, it readjusts share difficulty for miners to make sure no miner has > 5% of the shares in a given window:

https://github.com/forrestv/p2pool/blob/0460c6cf03b8da4a5accb5ac26606e596a5571ff/p2pool/work.py#L251

Code:

desired_share_target = min(desired_share_target, bitcoin_data.average_attempts_to_target(local_hash_rate * self.node.net.SHARE_PERIOD / 0.05)) # limit to 5% of pool shares by modulating share difficulty

That will only limit >1.5TH/s miners at current pool rate? That's a bit high to be much help for smaller miners.

[lenny_]

So nice it has been implemented already. But I will agree with comments made earlier on, it should be applied to miners with 500 GH/s (1.7% of total p2pool hashrate). Please reduce it to at least 2% from 5%. It's a simple fix, and it will help a lot to small miners.

[gyverlb]

So nice it has been implemented already. But I will agree with comments made earlier on, it should be applied to miners with 500 GH/s (1.7% of total p2pool hashrate). Please reduce it to at least 2% from 5%. It's a simple fix, and it will help a lot to small miners.

From experience, having "only" 2% of the p2pool hashrate doesn't mean there's too much variance (the rewards oscillate +/-~10% around).

With 5%, ~20 large miners can take most of the pie, leaving crumbs to others. With 2%, this is raised to 50 large miners.

I'd be OK with a 1% limit, but 2% should limit complains of high variance from large miners (the reward may even move as much from the hashrate fluctuations of the whole pool as from the share frequency variance, people with 5% or more may be able to confirm this if they have variance around 10% in their rewards too).

BTW: I've not looked into the code, what would happen if there were only 10 miners on p2pool? Is the current algorithm able to converge on sane values or would the current 5% target raise the individual share difficulty without bonds.
From the one-liner extract above it seems there's a missing parameter to achieve this protection (the number of distinct addresses with valid shares in the recent sharechain).

[forrestv]

So nice it has been implemented already. But I will agree with comments made earlier on, it should be applied to miners with 500 GH/s (1.7% of total p2pool hashrate). Please reduce it to at least 2% from 5%. It's a simple fix, and it will help a lot to small miners.

From experience, having "only" 2% of the p2pool hashrate doesn't mean there's too much variance (the rewards oscillate +/-~10% around).

With 5%, ~20 large miners can take most of the pie, leaving crumbs to others. With 2%, this is raised to 50 large miners.

I'd be OK with a 1% limit, but 2% should limit complains of high variance from large miners (the reward may even move as much from the hashrate fluctuations of the whole pool as from the share frequency variance, people with 5% or more may be able to confirm this if they have variance around 10% in their rewards too).

BTW: I've not looked into the code, what would happen if there were only 10 miners on p2pool? Is the current algorithm able to converge on sane values or would the current 5% target raise the individual share difficulty without bonds.
From the one-liner extract above it seems there's a missing parameter to achieve this protection (the number of distinct addresses with valid shares in the recent sharechain).

I will decrease the percentage then. Maybe 1.67%? That's a share every half hour.

If there are very few miners, nothing insane happens. Each miner's share difficulty multiplier becomes the maximum, 30, and then the 30-second share period target decreases the minimum difficulty until there's a share every 30 seconds again.

[gyverlb]

I will decrease the percentage then. Maybe 1.67%? That's a share every half hour.

Seems great.

If there are very few miners, nothing insane happens. Each miner's share difficulty multiplier becomes the maximum, 30, and then the 30-second share period target decreases the minimum difficulty until there's a share every 30 seconds again.

Oh right! I forgot about the maximum multiplier, thanks.