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

[PatMan]

Please contact me, I'd like to give you a private node address...

Hilarious.

I'd like to offer him my wife......

[Prelude]

Sweet, back to back blocks!  

Edit: And only 1 second apart.. 

[RoadStress]

Sweet, back to back blocks!  

Edit: And only 1 second apart.. 

CoinCadence is showing them as 30s apart. Any idea why is it showing as 0.00% luck?

[PatMan]

Cos it was pure skill......? 

[windpath]

Sweet, back to back blocks!  

Edit: And only 1 second apart.. 

CoinCadence is showing them as 30s apart. Any idea why is it showing as 0.00% luck?

Lol, they are to close together for my luck calculator to handle.....

Definitely a new P2Pool record...

I'll figure it out manually when I have some time.

Expected time to block ~ 15 hours

Actual time to block varies by what node you look at:
Coin Cadence recoded them 30 seconds apart
BlockChain has them 1:53 apart

[Prelude]

Sweet, back to back blocks!  

Edit: And only 1 second apart.. 

CoinCadence is showing them as 30s apart. Any idea why is it showing as 0.00% luck?

Lol, they are to close together for my luck calculator to handle.....

Definitely a new P2Pool record...

I'll figure it out manually when I have some time.

Expected time to block ~ 15 hours

Actual time to block varies by what node you look at:
Coin Cadence recoded them 30 seconds apart
BlockChain has them 1:53 apart

Weird, wonder why my local node shows them 1 second apart?

[windpath]

Its the network propagation time...

Some quick back of the napkin math using blockchains times puts block 329,431's luck at 47,368.42% 180,136.66% (see edit)

To put that in prospective our previous record luck (since I have been recording data) is block 313,299 (July 31) at 12,519.64%, that block took about 9:30...

Block 313,299: http://minefast.coincadence.com/p2pool-stats.php?blockoffset=213

Edit: Ok, here is the math...

Expected seconds to block = Difficulty * 2**32 / hashrate

Current bitcoin difficulty = 39,603,666,252
P2Pool Hashrate at time block found = 3,147.55 TH/s = 3,147,550,000,000,000 H/s

39,603,666,252 * 2**32 / 3,147,550,000,000,000 = 54,040.9 expected seconds to block

Luck % = Expected Time / Actual Time * 100

(54,041 / 30) * 100 = 180,136.66%

I'd love for someone to check the math....

[norgan]

Guys, I have low getblock latency, Matt's relay, plenty of bitcoind peers and a handful of p2pool peers yet I'm seeing almost 50% orphan shares. What could be the issue?

[windpath]

Guys, I have low getblock latency, Matt's relay, plenty of bitcoind peers and a handful of p2pool peers yet I'm seeing almost 50% orphan shares. What could be the issue?

I would try and find some closer peers and add them with -n when starting p2pool...

Only 2 of your peers are under 100ms away, the others are much further:

"218.16.212.194:9333": 335.9999656677246
"115.70.176.17:9333": 14.999866485595703
"178.63.18.3:9333": 312.999963760376
"59.167.237.19:9333": 31.000137329101562
"198.72.112.205:9333": 226.99999809265137
"73.20.171.64:9333": 233.99996757507324
"58.22.92.36:51905": 359.9998950958252
"92.251.43.47:1138": 383.00013542175293
"185.59.16.32:9333": 296.9999313354492
"95.154.200.216:9333": 289.0000343322754

[norgan]

Guys, I have low getblock latency, Matt's relay, plenty of bitcoind peers and a handful of p2pool peers yet I'm seeing almost 50% orphan shares. What could be the issue?

I would try and find some closer peers and add them with -n when starting p2pool...

Only 2 of your peers are under 100ms away, the others are much further:

"218.16.212.194:9333": 335.9999656677246
"115.70.176.17:9333": 14.999866485595703
"178.63.18.3:9333": 312.999963760376
"59.167.237.19:9333": 31.000137329101562
"198.72.112.205:9333": 226.99999809265137
"73.20.171.64:9333": 233.99996757507324
"58.22.92.36:51905": 359.9998950958252
"92.251.43.47:1138": 383.00013542175293
"185.59.16.32:9333": 296.9999313354492
"95.154.200.216:9333": 289.0000343322754

