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

[DeathAndTaxes]

You do mean the dead on arrival pseudoshare rate, not the dead share rate, right?

By psueodshare I assume you mean the low diff share cgminer thinks it is mining?
Which DOA stat is for the diff 1 shares and which is for "full sharechain difficult shares?

DOA is reported in 3 ? places
1) In graphs both total and per miner
2) On the /static page

Code:

Local rate: 11.6GH/s (2.0% DOA)

3) In the console window (which I find myself using less and less).

It may have just been a timing issue.  I think this weekend I will restart p2pool w/ no historical stats and restart all miner instances to get a "baseline".

I am also trying to figure out an easy way to convert JSON file into relational db tables so I can do some deeper digging.

My hunch (and I would like to stress completely unfounded) is that there is some error in the p2pool.info stats.

I think this error comes from the double estimations.

The raw data is shares seen by p2pool node.
p2pool abstracts that into global hashrate averaged over 10? minutes
p2pool poools that hashrate every 5 min?
p2pool uses that to construct avg hashrate over the block
p2pool use that and block time to determine # of hashes in block
p2pool compares # of hashes in block vs expected # of hashes in block to get "luck"

I am wondering if there is a better way.  simply look at all the shares since last block.
diff 1 shares for block = sum of difficulty of shares seen by node since last block
right? 

[twmz]

I am wondering if there is a better way.  simply look at all the shares since last block.
diff 1 shares for block = sum of difficulty of shares seen by node since last block
right?  

I don't fully understand the internals of the share chain distribution, but I think there are a couple problems that would have to be solved:

• We have a significant number of blocks where the duration was longer than the length of the share chain.  So in order to add up shares after a block is found, I would have to invent my own persistence of the the share chain that never got cleaned up.  Not trivial or fun (and fun = motivation to do it)
• The "hashes done by the pool" include hashes contained in stale shares that are not fully distributed through the p2p network.  Because those stale shares mostly could have been valid blocks, they need to be included in the luck calculation.  In fact a lot of our blocks actually were stale shares (as determined by the fact that they often aren't announced in IRC).  The current p2pool hashrate calculation handles this by counting the valid shares and then increasing the count based on the pool-wide stale rate.

[twmz]

I am wondering if there is a better way.  simply look at all the shares since last block.
diff 1 shares for block = sum of difficulty of shares seen by node since last block
right?  

I don't fully understand the internals of the share chain distribution, but I think there are a couple problems that would have to be solved:

• We have a significant number of blocks where the duration was longer than the length of the share chain.  So in order to add up shares after a block is found, I would have to invent my own persistence of the the share chain that never got cleaned up.  Not trivial or fun (and fun = motivation to do it)
• The "hashes done by the pool" include hashes contained in stale shares that are not fully distributed through the p2p network.  Because those stale shares mostly could have been valid blocks, they need to be included in the luck calculation.  In fact a lot of our blocks actually were stale shares (as determined by the fact that they often aren't announced in IRC).  The current p2pool hashrate calculation handles this by counting the valid shares and then increasing the count based on the pool-wide stale rate.

It would be an interesting experiment (and much easier because you can ignore the first problem by picking blocks that are shorter than 18 or so hours) to spot check.  If you want to calculate how many hashes you think went into a few blocks, I can tell you how many hashes p2pool.info thinks went into it and we can see how much variation there is in the two methods.

[Red Emerald]

When do the rest of us get this page? This looks nice. http://p2pool.hopto.org:9332/static/nodes.html

[DeathAndTaxes]

I hadn't thought about the fact that blocks can be longer than sharechain. I see a couple work arounds
a) quick & dirty for analysis I could simply cron job to archive the sharechain at quicker interval than shares fall off the end and recombine it to get a continual history

b) slightly better would be looking into the code to make p2poool keep shares around longer and/or make it a command line param

As far as orphaned (but not DOA) shares I need to look at the code on propogation.  If they aren't fully distributed then how does a node calculate hashrate & stale (better called orphan) rate?  

The current p2pool hashrate calculation handles this by counting the valid shares and then increasing the count based on the pool-wide stale rate.

So following that train of thought how does an arbitrary node determined the stale (orphan) rate for the network?  My node right now says orphan rate is 8.9%.  How does it know?  It must be notified of all orphaned shares (either by receiving shares and incrementing its local orphan count or by some orphan share message).  My understanding is things like hashrate, orphan %, etc all all calculated locally.  We just need to tap into this.

