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

[organofcorti]

Please stop spreading FUD  P2pool is open source and there is nothing suspect in the code. Do you know what variability and luck is?

Yes, what I'm suggesting is that we may be having issues with orphaned blocks or some such issue.
Just saying, the odds of luck as bad as p2pool now displays is less than 1%

How are you calculating that?

[1713560078]

1713560078

[1713560078]

1713560078

[1713560078]

1713560078

[Ente]

Please stop spreading FUD  P2pool is open source and there is nothing suspect in the code. Do you know what variability and luck is?

I am far from suggesting there is any malicious intent in this. This does not make sense at all and contradicts everything I see in this thread.
Of course there won't be a "hey, I found a haxx0r backdoor in line 713 which steals our monies!!". And no, I don't plan to read the code, as I am not knowledgeable to do so.

But, obviously for me, there is a general and (now) constant problem nevertheless. I don't write this to hurt p2pool, the opposite is the case. There are enough outcries and "have to go back to xypool" here to justify a closer look, even without the problem being visible in the luck chart for weeks now.

Ente

[spiccioli]

Please stop spreading FUD  P2pool is open source and there is nothing suspect in the code. Do you know what variability and luck is?

All right.

This is what the "luck" graph looks like:
http://s17.postimage.org/pe2oth8vx/luck.png
(as can be seen here: http://u.forre.st/p2pool/luck.png)


This is what "variability and luck" would make me expect it look instead:
http://s17.postimage.org/45p0c1uf1/luck_green.png


But, in fact, it looks much more like this, which is not "variability and luck", but a inherent problem besides variability:
http://s17.postimage.org/rl6xhee65/luck_red.png

...

Ente, I'm not able to see your images, I had to answer your message and copy and paste urls (safari and firefox on a mac).

In this answer I've removed the img tag from the quote so that the url is clickable.

spiccioli

[Ente]

Ente, I'm not able to see your images, I had to answer your message and copy and paste urls (safari and firefox on a mac).

In this answer I've removed the img tag from the quote so that the url is clickable.

spiccioli

Thanks for the info.
I can see the images fine in that post..
Will check and repair.

Any one else, do you see the three pics?

Ente

[gyverlb]

Any one else, do you see the three pics?

I don't see them in your post above.

[Ente]

Strange, I could see the pics in firefox, where I uploaded them with. In another browser I couldnt see them neither.
I reuploaded to another host, hope it works now.

Thanks for the info, you two.

Ente

[Smoovious]

Please stop spreading FUD  P2pool is open source and there is nothing suspect in the code. Do you know what variability and luck is?

Nobody suggested anything suspect in it, just that something may still be wrong.

I have to agree. I'm no statistician, and maybe it would be worth having someone better versed in statistical analysis to pipe in, but if that one line is indeed a projection of what should be expected, and the other line, what we're actually getting, with variance added, we should expect those lines to cross and re-cross in several different places and continue to do so in the future.

The actual results line, when smoothed out, should be pretty close to the projections, but it is spending too much time below the projection, which would imply an issue somewhere with the actual results we're getting.

One thing the graphs do not suggest, which is correct? Is the actual results line reflecting something wrong, and the projection is correct, or is the actual results line correct, and there is something wrong with the calculation for the projection?

Is it possible to make similar graphs for other operating pools as well to compare against?

Nobody is suggesting that there is something hinky going on with the code, but just by looking at the statistics, after this long a run so far, that as long as this pattern continues, there is the increasing likelihood, of something not operating quite right somewhere.

It could just be the projection calculation too, who knows, but it begs looking into.

-- Smoov

[ChanceCoats123]

Please stop spreading FUD  P2pool is open source and there is nothing suspect in the code. Do you know what variability and luck is?

Nobody suggested anything suspect in it, just that something may still be wrong.

I have to agree. I'm no statistician, and maybe it would be worth having someone better versed in statistical analysis to pipe in, but if that one line is indeed a projection of what should be expected, and the other line, what we're actually getting, with variance added, we should expect those lines to cross and re-cross in several different places and continue to do so in the future.

The actual results line, when smoothed out, should be pretty close to the projections, but it is spending too much time below the projection, which would imply an issue somewhere with the actual results we're getting.

One thing the graphs do not suggest, which is correct? Is the actual results line reflecting something wrong, and the projection is correct, or is the actual results line correct, and there is something wrong with the calculation for the projection?

Is it possible to make similar graphs for other operating pools as well to compare against?

Nobody is suggesting that there is something hinky going on with the code, but just by looking at the statistics, after this long a run so far, that as long as this pattern continues, there is the increasing likelihood, of something not operating quite right somewhere.

It could just be the projection calculation too, who knows, but it begs looking into.

-- Smoov

I like the direction he's going. Maybe it's not a pool issue (maybe it is), but it could just be an issue with the graphs projecting incorrect values. Afterall, p2pool.info is an estimate of hashing speeds and such. It's using the estimated speed (based upon shares) to determine the overall speed of the pool and from there calculating the projected block time. I don't know if you have seen your miner's speeds according to p2pool.info, but my miner is 200mhash/sec faster than my cards are actually mining.

[DeathAndTaxes]

The still unanswered question remains:
Is p2pool in fact statistically "working", in the sense that 100 Th will yield the [statistically] same amount of blocks as 100 Th on a single bitcoind or centralized pool?

Ente

I'm beginning to suspect not.
back when the pool was at 91% luck over 90 days, the odds of it having such a poor reward after so much hashing was ~2%.

It was never 2% when @ 91% luck over 90 days.  I will run the probability numbers for current luck.

[kano]

Please stop spreading FUD   P2pool is open source and there is nothing suspect in the code. Do you know what variability and luck is?

Nobody suggested anything suspect in it, just that something may still be wrong.

I have to agree. I'm no statistician, and maybe it would be worth having someone better versed in statistical analysis to pipe in, but if that one line is indeed a projection of what should be expected, and the other line, what we're actually getting, with variance added, we should expect those lines to cross and re-cross in several different places and continue to do so in the future.

The actual results line, when smoothed out, should be pretty close to the projections, but it is spending too much time below the projection, which would imply an issue somewhere with the actual results we're getting.

One thing the graphs do not suggest, which is correct? Is the actual results line reflecting something wrong, and the projection is correct, or is the actual results line correct, and there is something wrong with the calculation for the projection?

Is it possible to make similar graphs for other operating pools as well to compare against?

Nobody is suggesting that there is something hinky going on with the code, but just by looking at the statistics, after this long a run so far, that as long as this pattern continues, there is the increasing likelihood, of something not operating quite right somewhere.

It could just be the projection calculation too, who knows, but it begs looking into.

-- Smoov

I like the direction he's going. Maybe it's not a pool issue (maybe it is), but it could just be an issue with the graphs projecting incorrect values. Afterall, p2pool.info is an estimate of hashing speeds and such. It's using the estimated speed (based upon shares) to determine the overall speed of the pool and from there calculating the projected block time. I don't know if you have seen your miner's speeds according to p2pool.info, but my miner is 200mhash/sec faster than my cards are actually mining.

Well, remember that a variance of 8 times is not all that rare when it comes to block times and share times.
So when your talking about a base multiplier of around whatever the difficulty is now (around 650?) your going to be waiting quite a long time before you'll expect to see some convergence on your expected hashrate.

Yesterday I ran an Icarus for over 3 hours on a standard pool and got 105% of my expected 1 difficulty share rate with 380MH/s
Multiply that 3 hours by 650 ...
For the first 5 minutes it was over 120% - not that uncommon also to have it vary a lot early on - again multiply that 5 minutes by 650 ... and you get over 2.25 days

The point of a pool is to reduce variance - and although p2pool does that like every other pool, it's base figures are around 650 times higher due to being 650 difficulty shares. So expect a lot longer to see your expected share rate (i.e. your average can be higher or lower for a lot longer)

(Edit: corrected that hash rate above )

[Shadow383]

Please stop spreading FUD  P2pool is open source and there is nothing suspect in the code. Do you know what variability and luck is?

Yes, what I'm suggesting is that we may be having issues with orphaned blocks or some such issue.
Just saying, the odds of luck as bad as p2pool now displays is less than 1%

How are you calculating that?

Binomial distribution - couldn't work out an average # for share difficulty throughout the life of p2pool, so took the values for shares submitted vs expected shares required for our current number of blocks from p2pool.info and assumed avg difficulty of 1.5 million. So N=somehugenumber, p=0.00000066667, k=actual shares found/p.

Not the best, but shouldn't be far off.

[DeathAndTaxes]

How does the p2pool know the # of dead shares?
Aren't DOA shares detected at the node level, rejected, and then never forwarded to peers?
Do the p2pool.info charts include dead shares?  If so they are slanting the luck measurements.

Note: the questions refer to dead, aka DOA, aka dead on arrival, aka "rejected" (in cgminer) not orphaned shares.

[cabin]

How does the p2pool know the # of dead shares?
Aren't DOA shares detected at the node level, rejected, and then never forwarded to peers?
Do the p2pool.info charts include dead shares?  If so they are slanting the luck measurements.

Note: the questions refer to dead, aka DOA, aka dead on arrival, aka "rejected" (in cgminer) not orphaned shares.

The dead shares are not relevant to the bad luck since they can actually solve for a block and result in everyone getting rewarded. P2Pool does look at them and double check if they solve a block before reporting back to cgminer as 'rejected'.

The type of problem we are looking for is exactly the opposite actually.. ie someone who is successfully submitting non-orphan, non-doa shares, but yet not finding any blocks. I can only think of far fetched scenarios under which this might happen but here are two such examples:

1) Someone modifies their p2pool code so they submit shares as normal but never submit a block. Stupid and unlikely, but theoretically possible.
2) Some obscure bug in some combination of bitcoind and p2pool, such that rarely a found block fails to be passed on to bitcoind (and yet shares and getworks continue to flow freely, the bug would have to only affect the case where it is an actual block solve)

