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

[idonothave]

Yes, on the standard p2pool web GUI every address can be seen.

PS:  BLOCK!!  

That's odd, as I'm passing through the mining addresses as can be seen by how little is being credited to me.

P.S. 2nd share too.

EDIT: You're right, something's amuck. Your miners are supposed to be forced to reconnect by the proxy but they're not. I'm looking into it right now.

I may restart the node a few times while I implement code changes, bear with me (and always have a failover as you already know).

no problem, I understand we are in testing mode. let as know

[1714024976]

1714024976

[-ck]

Yes, on the standard p2pool web GUI every address can be seen.

PS:  BLOCK!!  

That's odd, as I'm passing through the mining addresses as can be seen by how little is being credited to me.

P.S. 2nd share too.

EDIT: You're right, something's amuck. Your miners are supposed to be forced to reconnect by the proxy but they're not. I'm looking into it right now.

I may restart the node a few times while I implement code changes, bear with me (and always have a failover as you already know).

Taking them down for a bit, they're not doing what they're supposed to. Redirecting the port directly to the p2pool node for the time being.

[p3yot33at3r]

No worries, I see my miner is still reporting the node as live so I'll just leave it as is.

[windpath]

Many thanks again -ck. With all the nastyness going on atm, it's great that a dev such as yourself is willing to step in & help out us p2poolers 

Incredibly the DE node has already found a share.

Yeah, I saw that 

I'm not seeing my payout address in the graphs for some reason:

17RAoAa2ZJy5vh2YNwx2NMHijrRmAajGr2

you cannot see it because it is working with default address which is sense of the thing
future payouts is another thing and he ck has there different solution then p2pool originaly has or?

Does the p2pool intrinsic web page usually show miners logged into a public node as separate addresses? I currently have 2 active miners in the proxy logs:

Code:

[2015-12-12 06:38:53.071] User 1PXJiWRQt3gNBAe4j6dbugEqhufJdgncCc:{"hashrate1m": "1.48T", "hashrate5m": "1.36T", "hashrate1hr": "658G", "hashrate1d": "36.5G", "hashrate7d": "5.27G", "lastupdate": 1449920333, "workers": 1, "shares": 741666, "bestshare": 2691098.6662059599}
[2015-12-12 06:38:53.071] User 17RAoAa2ZJy5vh2YNwx2NMHijrRmAajGr2:{"hashrate1m": "381G", "hashrate5m": "380G", "hashrate1hr": "134G", "hashrate1d": "7.03G", "hashrate7d": "1.01G", "lastupdate": 1449920333, "workers": 1, "shares": 142968, "bestshare": 475613.94521986018}

If all is going correctly, 1PXJiWRQt3gNBAe4j6dbugEqhufJdgncCc got the share and as far as I can tell it was credited to him, and only 1% credited to my 1GYU9ouTVY6ECTqidLe96mWn485dP6WZaJ address.

Very cool CK! If I remember correctly how the node fee works it is not 1% of each share but 1% of shares... So if a miner finds 100 shares on your node ~99 go to him and ~1 go to you...

[-ck]

No worries, I see my miner is still reporting the node as live so I'll just leave it as is.

Ok they're back up and I can see the extra miners listed now. Let's see what breaks next

[p3yot33at3r]

Let's see what breaks next

That'll be me.....

I can see the addresses on the web UI now - good stuff -ck  

Edit:  Ouch - that DOA rate........

[-ck]

Edit:  Ouch - that DOA rate........

Almost 3 am, but...

What's normal/good?

[windpath]

Edit:  Ouch - that DOA rate........

Almost 3 am, but...

What's normal/good?

Ideally you want to be equal to or better than the global pool DOA...

[p3yot33at3r]

Edit:  Ouch - that DOA rate........

Almost 3 am, but...

What's normal/good?

Mine sits at about 3% - but it's a local private node.

[Meuh6879]

[-ck]