BTW I am not expecting you to do any of this based on my hunch.  This weekend I will dive into the code and see if we can find a method to count shares (well technically sum of share difficulty).  If I can and it diverges from p2pool.info stats then we can look at using that to improve accuracy of the stats.  If it doesn't well then I was the only one who wasted his time.

[cabin]

I hadn't thought about the fact that blocks can be longer than sharechain. I see a couple work arounds
a) quick & dirty for analysis I could simply cron job to archive the sharechain at quicker interval than shares fall off the end and recombine it to get a continual history

b) slightly better would be looking into the code to make p2poool keep shares around longer and/or make it a command line param

As far as orphaned (but not DOA) shares I need to look at the code on propogation.  If they aren't fully distributed then how does a node calculate hashrate & stale (better called orphan) rate?  

The current p2pool hashrate calculation handles this by counting the valid shares and then increasing the count based on the pool-wide stale rate.

So following that train of thought how does an arbitrary node determined the stale (orphan) rate for the network?  My node right now says orphan rate is 8.9%.  How does it know?  It must be notified of all orphaned shares (either by receiving shares and incrementing its local orphan count or by some orphan share message).  My understanding is things like hashrate, orphan %, etc all all calculated locally.  We just need to tap into this.

BTW I am not expecting you to do any of this based on my hunch.  This weekend I will dive into the code and see if we can find a method to count shares (well technically sum of share difficulty).  If I can and it diverges from p2pool.info stats then we can look at using that to improve accuracy of the stats.  If it doesn't well then I was the only one who wasted his time.

Pages like this record tons of info about each share, and it is recording atleast some deads:
http://p2pool.hopto.org:9332/static/share.html#0000000000555d58d25a50651e47ec138edd63f4d7dfa868a9b679e160c79524

[cabin]

When do the rest of us get this page? This looks nice. http://p2pool.hopto.org:9332/static/nodes.html

You can save the html page to your own web-static/ folder and then you'll have it too

The ping times will be unique to where you are and the pools are hard coded from ones people wanted to be public. It is possible to grab a list of all your connected peers but maybe not everyone would appreciate that.

[Red Emerald]

When do the rest of us get this page? This looks nice. http://p2pool.hopto.org:9332/static/nodes.html

You can save the html page to your own web-static/ folder and then you'll have it too

The ping times will be unique to where you are and the pools are hard coded from ones people wanted to be public. It is possible to grab a list of all your connected peers but maybe not everyone would appreciate that.

Cool thanks.

Seems like hopto's ping time to my node is consistently less than the ping time to hopto. I guess I have a good network?

[Smoovious]

is it possible to show what version of p2pool the node is running, or is that not available?

also... woohoo! lowest ping time on your list!

138ms!

-- Smoov

[Red Emerald]

is it possible to show what version of p2pool the node is running, or is that not available?

also... woohoo! lowest ping time on your list!

138ms!

-- Smoov

I'm starting to think those are ping times from the client to the p2pool nodes, not the node to the other nodes. Loading the page from the miner would be most accurate.

[kano]

Meh - I somehow managed to post this in the BFL thread when I mean to post it here ...
OK fixing that, here it is here where it should be.

... and now I'll ask an evil question coz I'm curious about it ...