Yeah that's because the server is in Australia. Not many peers to choose from nearby.

[jonnybravo0311]

Its the network propagation time...

Some quick back of the napkin math using blockchains times puts block 329,431's luck at 47,368.42% 180,136.66% (see edit)

To put that in prospective our previous record luck (since I have been recording data) is block 313,299 (July 31) at 12,519.64%, that block took about 9:30...

Block 313,299: http://minefast.coincadence.com/p2pool-stats.php?blockoffset=213

Edit: Ok, here is the math...

Expected seconds to block = Difficulty * 2**32 / hashrate

Current bitcoin difficulty = 39,603,666,252
P2Pool Hashrate at time block found = 3,147.55 TH/s = 3,147,550,000,000,000 H/s

39,603,666,252 * 2**32 / 3,147,550,000,000,000 = 54,040.9 expected seconds to block

Luck % = Expected Time / Actual Time * 100

(54,041 / 30) * 100 = 180,136.66%

I'd love for someone to check the math....

Using the blockchain, you get

Code:

{
	"height" : 329431, 
	"hash" : "0000000000000000019bf01c784eb86ce651a072f667da0ec1b71e53b2f2c517",
	"time" : 1415637083,
	"main_chain" : true
},

{
	"height" : 329430, 
	"hash" : "000000000000000002b8cd492e2428d4f95047a591c89975e63a474c8d3b7c21",
	"time" : 1415636970,
	"main_chain" : true
},

329431 found Mon, 10 Nov 2014 16:31:23 GMT
329430 found Mon, 10 Nov 2014 16:29:30 GMT

Just shy of two minutes apart (113 seconds).  Plugging those numbers in you get a luck percentage of 47823.81.

[kano]

The block header "Time" is not in any way considered accurate.
It can be in the past or future of when the block was found.

For those 2 ... I'll look up when I actually saw them:

NB 2014-11-10 16:30:12+00 | bc : 000000000000000002b8cd492e2428d4f95047a591c89975e63a474c8d3b7c21
NB 2014-11-10 16:30:41+00 | bc : 0000000000000000019bf01c784eb86ce651a072f667da0ec1b71e53b2f2c517

So they were actually closer, only 29 seconds apart.
However, you also have the issue of the p2pool hash rate not being all that accurate.

[windpath]

The block header "Time" is not in any way considered accurate.
It can be in the past or future of when the block was found.

For those 2 ... I'll look up when I actually saw them:

NB 2014-11-10 16:30:12+00 | bc : 000000000000000002b8cd492e2428d4f95047a591c89975e63a474c8d3b7c21
NB 2014-11-10 16:30:41+00 | bc : 0000000000000000019bf01c784eb86ce651a072f667da0ec1b71e53b2f2c517

So they were actually closer, only 29 seconds apart.
However, you also have the issue of the p2pool hash rate not being all that accurate.

Yep, noted... For the calculation I went with when my node was first notified, 30 seconds apart....

What is the best method to store block time?

Not a better solution for pool hash rate I'm aware of...

[kano]

The block header "Time" is not in any way considered accurate.
It can be in the past or future of when the block was found.

For those 2 ... I'll look up when I actually saw them:

NB 2014-11-10 16:30:12+00 | bc : 000000000000000002b8cd492e2428d4f95047a591c89975e63a474c8d3b7c21
NB 2014-11-10 16:30:41+00 | bc : 0000000000000000019bf01c784eb86ce651a072f667da0ec1b71e53b2f2c517

So they were actually closer, only 29 seconds apart.
However, you also have the issue of the p2pool hash rate not being all that accurate.

Yep, noted... For the calculation I went with when my node was first notified, 30 seconds apart....

What is the best method to store block time?

Ah yep, I was looking at the times jonnybravo0311 used.
Since you got yours from your p2pool log, yep they'd be accurate (and more accurate than me)
I do (usually and currently) have p2pool running so I could have checked that log also

Not a better solution for pool hash rate I'm aware of...

Nope, the p2pool hash rate is what it is
In the arena of what the rate is, but not very accurate.

You can see this by grepping for "Pool:.*Stale" in the logfile.