Edit:  Ouch - that DOA rate........

Almost 3 am, but...

What's normal/good?

Mine sits at about 3% - but it's a local private node.

Yeah, don't know what to make of it. The overnight run saw 9 shares come in total without any orphans or dead but of course you need about 100 shares to get a fair idea of the real efficiency. I can understand if you move your miner away and appreciate the testing you did initially to confirm it works though, thanks.

It's been a while since I've played with p2pool though and something is really bugging me that I spot in the logs. I was wondering if anyone could answer me since my python knowledge is almost non-existent. On block changes, I'm NOT seeing p2pool immediately ask for a new block template when looking at my bitcoind logs which I have extra debugging on. Take for example this last block:

The block came in here:

Code:

2015-12-12 21:11:05.242988 UpdateTip: new best

And p2pool asked for the first newblock template here:

Code:

2015-12-12 21:11:23.387677 CreateNewBlock

Note the timestamps. There are 18 seconds between the block change and the first block template request. Now on my pool software I get a new template within milliseconds of the block update.

So here's the question. Is p2pool by design not updating immediately on block changes and hashing on stale work? Am I missing something?

[p3yot33at3r]

It's been a while since I've played with p2pool though and something is really bugging me that I spot in the logs. I was wondering if anyone could answer me since my python knowledge is almost non-existent. On block changes, I'm NOT seeing p2pool immediately ask for a new block template when looking at my bitcoind logs which I have extra debugging on. Take for example this last block:

The block came in here:

Code:

2015-12-12 21:11:05.242988 UpdateTip: new best

And p2pool asked for the first newblock template here:

Code:

2015-12-12 21:11:23.387677 CreateNewBlock

Note the timestamps. There are 18 seconds between the block change and the first block template request. Now on my pool software I get a new template within milliseconds of the block update.

So here's the question. Is p2pool by design not updating immediately on block changes and hashing on stale work? Am I missing something?

Above my paygrade I'm afraid - maybe forrestv can chime in here?

[-ck]

Well I've never really investigated the work model in p2pool and perhaps it's building on the work in its own chain somehow and not dependent on bitcoind? I see lots of blocktemplate calls to bitcoind the rest of the time though.

[p3yot33at3r]

Well I've never really investigated the work model in p2pool and perhaps it's building on the work in its own chain somehow and not dependent on bitcoind?

That's pretty much how I understand it to work, but I'm sure there's a little more to it than that.

[forrestv]

P2Pool should immediately call getblocktemplate after it knows that there is a new block. It is notified that there is a new block via its P2P connection to bitcoind, through which bitcoind sents an inv message when it has a new block. The code that does this is the work_poller in node.py. The reason that you saw a 18 second delay is something within that loop. Maybe bitcoind was lagging and took a long time to announce the block after it printed "new best"? Or maybe P2Pool was lagging and took a long time to respond. Is the delay always long or just for this one block?

That said, P2Pool will generate its own work if it knows that there is a new block (via its P2Pool peers) and bitcoind hasn't given it new work yet. These blocks will be empty, though. It's just a stopgap solution for bitcoind sometimes taking a long time to catch up.

In other news, a lot of users (or one big user) upgraded to v15 in the last day, and we'll probably be fine when BIP65 takes effect.

[-ck]

P2Pool should immediately call getblocktemplate after it knows that there is a new block. It is notified that there is a new block via its P2P connection to bitcoind, through which bitcoind sents an inv message when it has a new block. The code that does this is the work_poller in node.py. The reason that you saw a 18 second delay is something within that loop. Maybe bitcoind was lagging and took a long time to announce the block after it printed "new best"? Or maybe P2Pool was lagging and took a long time to respond. Is the delay always long or just for this one block?

Thanks for that. No this bitcoind is very rapid with its responses. It's set up the same as I use for my own pool. This happened routinely, not just the one block though. Here are the 3 before it:

Code:

2015-12-12 21:51:12.963648 UpdateTip: 
2015-12-12 21:51:32.679893 CreateNewBlock

2015-12-12 21:44:06.200074 UpdateTip:
2015-12-12 21:44:26.030397 CreateNewBlock

2015-12-12 21:42:07.479248 UpdateTip:
2015-12-12 21:42:26.094565 CreateNewBlock

I'm running current git master head.

That said, P2Pool will generate its own work if it knows that there is a new block (via its P2Pool peers) and bitcoind hasn't given it new work yet. These blocks will be empty, though. It's just a stopgap solution for bitcoind sometimes taking a long time to catch up.

EDIT:

Perhaps that actually explains these recent blocks then which are empty:
https://www.blocktrail.com/BTC/block/00000000000000000842de6ff4793f59ab08139a253f7e5622926f9d470c1ae9
https://www.blocktrail.com/BTC/block/000000000000000010e4a73a4abf8bd304809c021d636b1f39013ddf6e437d3c

[forrestv]

Hmm, can you apply this[1] patch to P2Pool and post the relevant log sections of both bitcoind and P2Pool?

1: http://im.forre.st/pb/80707844.txt

[-ck]

Hmm, can you apply this[1] patch to P2Pool and post the relevant log sections of both bitcoind and P2Pool?

1: http://im.forre.st/pb/80707844.txt

Running it now, will report back in a bit.

Captured one

Bitcoind:

Code:

2015-12-12 23:45:46.055397 UpdateTip: new best=0000000000000000057896223e152a585b48c27bfd0757f901116f4df1a026b2
2015-12-12 23:46:04.861979 CreateNewBlock()

p2pool:

Code:

2015-12-12 18:45:43.226373 work_poller sleeping
2015-12-12 18:45:44.580614 P2Pool: 17510 shares in chain (10184 verified/17514 total) Peers: 7 (0 incoming)
2015-12-12 18:45:44.580730  Local: 859GH/s in last 2.8 minutes Local dead on arrival: ~4.9% (3-7%) Expected time to share: 2.3 hours
2015-12-12 18:45:44.580780  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0018)=0.0018 BTC
2015-12-12 18:45:44.580821  Pool: 613TH/s Stale rate: 20.5% Expected time to block: 6.4 days
2015-12-12 18:45:46.060562 work_poller triggered 0
2015-12-12 18:45:46.591346 Skipping from block c961a121526cc3eea1788faec200b43ab71db3853833a8e to block 57896223e152a585b48c27bfd0757f901116f4df1a026b2!
2015-12-12 18:45:46.604193 New work for worker! Difficulty: 1300.617269 Share difficulty: 9373917.033071 Total block value: 25.000000 BTC including 0 transactions
2015-12-12 18:45:46.862936 Punishing share for 'Block-stale detected! height(c961a121526cc3eea1788faec200b43ab71db3853833a8e) < height(57896223e152a585b48c27bfd0757f901116f4df1a026b2) or 180de64f != 180de64f'! Jumping from 18b25839 to 301798e2!
2015-12-12 18:45:49.709867 work_poller sleeping
2015-12-12 18:45:49.723776 P2Pool: 17509 shares in chain (10184 verified/17514 total) Peers: 7 (0 incoming)
2015-12-12 18:45:49.723931  Local: 863GH/s in last 2.9 minutes Local dead on arrival: ~4.9% (3-7%) Expected time to share: 2.3 hours
2015-12-12 18:45:49.723991  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0017)=0.0017 BTC
2015-12-12 18:45:49.724073  Pool: 616TH/s Stale rate: 20.5% Expected time to block: 6.4 days
2015-12-12 18:45:51.569227 Punishing share for 'Block-stale detected! height(c961a121526cc3eea1788faec200b43ab71db3853833a8e) < height(57896223e152a585b48c27bfd0757f901116f4df1a026b2) or 180de64f != 180de64f'! Jumping from 18b25839 to 301798e2!
2015-12-12 18:45:51.578247 Punishing share for 'Block-stale detected! height(c961a121526cc3eea1788faec200b43ab71db3853833a8e) < height(57896223e152a585b48c27bfd0757f901116f4df1a026b2) or 180de64f != 180de64f'! Jumping from 18b25839 to 301798e2!
2015-12-12 18:45:52.095941 Peer sent entire transaction a2f01bd80b0b08eac507b98b7d4cfcebf291148f350e8d48f344b6d8dc295308 that was already received
2015-12-12 18:45:52.341543 Peer sent entire transaction c0dea60acb5a945e4dbfe490533555aa747b82cf358e5b81b311f97975061a76 that was already received
2015-12-12 18:45:52.734235 P2Pool: 17509 shares in chain (10184 verified/17514 total) Peers: 7 (0 incoming)
2015-12-12 18:45:52.734375  Local: 877GH/s in last 2.9 minutes Local dead on arrival: ~5.0% (3-7%) Expected time to share: 2.3 hours
2015-12-12 18:45:52.734432  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0017)=0.0017 BTC
2015-12-12 18:45:52.734493  Pool: 616TH/s Stale rate: 20.5% Expected time to block: 6.4 days
2015-12-12 18:45:55.739050 P2Pool: 17509 shares in chain (10184 verified/17514 total) Peers: 7 (0 incoming)
2015-12-12 18:45:55.739190  Local: 893GH/s in last 3.0 minutes Local dead on arrival: ~5.1% (3-7%) Expected time to share: 2.2 hours
2015-12-12 18:45:55.739244  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0017)=0.0017 BTC
2015-12-12 18:45:55.739283  Pool: 616TH/s Stale rate: 20.5% Expected time to block: 6.4 days
2015-12-12 18:45:56.595158 Punishing share for 'Block-stale detected! height(c961a121526cc3eea1788faec200b43ab71db3853833a8e) < height(57896223e152a585b48c27bfd0757f901116f4df1a026b2) or 180de64f != 180de64f'! Jumping from 18b25839 to 301798e2!
2015-12-12 18:45:56.606212 Punishing share for 'Block-stale detected! height(c961a121526cc3eea1788faec200b43ab71db3853833a8e) < height(57896223e152a585b48c27bfd0757f901116f4df1a026b2) or 180de64f != 180de64f'! Jumping from 18b25839 to 301798e2!
2015-12-12 18:45:57.728314 Peer sent entire transaction b162860a4358618d94e89809bea4f8471e3f581c0dc1f407faecda09676713a5 that was already received
2015-12-12 18:45:58.753944 P2Pool: 17509 shares in chain (10184 verified/17514 total) Peers: 7 (0 incoming)
2015-12-12 18:45:58.754053  Local: 940GH/s in last 3.0 minutes Local dead on arrival: ~5.2% (4-7%) Expected time to share: 2.1 hours
2015-12-12 18:45:58.754113  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0017)=0.0017 BTC
2015-12-12 18:45:58.754161  Pool: 616TH/s Stale rate: 20.5% Expected time to block: 6.4 days
2015-12-12 18:46:01.631496 Punishing share for 'Block-stale detected! height(c961a121526cc3eea1788faec200b43ab71db3853833a8e) < height(57896223e152a585b48c27bfd0757f901116f4df1a026b2) or 180de64f != 180de64f'! Jumping from 18b25839 to 301798e2!
2015-12-12 18:46:01.643085 Punishing share for 'Block-stale detected! height(c961a121526cc3eea1788faec200b43ab71db3853833a8e) < height(57896223e152a585b48c27bfd0757f901116f4df1a026b2) or 180de64f != 180de64f'! Jumping from 18b25839 to 301798e2!
2015-12-12 18:46:01.779099 P2Pool: 17509 shares in chain (10184 verified/17514 total) Peers: 7 (0 incoming)
2015-12-12 18:46:01.779293  Local: 955GH/s in last 3.1 minutes Local dead on arrival: ~5.2% (4-7%) Expected time to share: 2.1 hours
2015-12-12 18:46:01.779401  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0017)=0.0017 BTC
2015-12-12 18:46:01.779491  Pool: 616TH/s Stale rate: 20.5% Expected time to block: 6.4 days
2015-12-12 18:46:04.636870 New work for worker! Difficulty: 1413.903366 Share difficulty: 9448997.950860 Total block value: 25.114565 BTC including 2345 transactions
2015-12-12 18:46:04.823342 work_poller triggered 1
2015-12-12 18:46:04.835841 P2Pool: 17510 shares in chain (10185 verified/17515 total) Peers: 7 (0 incoming)
2015-12-12 18:46:04.835984  Local: 969GH/s in last 3.1 minutes Local dead on arrival: ~5.2% (4-7%) Expected time to share: 2.0 hours
2015-12-12 18:46:04.836040  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0017)=0.0017 BTC
2015-12-12 18:46:04.836098  Pool: 608TH/s Stale rate: 20.5% Expected time to block: 6.5 days
2015-12-12 18:46:06.747933 work_poller sleeping

