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

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

Quote from: Mogumodz on November 02, 2013, 03:42:26 PM

Quote from: mdude77 on November 02, 2013, 11:31:52 AM

Quote from: zvs on November 02, 2013, 09:39:00 AM

hetzner network was screwed for about 15m, if anyone reads this that was mining on my pool or some other one located on hetzner network

oh, and luck over the last 3 days has been good if you include 266856 and onwards Grin

5 blocks in 76 hours, estimated time is 14hr30m but that's with 32.9 thash, and the average over the last 76 hours is probably more like 29-30thash... jaja

btw: whoever is using p2pool.org:9332 and paying 2% for 75% efficiency... stop!

I second that! I've got my measily 12gh/s pointed to zvs's server and it's working pretty well. I gave up trying to run my own, don't have the bandwidth for it. Sad

(btw - thanks zvs!!)

M

Heh, I think that must of been you who connected to my pool for a few minuites then

ah, nice to have backup pools set, never know when someone might DoS a p2pool to take that .001% hashrate out of action.

i think you have the wrong person though, since if you look at my weekly chart, FTX has been on it for 3 or 4 days =p

edited!

Mogumodz

sr. member

Activity: 290

Merit: 250

Quote from: mdude77 on November 02, 2013, 11:31:52 AM

Quote from: zvs on November 02, 2013, 09:39:00 AM

hetzner network was screwed for about 15m, if anyone reads this that was mining on my pool or some other one located on hetzner network

oh, and luck over the last 3 days has been good if you include 266856 and onwards Grin

5 blocks in 76 hours, estimated time is 14hr30m but that's with 32.9 thash, and the average over the last 76 hours is probably more like 29-30thash... jaja

btw: whoever is using p2pool.org:9332 and paying 2% for 75% efficiency... stop!

I second that! I've got my measily 12gh/s pointed to zvs's server and it's working pretty well. I gave up trying to run my own, don't have the bandwidth for it. Sad

(btw - thanks zvs!!)

M

Heh, I think that must of been you who connected to my pool for a few minuites then

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

Quote from: mdude77 on November 02, 2013, 11:31:52 AM

Quote from: zvs on November 02, 2013, 09:39:00 AM

hetzner network was screwed for about 15m, if anyone reads this that was mining on my pool or some other one located on hetzner network

oh, and luck over the last 3 days has been good if you include 266856 and onwards Grin

5 blocks in 76 hours, estimated time is 14hr30m but that's with 32.9 thash, and the average over the last 76 hours is probably more like 29-30thash... jaja

btw: whoever is using p2pool.org:9332 and paying 2% for 75% efficiency... stop!

I second that! I've got my measily 12gh/s pointed to zvs's server and it's working pretty well. I gave up trying to run my own, don't have the bandwidth for it. Sad

(btw - thanks zvs!!)

M

heh, speaking of which... i just noticed all the DOA, and it looks like i have nearly 1000 python connects from one person. not sure if something is just busted or if it's intentional or not, i guess i might reset p2pool.

alright, I don't think it was an actual miner, since when I firewalled the IP, nobody's activity dropped off... but the 600-700 open sockets in python weren't closing, so i used fuser -k (then some 600 connections went from established to FIN_WAIT_1). surely there is some better solution? anyone that has more knowledge of linux? was there any way to get rid of all that w/o having to restart p2pool?

i added some limit to simultaneous connections in firewall settings anyway

it was 220.233.90.xx, some ADSL connection from Australia

& having the stats reset sucks. 0 orphans in the last 24 hrs, and 1 out of like 200 shares =p

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: zvs on November 02, 2013, 09:39:00 AM

hetzner network was screwed for about 15m, if anyone reads this that was mining on my pool or some other one located on hetzner network

oh, and luck over the last 3 days has been good if you include 266856 and onwards Grin

5 blocks in 76 hours, estimated time is 14hr30m but that's with 32.9 thash, and the average over the last 76 hours is probably more like 29-30thash... jaja

btw: whoever is using p2pool.org:9332 and paying 2% for 75% efficiency... stop!

I second that! I've got my measily 12gh/s pointed to zvs's server and it's working pretty well. I gave up trying to run my own, don't have the bandwidth for it. Sad

(btw - thanks zvs!!)

M

gnar1ta$

donator

Activity: 798

Merit: 500

Quote from: Mogumodz on November 01, 2013, 03:29:06 PM

Over the next few hours I'm pointing a Jupiter, Saturn and a Mercury all at p2pool for testing on FW 0.98.

Jupiter already seems to be happier than it was last time, Saturn will move over soon.

Yes .98 is much better. I'm up from 440GH/s to 530GH/s on my Jupiter.

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

hetzner network was screwed for about 15m, if anyone reads this that was mining on my pool or some other one located on hetzner network

oh, and luck over the last 3 days has been good if you include 266856 and onwards Grin

5 blocks in 76 hours, estimated time is 14hr30m but that's with 32.9 thash, and the average over the last 76 hours is probably more like 29-30thash... jaja

btw: whoever is using p2pool.org:9332 and paying 2% for 75% efficiency... stop!

Mogumodz

sr. member

Activity: 290

Merit: 250

Block been found recently thankfully.

Over the next few hours I'm pointing a Jupiter, Saturn and a Mercury all at p2pool for testing on FW 0.98.