As an example of 2), if anyone finds this line in your logs, congratulations.. you are the problem
"Error while processing potential block"

[DeathAndTaxes]

The dead shares are not relevant to the bad luck since they can actually solve for a block and result in everyone getting rewarded. P2Pool does look at them and double check if they solve a block before reporting back to cgminer as 'rejected'.

Of course they are relevent.  Most DOA can't solve a block.  They are stale (due to bitcoind LP) or invalid.  All pools have these (commonly called rejected).  They are never included in luck calculations because they weren't good work to begin with.

Say the average DOA rate is 3%.  If those 3% of shares (unpaid, worthless work) are included in luck calculations that the expected # of blocks will be inflated by 3% making the pool appear to be 3% unluckier.  No conventional pool includes rejected shares in their luck calculations.

As an example of how invalid it is to include DOA shares I could point my miners towards a normal pool and have the found shares also submitted to p2pool.  Obviously the shares wouldn't be valid for p2pool so it would be a 100% DOA rate.  If the DOA rate is/was included in luck calculations then I made the pool appear x% unluckier.

So I will ask again.
1) HOW does p2pool network know the DOA rate?
2) Are they included in p2pool.info luck calculations?

[DeathAndTaxes]

1) Someone modifies their p2pool code so they submit shares as normal but never submit a block. Stupid and unlikely, but theoretically possible.
2) Some obscure bug in some combination of bitcoind and p2pool, such that rarely a found block fails to be passed on to bitcoind (and yet shares and getworks continue to flow freely, the bug would have to only affect the case where it is an actual block solve)