EDIT: looks ok to me. Maybe it's just bitcoind hiding the call debug message. I'll investigate further at my end with more debugging in bitcoind, thanks.

Investigated further and added debugging to see when GBT was called since calls to CNB are cached and it is indeed calling GBT immediately after a blockchange, so this was all my fault for not noticing, sorry about the noise.

[windpath]

Edit:  Ouch - that DOA rate........

Almost 3 am, but...

What's normal/good?

Mine sits at about 3% - but it's a local private node.

Yeah, don't know what to make of it. The overnight run saw 9 shares come in total without any orphans or dead but of course you need about 100 shares to get a fair idea of the real efficiency. I can understand if you move your miner away and appreciate the testing you did initially to confirm it works though, thanks.

It's been a while since I've played with p2pool though and something is really bugging me that I spot in the logs. I was wondering if anyone could answer me since my python knowledge is almost non-existent. On block changes, I'm NOT seeing p2pool immediately ask for a new block template when looking at my bitcoind logs which I have extra debugging on. Take for example this last block:

The block came in here:

Code:

2015-12-12 21:11:05.242988 UpdateTip: new best

And p2pool asked for the first newblock template here:

Code:

2015-12-12 21:11:23.387677 CreateNewBlock

Note the timestamps. There are 18 seconds between the block change and the first block template request. Now on my pool software I get a new template within milliseconds of the block update.

So here's the question. Is p2pool by design not updating immediately on block changes and hashing on stale work? Am I missing something?

edit: see Forrest's answer above...

I *believe* (and may be incorrect) that p2pool will wait for a valid share (pool wide) before sending new work @ 30 seconds on average. I recall a couple years ago discussing this with someone. As P2Pool does not subscribe to bitcoind blocknotify it is not aware of the block change...

If I am right and this is the case, setting up a blocknotify flag in Bitcoin.conf and integrating it into the code should not be to hard, but I suspect there is a reason Forrest set it up this way? (Or maybe -blocknotify did not exist then?)

[-ck]

I *believe* (and may be incorect) that p2pool will wait for a valid share (pool wide) before sending new work @ 30 seconds on average. I recall a couple years ago discussing this with someone. As P2Pool does not subscribe to bitcoind blocknotify it is not aware of the block change...

If I am right and this is the case, setting up a blocknotify flag in Bitcoin.conf and integrating it into the code should not be to hard, but I suspect there is a reason Forrest set it up this way? (Or maybe -blocknotify did not exist then?)

Yeah sorry this was my mistake at misreading what debug output I had so it was a false positive.

Investigated further and added debugging to see when GBT was called since calls to CNB are cached and it is indeed calling GBT immediately after a blockchange, so this was all my fault for not noticing, sorry about the noise.