I added the code that did network block detection in cgminer.
It reports "BLOCK!" on BOTH Accepted and Rejected shares.
I've wondered in the past if anyone has ever had a Rejected "BLOCK!"
i.e. you found a block, but you were JUST unlucky enough to find it in the time frame where it would be Rejected
( of course people have, but they'd need to keep their logs and check them ... I do keep all my logs and sometimes check them Cheesy )

They should be rare but also easy to calculate how often you should get them ...
The Rejection rate of your shares is a percentage.
That Rejection rate is also the % of blocks you find that should also be a Rejected "BLOCK!"


... now for a code change suggestion ...

So if you get 10% of your shares rejected then 10% of the blocks you find should also be rejected ....................
However ........... of that 10% that get rejected, 98.3% of them would be accepted by the bitcoin block chain but are invalid for the share chain and are thus thrown away .............

(I also wonder if this is a factor in the luck discussion - but I've no idea if it is)

Yeah I think there should be an exception in the code to allow rejected shares, that match this circumstance, and enable support for the exception in the share chain
i.e. if you get a Rejected BLOCK! it should make it all the way to the bitcoind and then it's up to bitcoind to reject it if it was a real block chain LP (not a P2Pool share chain LP)
Of course if this was implemented: it would also mean that everyone mining with cgminer on P2Pool should enable submit stale
(and also P2Pool should tell all miners to submit stale shares)

[cabin]

is it possible to show what version of p2pool the node is running, or is that not available?

also... woohoo! lowest ping time on your list!

138ms!

-- Smoov

I'm starting to think those are ping times from the client to the p2pool nodes, not the node to the other nodes. Loading the page from the miner would be most accurate.

Yes, it is always the ping from your current computer to the node. Everyone will get different numbers and if your node is on your machine or on the same network your ping will be very low. In effect it shows you the node that will be best for you and you alone to connect to.

The version number isn't in the data below so I don't display it.
http://p2pool.hopto.org:9332/local_stats

[cabin]

Meh - I somehow managed to post this in the BFL thread when I mean to post it here ...
OK fixing that, here it is here where it should be.

... and now I'll ask an evil question coz I'm curious about it ...

I added the code that did network block detection in cgminer.
It reports "BLOCK!" on BOTH Accepted and Rejected shares.
I've wondered in the past if anyone has ever had a Rejected "BLOCK!"
i.e. you found a block, but you were JUST unlucky enough to find it in the time frame where it would be Rejected
( of course people have, but they'd need to keep their logs and check them ... I do keep all my logs and sometimes check them Cheesy )

They should be rare but also easy to calculate how often you should get them ...
The Rejection rate of your shares is a percentage.
That Rejection rate is also the % of blocks you find that should also be a Rejected "BLOCK!"


... now for a code change suggestion ...

So if you get 10% of your shares rejected then 10% of the blocks you find should also be rejected ....................
However ........... of that 10% that get rejected, 98.3% of them would be accepted by the bitcoin block chain but are invalid for the share chain and are thus thrown away .............

(I also wonder if this is a factor in the luck discussion - but I've no idea if it is)

Yeah I think there should be an exception in the code to allow rejected shares, that match this circumstance, and enable support for the exception in the share chain
i.e. if you get a Rejected BLOCK! it should make it all the way to the bitcoind and then it's up to bitcoind to reject it if it was a real block chain LP (not a P2Pool share chain LP)
Of course if this was implemented: it would also mean that everyone mining with cgminer on P2Pool should enable submit stale
(and also P2Pool should tell all miners to submit stale shares)

If a share is DOA or orphan it will still count as a real block. If you look at the source in main.got_response(header, request) the first thing it does is check if it is a real block. Only after that does it bother to check for DOA. CGminer will submit dead shares if you use --submit_stale, or if you are running a fairly recent version it will do this automatically. If you are using an old version of cgminer, and not using --submit_stale, then you could discard a valid block before it even reaches P2Pool.

[kano]

...
If a share is DOA or orphan it will still count as a real block. If you look at the source in main.got_response(header, request) the first thing it does is check if it is a real block. Only after that does it bother to check for DOA. CGminer will submit dead shares if you use --submit_stale, or if you are running a fairly recent version it will do this automatically. If you are using an old version of cgminer, and not using --submit_stale, then you could discard a valid block before it even reaches P2Pool.

So, you can confirm that a 10 second share that is effectively late (stale/rejected) will still make it all the way to bitcoind if it is a valid block?
So P2Pool already has this 2 way path?
A share that isn't valid for the share chain will still pay out to everyone and go to bitcoind if it is a block?
(or the share chain can also store invalid shares?)

If forrestv will confirm this - then that's good.

[twmz]

...
If a share is DOA or orphan it will still count as a real block. If you look at the source in main.got_response(header, request) the first thing it does is check if it is a real block. Only after that does it bother to check for DOA. CGminer will submit dead shares if you use --submit_stale, or if you are running a fairly recent version it will do this automatically. If you are using an old version of cgminer, and not using --submit_stale, then you could discard a valid block before it even reaches P2Pool.

So, you can confirm that a 10 second share that is effectively late (stale/rejected) will still make it all the way to bitcoind if it is a valid block?
So P2Pool already has this 2 way path?
A share that isn't valid for the share chain will still pay out to everyone and go to bitcoind if it is a block?
(or the share chain can also store invalid shares?)

If forrestv will confirm this - then that's good.

Here is the explaination forrest has given in IRC in the past...  If a share is stale/doa but still meets the current bitcoin difficulty requirements (aka it is a block), it is sent to the local p2pool node's bitcoind.  It is also sent to all of the node's peers.  Each of the peers also send the block to their own local bitcoind instances (in order to increase the speed of propagation through the bitcoin network).  However, each of the peers does not relay the stale share to any of their peers.

So it propagates partially through the p2pool p2p network and should be sent to at least 11 bitcoin nodes (1 bitcoin node from the finder of the block and the bitcoin nodes of the block finder's 10 outgoing p2pool connections).  If the block finder has any incoming p2pool connections, it will go to those p2pool peers as well.

A side effect of the fact that the stale share is not fully propagated through the p2pool network is that stale share/valid blocks are sometimes not announced on IRC because the IRC bots sometimes never hear about the stale share (because they are not a direct peer of the block finder).  We have seen this side effect several times (p2pool blocks have been found and not announced in IRC by any of the half dozen or so p2pool nodes that are connected to IRC and announcing blocks).

[Smoovious]

is it possible to show what version of p2pool the node is running, or is that not available?

also... woohoo! lowest ping time on your list!

138ms!

-- Smoov

I'm starting to think those are ping times from the client to the p2pool nodes, not the node to the other nodes. Loading the page from the miner would be most accurate.

Yes, it is always the ping from your current computer to the node. Everyone will get different numbers and if your node is on your machine or on the same network your ping will be very low. In effect it shows you the node that will be best for you and you alone to connect to.

The version number isn't in the data below so I don't display it.
http://p2pool.hopto.org:9332/local_stats

well, I thought the page was showing the ping times from his location since it was his page I was looking at.

Oh well.

If it is possible to lift the version # of the p2pools in the list, might be good to have it there, if you wanna pick a pool that is current.

-- Smoov

[kano]

...
Here is the explaination forrest has given in IRC in the past...  If a share is stale/doa but still meets the current bitcoin difficulty requirements (aka it is a block), it is sent to the local p2pool node's bitcoind.  It is also sent to all of the node's peers.  Each of the peers also send the block to their own local bitcoind instances (in order to increase the speed of propagation through the bitcoin network).  However, each of the peers does not relay the stale share to any of their peers.

So it propagates partially through the p2pool p2p network and should be sent to at least 11 bitcoin nodes (1 bitcoin node from the finder of the block and the bitcoin nodes of the block finder's 10 outgoing p2pool connections).  If the block finder has any incoming p2pool connections, it will go to those p2pool peers as well.

A side effect of the fact that the stale share is not fully propagated through the p2pool network is that stale share/valid blocks are sometimes not announced on IRC because the IRC bots sometimes never hear about the stale share (because they are not a direct peer of the block finder).  We have seen this side effect several times (p2pool blocks have been found and not announced in IRC by any of the half dozen or so p2pool nodes that are connected to IRC and announcing blocks).

So the fact that such a block doesn't make it to the share chain for most P2Poolers doesn't skew the statistics in any way?
... again in relations to the low stats people have been discussing ...

There's no difficulty looking through the block chain to find all the recent P2Pool shares,
(not sure about identifying blocks early on when P2Pool first started of course)
but does P2Pool itself record blocks that didn't get into the share chain - that it isn't notified of via the share chain?
(I've no idea - that's why I ask)

[DeathAndTaxes]

So the fact that such a block doesn't make it to the share chain for most P2Poolers doesn't skew the statistics in any way?
... again in relations to the low stats people have been discussing ...

It likely does just as if the pool is unaware of a orphaned share (which isn't a block) but the effect would be negligible.  

Even at avg diff of 800 only one in 700 shares is a block solution so the amount that not knowing about that share can affect stats is <1%.

If a node is unaware of any orphaned share it will affect things like luck calculations (but not payouts).

A block whose share is stale is no different than any other orphaned or DOA share with the exception that it is very rare.

There's no difficulty looking through the block chain to find all the recent P2Pool shares,
(not sure about identifying blocks early on when P2Pool first started of course)
but does P2Pool itself record blocks that didn't get into the share chain - that it isn't notified of via the share chain?
(I've no idea - that's why I ask)

p2pool doesn't need to know that it found a block because that doesn't affect
a) its work
b) its estimate on hashrate
c) reward split

sites like p2pool.info keep track of found blocks because miners like to know when to expect the next payment.  If your node was never notified on any p2pool block via the p2pool network it could still operate just fine (it will always be notified by bitcoind just like it is on any other found block).

Still I would think found blocks who's shares are oprhaned/DOA sould be replicated to every single p2pool node.  Getting the block broadcast from as many nodes as possible can only help block orphan rates.  Right?

[JayCoin]

What is going on?  It seems very strange that we don't solve a block all day and then solve three blocks in a row!?

[TheHarbinger]

To take a break from the serious conversations going on in this thread right now...


I just want you to know, I'm the one who found the block that broke the 23h 49m without a block drought.  No thanks necessary. But tips are, pay me bitches!