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

[cathoderay]

Oh, and I can confirm that merged mining works fine still as I now have block rewards for IXC, NMC, and DVC.

jonnybravo - would you mind telling me what ports (rpc & p2p) you are using for your different coins?

I see so many different statements regarding this it's daft, & seeing as yours are confirmed working......

Thanks 

[andmax]

I have just setup my own node in Perth Western Australia if anyone wants to check it out go to p2poolmining.hopto.org:9332 feel free to mine on it 0% fee. I'm looking a getting a few Antminer S1's in the next couple of weeks to boost up the hash power.

[bkminer]

They are one of us..

I agree, I just like to know my family better.... 

[Meuh6879]

  good to see that some farm have do some test on P2Pool to evaluate the reward and the available share job ...


http://imageshack.com/a/img843/1953/d1jm.jpg

[phillipsjk]

p2pool supports stratum.

Maybe I'm missing a step in my setup to get stratum working?

The problem is that P2Pool auto-detects if the miner is using the old get-work protocol. However, most stratum proxies auto-detect stratum pools by trying to use getwork first. An option to disable this auto-detection on either side would be nice.

Would probably be difficult with the P2Pool software since the listening port is also overloaded for the stats page.
Edit: I suppose P2Pool can start sending out the X-Stratum: (not sure about spelling) header directing such clients... to the same port they connected on.

[PublicP2poolNode]

Thank you, I'll see if they can fix it on their end then.

[PatMan]

I noticed bfgminer are working on integrating SSL/TLS support in their miner - I've been looking through p2pool documentation but can't find any info on weather p2pool supports it or not.....anybody shed some light on this for me?

Peace.

[jonnybravo0311]

Oh, and I can confirm that merged mining works fine still as I now have block rewards for IXC, NMC, and DVC.

jonnybravo - would you mind telling me what ports (rpc & p2p) you are using for your different coins?

I see so many different statements regarding this it's daft, & seeing as yours are confirmed working......

Thanks 

For those of you interested in merge mining on your p2pool node, there's a great thread here: https://bitcointalk.org/index.php?topic=62842.0

It's rather old, but the information in it is good.  Below, I've put the *.conf files from my system, and the command I use to start my node.  User names and passwords have been changed.

1) bitcoin.conf

server=1
rpcuser=BTCuser
rpcpassword=BTCpassword
rpcallowip=10.0.1.*
rpcport=8332

2) devcoin.conf

server=1
rpcuser=DVCuser
rpcpassword=DVCpassword
rpcallowip=10.0.1.*
rpcport=53333

3) ixcoin.conf

server=1
daemon=1
listen=1
rpcuser=IXCuser
rpcpassword=IXCpassword
rpcallowip=10.0.1.*
rpcport=8338

4) namecoin.conf

server=1
daemon=1
listen=1
rpcuser=NMCuser
rpcpassword=NMCpassword
rpcallowip=10.0.1.*
rpcport=7333

5) Node startup

nohup ./run_p2pool.py --give-author 0 --merged http://NMCuser:NMCpassword@10.0.1.10:7333 --merged http://IXCuser:IXCpassword@10.0.1.10:8338 --merged http://DVCuser:DVCpassword@10.0.1.10:53333 -a NODEWALLETADDRESS BTCuser BTCpassword > /dev/null 2>&1 &

Hope this helps!

[mdude77]

I noticed bfgminer are working on integrating SSL/TLS support in their miner - I've been looking through p2pool documentation but can't find any info on weather p2pool supports it or not.....anybody shed some light on this for me?

Peace.

If you're using a local node it shouldn't matter.

M

[jacob019]

Network hash rate is up to 524 TH/s, best I've seen.  Expected time to block is down to 15 hours, really great!

I'm operating a 0% fee node on a fast server in Chicago.
http://p2pool.1js.us
Come mine with us!

[mdude77]

Network hash rate is up to 524 TH/s, best I've seen.  Expected time to block is down to 15 hours, really great!

I'm operating a 0% fee node on a fast server in Chicago.
http://p2pool.1js.us
Come mine with us!

The hash rate seems to jump around quite a bit.  I think I finally understand why.  p2pool doesn't really know what the hash rate is.  It just does an estimate based on how many shares are being found per time period.  Since that varies with pool share difficulty, it keeps swinging around.  Pool share difficulty goes up, shares/time goes down, apparent hashrate decreases.  Then pool share difficulty goes down to compensate, shares/time goes up, and apparent hashrate increases.  Rinse and repeat.

M

[gyverlb]

Network hash rate is up to 524 TH/s, best I've seen.  Expected time to block is down to 15 hours, really great!

I'm operating a 0% fee node on a fast server in Chicago.
http://p2pool.1js.us
Come mine with us!

The hash rate seems to jump around quite a bit.  I think I finally understand why.  p2pool doesn't really know what the hash rate is.  It just does an estimate based on how many shares are being found per time period.  Since that varies with pool share difficulty, it keeps swinging around.  Pool share difficulty goes up, shares/time goes down, apparent hashrate decreases.  Then pool share difficulty goes down to compensate, shares/time goes up, and apparent hashrate increases.  Rinse and repeat.