Jupiter already seems to be happier than it was last time, Saturn will move over soon.

agibby5

sr. member

Activity: 267

Merit: 250

Quote from: oldbushie on November 01, 2013, 02:37:44 PM

Alright, looking through the source code, the problem is that the recent_blocks resource only gets populated with the last day's worth of blocks. So it's not the frontend's fault. If it could at least track a minimum of, say, the last ten blocks that would be a bit more helpful when we run into large blocks. Then I could modify the frontend code a bit to calculate "Current Round" based on the last block received.

I'm just trying to reduce the number of tabs that are constantly open in my browser, heh.

I think it's a good idea. I've wanted some of the features that the p2pool.info site have but that aren't in the p2pool frontend (even the aftermarket one).

oldbushie

member

Activity: 94

Merit: 10

Alright, looking through the source code, the problem is that the recent_blocks resource only gets populated with the last day's worth of blocks. So it's not the frontend's fault. If it could at least track a minimum of, say, the last ten blocks that would be a bit more helpful when we run into large blocks. Then I could modify the frontend code a bit to calculate "Current Round" based on the last block solved.

I'm just trying to reduce the number of tabs that are constantly open in my browser, heh.

oldbushie

member

Activity: 94

Merit: 10

Quote from: zvs on November 01, 2013, 11:15:49 AM

Quote from: oldbushie on November 01, 2013, 12:46:03 AM

I currently use hardcpp's frontend to make p2pool easier on the eyes when tracking my miners. However, I'd like to view a smaller view of the main p2pool.info site on that same page, so I can have everything in one tab. Is that possible?

Basically I just want to see Current Round on my server's main stats page. The last 5 Recent Blocks would be nice to know as well. hardcpp's frontend has something called "Last Blocks" which is empty for me, so I'm not sure if that's *supposed* to mirror the Recent Blocks that the main site shows or if it only shows any blocks that my miners happened to personally solve (versus sharing someone else's block solve).

It's supposed to show all the blocks that p2pool has gotten in the last day or so

except it hasn't gotten any

go get one ASAP

LOL, that explains it then. It should show last X blocks instead of blocks found in the last day.

I'm working on it, already! Wink

These 2 day blocks are killing me.

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

Quote from: oldbushie on November 01, 2013, 12:46:03 AM

I currently use hardcpp's frontend to make p2pool easier on the eyes when tracking my miners. However, I'd like to view a smaller view of the main p2pool.info site on that same page, so I can have everything in one tab. Is that possible?

Basically I just want to see Current Round on my server's main stats page. The last 5 Recent Blocks would be nice to know as well. hardcpp's frontend has something called "Last Blocks" which is empty for me, so I'm not sure if that's *supposed* to mirror the Recent Blocks that the main site shows or if it only shows any blocks that my miners happened to personally solve (versus sharing someone else's block solve).

It's supposed to show all the blocks that p2pool has gotten in the last day or so

except it hasn't gotten any

go get one ASAP

lenny_

legendary

Activity: 1036

Merit: 1000

DARKNETMARKETS.COM

Quote from: forrestv on October 31, 2013, 06:04:37 PM

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.

Thanks! Can't wait to see it in action

oldbushie

member

Activity: 94

Merit: 10

I currently use hardcpp's frontend to make p2pool easier on the eyes when tracking my miners. However, I'd like to view a smaller view of the main p2pool.info site on that same page, so I can have everything in one tab. Is that possible?

Basically I just want to see Current Round on my server's main stats page. The last 5 Recent Blocks would be nice to know as well. hardcpp's frontend has something called "Last Blocks" which is empty for me, so I'm not sure if that's *supposed* to mirror the Recent Blocks that the main site shows or if it only shows any blocks that my miners happened to personally solve (versus sharing someone else's block solve).

gyverlb

hero member

Activity: 896

Merit: 1000

Quote from: forrestv on October 31, 2013, 06:04:37 PM

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

Seems great.

Quote from: forrestv on October 31, 2013, 06:04:37 PM

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.

forrestv

hero member

Activity: 516

Merit: 643

Quote from: gyverlb on October 31, 2013, 04:53:51 PM

Quote from: lenny_ on October 31, 2013, 04:40:20 PM

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

hero member

Activity: 896

Merit: 1000

Quote from: lenny_ on October 31, 2013, 04:40:20 PM

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).

lenny_

legendary

Activity: 1036

Merit: 1000

DARKNETMARKETS.COM

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.

gnar1ta$

donator

Activity: 798

Merit: 500

Quote from: maqifrnswa on October 31, 2013, 11:32:26 AM

Quote from: lenny_ on October 31, 2013, 01:28:21 AM

Quote from: gnar1ta$ on October 30, 2013, 08:55:38 PM

Quote from: maqifrnswa on October 30, 2013, 01:39:18 PM

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.

maqifrnswa

sr. member

Activity: 454

Merit: 252

Quote from: lenny_ on October 31, 2013, 01:28:21 AM

Quote from: gnar1ta$ on October 30, 2013, 08:55:38 PM

Quote from: maqifrnswa on October 30, 2013, 01:39:18 PM

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

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

Quote from: mdude77 on October 30, 2013, 06:30:42 PM

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

Quote

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)

Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 472. (Read 2592017 times)