Regarding #2 doesn't the local p2pool node pass the block to p2pool peers also.  So a failure on one node's bitcoind would prevent block propagation.  Now it may result in slower block propagation so we should see that in a higher block orphan rate (which we don't) rather than just lower luck.

If I am mistaken and p2pool node doesn't do that this may be a way to make the network "stronger" so that the failure of one bitcoind can't lower block finding rate.

[cabin]

The dead shares are not relevant to the bad luck since they can actually solve for a block and result in everyone getting rewarded. P2Pool does look at them and double check if they solve a block before reporting back to cgminer as 'rejected'.

Of course they are relevent.  Most DOA can't solve a block.  They are stale (due to bitcoind LP) or invalid.  All pools have these (commonly called rejected).  They are never included in luck calculations because they weren't good work to begin with.

Say the average DOA rate is 3%.  If those 3% of shares (unpaid, worthless work) are included in luck calculations that the expected # of blocks will be inflated by 3% making the pool appear to be 3% unluckier.  No conventional pool includes rejected shares in their luck calculations.

As an example of how invalid it is to include DOA shares I could point my miners towards a normal pool and have the found shares also submitted to p2pool.  Obviously the shares wouldn't be valid for p2pool so it would be a 100% DOA rate.  If the DOA rate is/was included in luck calculations then I made the pool appear x% unluckier.

So I will ask again.
1) HOW does p2pool network know the DOA rate?
2) Are they included in p2pool.info luck calculations?

I believe most DOA CAN solve a block in P2Pool's case. They are only DOA with regard to the 10 second shares, but they are probably hashing away on a perfectly valid 10 minute real block. I'm not 100% on this though. And I see your point.. in the extreme case a terribly connected miner, who will never solve a real block, could be hashing away and getting say 50% stales and 50% DOA. He is not getting any shares and so is not hurting the rest of us, but his hashes may be skewing the luck. Again I'm not 100% on this either.

[cabin]

1) Someone modifies their p2pool code so they submit shares as normal but never submit a block. Stupid and unlikely, but theoretically possible.
2) Some obscure bug in some combination of bitcoind and p2pool, such that rarely a found block fails to be passed on to bitcoind (and yet shares and getworks continue to flow freely, the bug would have to only affect the case where it is an actual block solve)

Regarding #2 doesn't the local p2pool node pass the block to p2pool peers also.  So a failure on one node's bitcoind wouldn't prevent block propagation.  Now it may result in slower block propagation so we should see that in a higher block orphan rate (which we don't) rather than just lower luck.

If I am mistaken and p2pool node doesn't do that this may be a way to make the network "stronger" so that the failure of one bitcoind can't lower block finding rate.

That is a good question.. the code that would do this would start at around line 577 in main.py.. and in looking it may not in fact recover from this, it seems to just log an error. But I'm going to shutup and let forrestv answer this one.

[DeathAndTaxes]

They are only DOA with regard to the 10 second shares, but they are probably hashing away on a perfectly valid 10 minute real block.

DOA simply means the share is invalid by the time the local node gets it.  Don't make any assumptions beyond that.  Conventional pools reject a sizable number of shares and they have no 10 sec LP.  "Some" DOA may still be valid but not all of them are.

And I see your point.. in the extreme case a terribly connected miner, who will never solve a real block, could be hashing away and getting say 50% stales and 50% DOA.

The "horrible" miner is just an example.  IF (and I am not sure they are) DOA are included in p2pool.info luck calculations they will skew them.

[cabin]

They are only DOA with regard to the 10 second shares, but they are probably hashing away on a perfectly valid 10 minute real block.

DOA simply means the share is invalid by the time the local node gets it.  Don't make any assumptions beyond that.  Conventional pools reject a sizable number of shares and they have no 10 sec LP.  "Some" DOA may still be valid but not all of them are.

And I see your point.. in the extreme case a terribly connected miner, who will never solve a real block, could be hashing away and getting say 50% stales and 50% DOA.

The "horrible" miner is just an example.  IF (and I am not sure they are) DOA are included in p2pool.info luck calculations they will skew them.

My understanding is that > 98% of P2pool's DOA's have the potential to solve a block. The only ones that would not be useful are those DOA's that came right after a real block chain LP, ie once every 10 minutes. This also matches up well with the 1-2% of shares that regular pools reject, and I agree, 100% of these regular pool rejects are useless and have no chance of solving a block.

[DeathAndTaxes]

My understanding is that > 98% of P2pool's DOA's have the potential to solve a block. The only ones that would not be useful are those DOA's that came right after a real block chain LP, ie once every 10 minutes. This also matches up well with the 1-2% of shares that regular pools reject, and I agree, 100% of these regular pool rejects are useless and have no chance of solving a block.

Your numbers don't make sense.

You agree conventional pools have 1% to 2% stales due to bitcoin LP and invalid hashes.  Let's say 1.5%.   If 98% of p2pool DOA were NOT due to those reasons then 2% of them are.  Thus 1.5%/2% = 75% it would have an overall DOA rate of 75%.  For 98% of p2pool DOA to be due to 10 sec LP then it would need to have a DOA rate of 75%.  Obviously the % due to 10s LP is much lower.

If p2pool has a 4% DOA rate (??) and 1.5% of that is due to Bitcoin LP and invalid hashes then they make up ~40% of all DOAs.

Still I think I was confused.  p2pool doesn't track global DOA only global "stales" which if forrest can verify I believe is orphans only.


One correction:

The only ones that would not be useful are those DOA's that came right after a real block chain LP, ie once every 10 minutes.

You are forgetting invalid hashes.  No GPU produces 100% flawless hashes.  Some % (0.1% to 1% depending on overclock, temps, ASIC quality, etc) are just bad.  Nonsense hashes that solve no block.

TL/DR version

Conventional pool rejected shares = invalid hashes + stale hashes (after Bitcoin LP)
p2pool DOA shares = invalid hashes + stale hashes (after Bitcoin LP) + "pre-orphaned" hashes (hash that would be 100% orphaned it submitted)
Only the last one is valid work which can solve a block.