M

This effect could be felt only between 2 shares if the difficulty rose of fell rapidly while the actual network speed went in the other direction. Given that the p2pool share interval is only 30 seconds this effect should be negligible.

The problem is more likely to be simply that the hash rate is an estimation on a time period or a number of shares (which is more or less the same). As a mean value it doesn't reflect the fastest changes. I'm not sure how many shares are used for the current hash rate estimation that's probably not hard to find in the code though...

[PatMan]

I noticed bfgminer are working on integrating SSL/TLS support in their miner - I've been looking through p2pool documentation but can't find any info on weather p2pool supports it or not.....anybody shed some light on this for me?

Peace.

If you're using a local node it shouldn't matter.

M

Hi mdude,

Obviously not for the local miner node, I meant for the remote miner as well as nodes to node communication. I see there are many reports from various pools that there is some kind of bug/malware causing redirects etc, hence the reason for the SSL/TLS - just to give another level of security. I like the thought of internode comms being securely encrypted, as well as the miner software 

[mdude77]

Network hash rate is up to 524 TH/s, best I've seen.  Expected time to block is down to 15 hours, really great!

I'm operating a 0% fee node on a fast server in Chicago.
http://p2pool.1js.us
Come mine with us!

The hash rate seems to jump around quite a bit.  I think I finally understand why.  p2pool doesn't really know what the hash rate is.  It just does an estimate based on how many shares are being found per time period.  Since that varies with pool share difficulty, it keeps swinging around.  Pool share difficulty goes up, shares/time goes down, apparent hashrate decreases.  Then pool share difficulty goes down to compensate, shares/time goes up, and apparent hashrate increases.  Rinse and repeat.

M

This effect could be felt only between 2 shares if the difficulty rose of fell rapidly while the actual network speed went in the other direction. Given that the p2pool share interval is only 30 seconds this effect should be negligible.

The problem is more likely to be simply that the hash rate is an estimation on a time period or a number of shares (which is more or less the same). As a mean value it doesn't reflect the fastest changes. I'm not sure how many shares are used for the current hash rate estimation that's probably not hard to find in the code though...

I think we're saying the same thing.  What's unknown is the time period involved.

M

[gyverlb]

I think we're saying the same thing.  What's unknown is the time period involved.

M

I'm not sure, the part I didn't quite understand is :

Pool share difficulty goes up, shares/time goes down, apparent hashrate decreases.  Then pool share difficulty goes down to compensate, shares/time goes up, and apparent hashrate increases.

The pool share difficulty is recomputed every new share (according to my p2pool logs) and is adjusted to match the detected hash rate. Past share difficulty is used to compute the average hash rate, not the current difficulty so changing the current difficulty doesn't affect the detected hash rate. So I don't understand why you say that apparent hashrate decreases or increases according to pool share difficulty.

[mdude77]

I think we're saying the same thing.  What's unknown is the time period involved.

M

I'm not sure, the part I didn't quite understand is :

Pool share difficulty goes up, shares/time goes down, apparent hashrate decreases.  Then pool share difficulty goes down to compensate, shares/time goes up, and apparent hashrate increases.

The pool share difficulty is recomputed every new share (according to my p2pool logs) and is adjusted to match the detected hash rate. Past share difficulty is used to compute the average hash rate, not the current difficulty so changing the current difficulty doesn't affect the detected hash rate. So I don't understand why you say that apparent hashrate decreases or increases according to pool share difficulty.

It was the logical assumption I came to.  p2pool doesn't know the pool hashrate, so it has to use something to estimate it.  The only thing it can estimate it by is how often shares are submitted (shares/some time period).  I realize now the problem with that is how often shares are solved is supposed to be fixed ... the 30 second difficulty adjustment you referred to.  So I have to nix that thought.

That said, I have a hard time believing the pool rate really fluctuates as much as it appears to.

M

[IYFTech]

Indeed, the hash rate swing is massive sometimes - I'm wondering if it's due to this redirect issue other pools are experiencing.....?

[jedimstr]

The large swings could also be due to large miners using quota pool settings (like in BFGMiner) to jump between p2pool and other centralized pool.  Sorta "have your cake and eat it too" mentality. 

[smoothrunnings]

I am seeing huge swings in the predicted payout, which is normally spot on when a payout occurs because I verify it when I look at when I get paid.

My 100GH miner has fallen to .001 while my 180GH/s of miners is .008 to .010 which doesn't make sense for the 100GH/s miner.

I see the global pool is now 485GH/s.

[jonnybravo0311]

I am seeing huge swings in the predicted payout, which is normally spot on when a payout occurs because I verify it when I look at when I get paid.

My 100GH miner has fallen to .001 while my 180GH/s of miners is .008 to .010 which doesn't make sense for the 100GH/s miner.

I see the global pool is now 485GH/s.

It depends on when the last share was found by your 100GH miner.  Expected payout will indeed swing around wildly as hash rates increase/decrease, share difficulties increase/decrease, shares drop off the payout list, etc.