Author

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

hero member
Activity: 737
Merit: 500
No 9332 is both mining and web page
9333 is p2p

So I am back to my original question. How do I change the website front-end port?

The answer is still -w.  You can't change the port for only the website front-end without changing the port for miners.  The port for the front-end and the miners is always the same port.
hero member
Activity: 630
Merit: 501
No 9332 is both mining and web page
9333 is p2p

So I am back to my original question. How do I change the website front-end port?
legendary
Activity: 2912
Merit: 1060
No 9332 is both mining and web page
9333 is p2p
hero member
Activity: 630
Merit: 501
how do I change the port 9332 to something else for the website front-end? I know how to change the port for the bitcoin but I need to change it for the front-end now. I have setup a second server on a different box, also does the server need to communicate with the pool on 9333 or can I change that port too?

Thanks,


https://en.bitcoin.it/wiki/P2Pool

  --p2pool-port PORT    use port PORT to listen for connections (forward this
                        port from your router!) (default: bitcoin:9333,
                        litecoin:9338)

  -w PORT or ADDR:PORT, --worker-port PORT or ADDR:PORT
                        listen on PORT on interface with ADDR for RPC
                        connections from miners (default: all interfaces,
                        bitcoin:9332, litecoin:9327)

so to clarify the --p2pool-port is port that when you access it hits the webpage and not the mining pool for the coin(s)?
legendary
Activity: 2912
Merit: 1060
how do I change the port 9332 to something else for the website front-end? I know how to change the port for the bitcoin but I need to change it for the front-end now. I have setup a second server on a different box, also does the server need to communicate with the pool on 9333 or can I change that port too?

Thanks,


https://en.bitcoin.it/wiki/P2Pool

  --p2pool-port PORT    use port PORT to listen for connections (forward this
                        port from your router!) (default: bitcoin:9333,
                        litecoin:9338)

  -w PORT or ADDR:PORT, --worker-port PORT or ADDR:PORT
                        listen on PORT on interface with ADDR for RPC
                        connections from miners (default: all interfaces,
                        bitcoin:9332, litecoin:9327)
hero member
Activity: 630
Merit: 501
how do I change the port 9332 to something else for the website front-end? I know how to change the port for the bitcoin but I need to change it for the front-end now. I have setup a second server on a different box, also does the server need to communicate with the pool on 9333 or can I change that port too?

Thanks,
full member
Activity: 162
Merit: 100
PS- It'd be nice if anyone else has tested my earlier diff to share feedback on it.

I implemented your patch to work.py for my VTC node at vtc.coinpools.de:9171. Looks good so far.

One question, I can't find an answer to: where does this 1.67% of pools shares limit come from? This seems reasonable for a big network like p2pool for LTC or BTC, but many altcoins do have 5-10 pool nodes... Shouldn't this limit somehow be related to the pool node count?

PS @roy7: sorry for the delay, I managed to miss the followup discussion here Wink
sr. member
Activity: 434
Merit: 250
So your update only only applies to the front-end that has the graphs? Will I get any thing out of it if I apply it to my P2Pool that has a different front-end?

Do you run a Vertcoin p2pool node? We need to do a hard fork of the network to fix a setting that was wrong when the network first went live. Has nothing to do with the graphs.

I am confused by the comment after the question...

I run a Bitcoin p2pool.  p2pool.smoothrunnings.ca:9332/

Ok then the changes we're making to the Vertcoin networks.py won't affect you in any way. Smiley
hero member
Activity: 630
Merit: 501
So your update only only applies to the front-end that has the graphs? Will I get any thing out of it if I apply it to my P2Pool that has a different front-end?

Do you run a Vertcoin p2pool node? We need to do a hard fork of the network to fix a setting that was wrong when the network first went live. Has nothing to do with the graphs.

I am confused by the comment after the question...

I run a Bitcoin p2pool.  p2pool.smoothrunnings.ca:9332/

member
Activity: 70
Merit: 10
I have created the proxy pool as discussed earlier, source will be released very soon. I just want to get a bit of testing done. We will be able to scale p2pool to hell and back.
sr. member
Activity: 434
Merit: 250
This is an interesting discussion, please let us know the results.

P2pool is important for bitcoin and making it accessible to more people is important. This type of change helps public pools - and that helps bitcoin and p2pool. Let's face it, many people won't set up their own p2pool node, they want easy and compared to pools that require registration, p2pool is easy.