Here over the last few minutes:
2014-11-09 01:36:02.720179  Pool: 4604TH/s Stale rate: 14.9% Expected time to block: 10.3 hours
2014-11-09 01:36:05.726034  Pool: 4587TH/s Stale rate: 15.5% Expected time to block: 10.3 hours
2014-11-09 01:36:17.739654  Pool: 4464TH/s Stale rate: 14.9% Expected time to block: 10.6 hours
2014-11-09 01:36:20.744880  Pool: 4412TH/s Stale rate: 14.9% Expected time to block: 10.7 hours
2014-11-09 01:36:35.758069  Pool: 4412TH/s Stale rate: 14.9% Expected time to block: 10.7 hours
2014-11-09 01:36:50.773637  Pool: 4412TH/s Stale rate: 14.9% Expected time to block: 10.7 hours
2014-11-09 01:37:05.789544  Pool: 4412TH/s Stale rate: 14.9% Expected time to block: 10.7 hours
2014-11-09 01:37:11.870958  Pool: 4521TH/s Stale rate: 14.9% Expected time to block: 10.4 hours

It seems to think it varied by 5%

[Redwing91]

Need some help,  

A friend  and I are mining on two different systems.  I have an S3+ and S1 on p2pool - decentralized mining using Windows 7.  My friend is also mining an S3+ and S1  mining on Linux.  

So here is both our problems. After we start bitcoin-qt / core and it is updated. We then both start our p2pool programs and for 5 days we both are mining along getting shares any where from .0039 to .01xxx.  but after 5 days we see .0000 btc and both of us try to reboot But on the restarts after 2 days we are still setting at .0000 btc, with stale rate and efficiency showing .   Is there a setting that we are missing to avoid p2pool to fail in collecting payouts for us, but continues to mine for shares?

[windpath]

Need some help,  

A friend  and I are mining on two different systems.  I have an S3+ and S1 on p2pool - decentralized mining using Windows 7.  My friend is also mining an S3+ and S1  mining on Linux.  

So here is both our problems. After we start bitcoin-qt / core and it is updated. We then both start our p2pool programs and for 5 days we both are mining along getting shares any where from .0039 to .01xxx.  but after 5 days we see .0000 btc and both of us try to reboot But on the restarts after 2 days we are still setting at .0000 btc, with stale rate and efficiency showing .   Is there a setting that we are missing to avoid p2pool to fail in collecting payouts for us, but continues to mine for shares?

If it was mining effectively (and you received a payout) chances are you are both just in a streak of bad luck, ~600 GH/s is close to the minimum threshold to expect a payout in every block.

Do you show active shares in the share chain?

Since you both have the same gear, if you guys trust each other it might be worthwhile to both mine to the same address (or set up a multisig) so that overall you are closer to 1.2 TH/s and will have a better shot of keeping a share on the chain, then splitting the payout at some interval....

Supplying the node address would be helpful in troubleshooting...

[kano]

Remember that variance is high on p2pool especially when considering a tiny 600GHs

Pool share required is ~18 million, so:
600GHs average expected time to find a share with 600GHs at the moment is ~36hours.
If you don't find a share, you wont get anything.

800% variance on that (which is rare but not unheard of) means 286 hours ...

[bicer]

Guys, I have low getblock latency, Matt's relay, plenty of bitcoind peers and a handful of p2pool peers yet I'm seeing almost 50% orphan shares. What could be the issue?

I would try and find some closer peers and add them with -n when starting p2pool...

Only 2 of your peers are under 100ms away, the others are much further:

"218.16.212.194:9333": 335.9999656677246
"115.70.176.17:9333": 14.999866485595703
"178.63.18.3:9333": 312.999963760376
"59.167.237.19:9333": 31.000137329101562
"198.72.112.205:9333": 226.99999809265137
"73.20.171.64:9333": 233.99996757507324
"58.22.92.36:51905": 359.9998950958252
"92.251.43.47:1138": 383.00013542175293
"185.59.16.32:9333": 296.9999313354492
"95.154.200.216:9333": 289.0000343322754

Yeah that's because the server is in Australia. Not many peers to choose from nearby.

Maybe this will help https://bitcointalk.org/index.php?topic=766190.0

[kano]

...
Maybe this will help https://bitcointalk.org/index.php?topic=766190.0

He runs one of the relay nodes

[PatMan]

Bitmain announce their new p2pool software......check it out:

https://bitcointalk.org/index.php?topic=855548.new#new