Decreasing variance (since people are impatient and don't care about the math) could be helpful too. 

Compare the "local rate reflected in shares" between:

http://vtc.royalminingco.com:9171/static/graphs.html?Day  (standard node)
http://vtc-us-east.royalminingco.com:9171/static/graphs.html?Day  (test node)

Standard node has about twice the hash power. The share graph has peaks up to 10x the mean speed, and many gaps. The test node with half the power has peaks only about 5x the mean speed, and almost no gaps.

I guess one could calculate the standard deviation on the graphs to get an idea of the variance reduction between the two, but just visually it's very clear.
sr. member
Activity: 434
Merit: 250
So your update only only applies to the front-end that has the graphs? Will I get any thing out of it if I apply it to my P2Pool that has a different front-end?

Do you run a Vertcoin p2pool node? We need to do a hard fork of the network to fix a setting that was wrong when the network first went live. Has nothing to do with the graphs.
hero member
Activity: 630
Merit: 501
When updating networks.py to a new identifier/prefix and a new spread setting, is it okay to keep the existing share chain data file for the new network? I know you can't run two network.py configs on same network, but it seems like keeping the prior share data wouldn't hurt the new network.

We'll probably bite the bullet and roll out the corrected SPREAD setting this week for VTC.

PS- It'd be nice if anyone else has tested my earlier diff to share feedback on it.

So your update only only applies to the front-end that has the graphs? Will I get any thing out of it if I apply it to my P2Pool that has a different front-end?

sr. member
Activity: 434
Merit: 250
When updating networks.py to a new identifier/prefix and a new spread setting, is it okay to keep the existing share chain data file for the new network? I know you can't run two network.py configs on same network, but it seems like keeping the prior share data wouldn't hurt the new network.

We'll probably bite the bullet and roll out the corrected SPREAD setting this week for VTC.

PS- It'd be nice if anyone else has tested my earlier diff to share feedback on it.
hero member
Activity: 630
Merit: 501
This is an interesting discussion, please let us know the results.

P2pool is important for bitcoin and making it accessible to more people is important. This type of change helps public pools - and that helps bitcoin and p2pool. Let's face it, many people won't set up their own p2pool node, they want easy and compared to pools that require registration, p2pool is easy.

Decreasing variance (since people are impatient and don't care about the math) could be helpful too.  

Has been working well so far. The diff miners get is lower than it'd normally be, but not as low as if they did /1 to mine at the minimum share diff all of the time. The reason /1 goes lower is that it overrides the dust prevention code. So it's best to not just tell all public node miners to use /1, and instead only have people who can't stomach the variance and are willing to pay the tx fees do that (or they should use a normal pool).

The node I'm testing on is

http://vtc-us-east.royalminingco.com:9171/static/graphs.html?Week

and the code went live at the Feb 9ths mark (early morning). You can see from the pool shares graph the peaks/valleys have smoothed out, and you can see it happening in a similar way on a per-miner level on the miner graphs.

I don't run a BTC node at the present time so I don't know what sort of share difficulties normally get assigned to workers on the public pools. The VTC p2pool network is over 5% of the global network speed and finds many blocks per day. So the behavior here might be quite difference than on BTC itself. Hopefully forrestv or someone with more knowledge and experience with the p2pool code base will review and comment.

can you do a comparison shot of before and after? I still don't get what you have changed.

Oops just saw you did that. Smiley
sr. member
Activity: 434
Merit: 250
Now that we have more history. Here is with my change:

http://vtc-us-east.royalminingco.com:9171/static/graphs.html?Day

and here is my other bigger node without it:

http://vtc.royalminingco.com:9171/static/graphs.html?Day

You can see how on the test node, around 600Kh (2 GPUs, vertcoin hash speed is half litecoin speed) is enough to almost never have a gap in payment history. (Consider VaHA4dVWiSJKgWeeqmLDFQPPgrvS6BMkA3.) The payments may be as low as .025 but that honors the dust threshold in networks.py, and since there are more individual shares normally the payments are higher than that (since 2+ shares are alive at any one time).

On the "normal" busier node, there are miners at 1Mh who have more empty space than shares. (Consider VfDC2i3psuH5iSiqmb73qauY5DPQQzT6b4.) Minimum share value here is about .3, but smaller miners often only have 1 share if any.
hero member
Activity: 686
Merit: 500
WANTED: Active dev to fix & re-write p2pool in C
Nice to see someone actually trying to do some development on p2pool - well done!  Smiley

Keep us posted dude.....

Cheers  Grin
sr. member
Activity: 434
Merit: 250
This is an interesting discussion, please let us know the results.

P2pool is important for bitcoin and making it accessible to more people is important. This type of change helps public pools - and that helps bitcoin and p2pool. Let's face it, many people won't set up their own p2pool node, they want easy and compared to pools that require registration, p2pool is easy.

Decreasing variance (since people are impatient and don't care about the math) could be helpful too. 

Has been working well so far. The diff miners get is lower than it'd normally be, but not as low as if they did /1 to mine at the minimum share diff all of the time. The reason /1 goes lower is that it overrides the dust prevention code. So it's best to not just tell all public node miners to use /1, and instead only have people who can't stomach the variance and are willing to pay the tx fees do that (or they should use a normal pool).

The node I'm testing on is

http://vtc-us-east.royalminingco.com:9171/static/graphs.html?Week

and the code went live at the Feb 9ths mark (early morning). You can see from the pool shares graph the peaks/valleys have smoothed out, and you can see it happening in a similar way on a per-miner level on the miner graphs.

I don't run a BTC node at the present time so I don't know what sort of share difficulties normally get assigned to workers on the public pools. The VTC p2pool network is over 5% of the global network speed and finds many blocks per day. So the behavior here might be quite difference than on BTC itself. Hopefully forrestv or someone with more knowledge and experience with the p2pool code base will review and comment.
legendary
Activity: 4256
Merit: 1313
I realize that p2pool's intention is to treat each node as a single miner, and p2pool isn't intended to operate as a pseduo public pool. So as I look in the code, I see how the 1.67% cap is applied to the node (not individual connected miners) and that makes total sense in the context that a node is a single operation (an individual or group using p2pool with all of their own hardware as a replacement for solo mining).

However, to better support miners that want to use a public node for whatever reason I think it'd be good if that could be handled in a way that will, in effect, simulate the same result as if they were running a p2pool node of their own instead. Maybe as a command line option that is off by default so any changes make zero difference to existing operations.

Basically this comes down to making the share target for a miner (by which I mean a person or group with 1 or more physical mining devices) based on that miner, and the 1.67% cap on that miner. Not on the node as whole.

The key code in get_work currently is:

Code:
if desired_share_target is None:
desired_share_target = 2**256-1
local_hash_rate = self._estimate_local_hash_rate()
if local_hash_rate is not None:
desired_share_target = min(desired_share_target,
bitcoin_data.average_attempts_to_target(local_hash_rate * self.node.net.SHARE_PERIOD / 0.0167))
# limit to 1.67% of pool shares by modulating share difficulty

However, we wouldn't want to just change the local_hash_rate to be the miner whose new work is being assigned (the physical mining device with a connection to the pool). That would defeat the purpose of things like the 1.67% cap. What if, instead, it was based on the estimated hash rate of the destination payment address? So if I have 4 antminers all mining to ADDR_X, the target share rate is based on their combined speed. But someone else connecting their two antminers with ADDR_Y will have a lower target share rate. ADDR_X and ADDR_Y are both having the 1.67% cap applied individually, etc. Someone operating a node now with dozens of pieces of equipment all paying to the same address would see zero change even if they did toggle this on. Individual miners on a public node would see reduced variance in their own shares, since pool hash rate is taken out of the equation. They could do this by hand now with ADDR/1 (or say /.000001 for scrypt), but I think handling it automatically makes more sense (and keeps vardiff alive for miners that are maybe bigger than justifies using ADDR/1).

The way I view this is that if ADDR_X and ADDR_Y were running their own nodes instead of connecting to a public node, their target share rates would be based on only their own hash rates anyway. The 1.67% would be applied to each of them individually (instead of all combined in the public node). By adjusting their target share rates only to their own speeds, it simulates them running their own nodes.

Thoughts?

TLDR: A small miner connecting to a busy public node has much higher variance than running a node of their own.

This is an interesting discussion, please let us know the results.

P2pool is important for bitcoin and making it accessible to more people is important. This type of change helps public pools - and that helps bitcoin and p2pool. Let's face it, many people won't set up their own p2pool node, they want easy and compared to pools that require registration, p2pool is easy.

Decreasing variance (since people are impatient and don't care about the math) could be helpful too. 
full member
Activity: 224
Merit: 100
Could you please add DigiByte Support
Jump to: