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

[roy7]

Having written that, I'm wondering how the payouts are affected by long droughts between block finds, and hope someone can clarify things for me.

Hi jonnybravo0311. I will try to help.

Example 1: Miner finds a valid share every 4 hours.  Pool finds a block every 24 hours.
This is the average example, so I would expect payout to be right on that 0.01BTC per day.  Is my understanding correct?

Yes. BTC has a SPREAD of 3 and a maximum share chain of 3 days worth of shares. If block times get over 1 day on average, the share window will be smaller than SPREAD since we hit the 3 day cap, but your example fits perfectly.

Since shares are good for 3 days in your example, after mining 3 days if we're nailing the average like clockwork, you'd have 18 shares in the share chain (6 per day * 3 days). So the value of a share would be .01 BTC / 18 so that your one block per day pays out .01 to you.

Example 2: Miner finds a valid share every 4 hours.  Pool finds a block every 96 hours.
In this example, the miner is still working and finding shares; however the pool has hit a string of bad luck and doesn't find a block for 4 days.  Does the miner get rewarded for having submitted shares successfully during the entire 96 hours, or will only a given window of those shares be counted?  In other words, when the pool finds the block, does the miner get paid for 4 days of work, or 1?  My understanding is that this is a bad luck case, and the miner would only get the expected 0.01BTC once the pool finds the block.  Is my understanding correct?

So we're assuming the pool is supposed to find a block every 24 hours on average, but it is a really long round. Nothing really changes. You have 18 shares in the chain that total .01 of value, when this block is found you are paid .01. So you've made less income over these 4 days because of bad pool luck. I don't know what CDF a 4x longer than expect block is (it could be calculated but I'm doing my taxes and I'm tired), but keep in mind the 5% chance you hit a bad luck 95% CDF round is the same as the 5% chance you hit a 5% CDF round. Over a long enough period of time the average CDF of all blocks found should be 50%.

Example 3: Miner finds 4 invalid shares (orphans) per day.  Pool finds a block every 24 hours.
Here the miner's shares are beat getting into the share chain - at least that is what I assume orphaned means, if my understanding is wrong, then please define orphaned and dead shares as they relate to p2pool.  My understanding here is that the miner would not be paid out anything because all of the shares submitted are invalid.  Is this correct?

You have zero shares and so get paid nothing. Orphan rates should be somewhat similar across the p2pool networks, but a node that is super fast and efficient might have a lower orphan rate than some other poorly connected slow node. This gives an advantage to the better/faster nodes. The efficiency % in most interfaces is a way to try and measure that.

Example 4: Miner finds 4 valid shares a day for 3 days, but finds all invalid shares on the 4th day.  Pool finds block on the 5th day.
So, the miner has been chugging along for 4 days, happily submitting shares.  Unfortunately on the 4th day all of the submitted shares were invalid.  If things follow the pattern I've laid out in previous examples, then the miner doesn't get paid for his efforts because the only shares seen in the past 24 hours are invalid ones.  Is my understanding correct?

At the time the block is found you have 2 days of shares in the share chain (since day 3 was all orphans). That means 12 shares instead of 18 shares, giving you 2/3 of your normal payment. .00666666 instead of .01.

The max share chain length was increased to 3 days instead of 1 day at some point in the past, when the share chain was slowed down from 10 seconds to 30 seconds.

Example 5: Miner finds 8 valid shares in a day.  Pool finds 2 blocks a day.
Since the examples have been all doom and gloom up to this point, let's look at the other side of the coin - where lady luck shines on us a bit.  Here the miner is finding and submitting twice the expected amount of work and the pool is finding double the number of blocks.  In this case, I expect that the miner would be making 4 times the expected payout.  Twice as much because he's finding double the shares and twice as much again because the pool is finding 2 blocks in that 24 hour window.  Is this correct?

If you are supposed to find 6 shares/day at your hash rate but get lucky and find 8 instead, then you're making about 1/3 more than normal. Or .01333333 per block instead of .01. If the pool is supposed to be finding 1 block a day but is constantly lucky and finding 2 instead, then you are getting two .01333333 payments per day. In total making .02666666 vs .01 per day. Of course, you are equally likely to have bad luck in the opposite direction and given enough time it will average out to .01/day.

I hope 1- this helps, and 2- I didn't actually get any of this wrong.

[1714048383]

1714048383

[1714048383]

1714048383

[1714048383]

1714048383

[1714048383]

1714048383

[1714048383]

1714048383

[smooth]

Example 3: Miner finds 4 invalid shares (orphans) per day.  Pool finds a block every 24 hours.
Here the miner's shares are beat getting into the share chain - at least that is what I assume orphaned means, if my understanding is wrong, then please define orphaned and dead shares as they relate to p2pool.  My understanding here is that the miner would not be paid out anything because all of the shares submitted are invalid.  Is this correct?

You can simplify your thinking on this significantly. Orphan shares are virtually the same as not having found the share in the first place. What matters is your rate of finding valid shares (compared to the pool's rate of valid shares).

The only way in which orphan shares might be different from never finding the share at all is that they could actually find a bitcoin block, but that is so rare they can be ignored.

Your earnings are determined by your rate (and, in the short term, timing) of your VALID shares, plus the blocks found by the pool. That's all that matters.

[IYFTech]

Sharing the alert:


Get 0.9.1 immediately if you are using 0.9.0!!  See the alert on the top:

News: ♦♦ A bug in OpenSSL, used by Bitcoin-Qt/Bitcoin Core, could allow your bitcoins to be stolen. Immediately updating Bitcoin Core to 0.9.1 is required in some cases, especially if you're using 0.9.0.

!!!!!

https://bitcoin.org/bin/0.9.1/

M

Glad I stuck to v8.6.0.......Think I'll leave this alone as well for a while.

[jonnybravo0311]

smooth and roy7, thanks for taking the time and providing the explanation.  Just to make sure I've got everything correct, ultimately it works out to be:

Shares are counted in a rolling 3 day window.  Every block found during that time is paid out based upon how many valid shares a miner has contributed during that 3 day window.

So, to use a concrete example, I'm running an Antminer S1 @ 200GH/s on a local p2pool node.  I've had it setup and running for a week at this point.  I'll have to shut it down for a bit tonight to upgrade to 0.9.1, but that will take like 5 minutes tops.  During this week, p2pool has found 3 blocks, and I received payouts for each.  Now it's been nearly 4 days since a block was found.  When that block is found, assuming I continue on without interruption and I find about 6 shares a day, I'll get 18 shares worth of payment from that block, and from every block found until my rate of found shares goes down.

Again, thanks for taking the time and providing the explanation!

[smooth]

Now it's been nearly 4 days since a block was found.  When that block is found, assuming I continue on without interruption and I find about 6 shares a day, I'll get 18 shares worth of payment from that block, and from every block found until my rate of found shares goes down.

Mostly correct. Not necessarily exactly 18 shares worth. If that's your average then it might be a little higher or lower than that.

Also, remember, its only valid shares that count. Invalid shares don't exist except on a stats page.

[roy7]

Again, thanks for taking the time and providing the explanation!

My pleasure. Here's my one S1 that I own:

http://us-east.royalminingco.com:9332/static/miner.html?id=1Gtt49xTxD3udiKcMfuzK37oJu1pGbnr8A

Click on Week or Month and you can see more of my share value history over time.

Also remember for BTC the 3 day thing is just the max capacity of the window. It's really supposed to be 3 blocks worth of work on average. So once the pool start finding blocks faster than 1/day, shares will last less than 3 days.

[jonnybravo0311]

Again, thanks for taking the time and providing the explanation!

My pleasure. Here's my one S1 that I own:

http://us-east.royalminingco.com:9332/static/miner.html?id=1Gtt49xTxD3udiKcMfuzK37oJu1pGbnr8A

Click on Week or Month and you can see more of my share value history over time.

Also remember for BTC the 3 day thing is just the max capacity of the window. It's really supposed to be 3 blocks worth of work on average. So once the pool start finding blocks faster than 1/day, shares will last less than 3 days.

Looking at your stats...

1) I like the front end by John Doe.  Very clean!
2) You don't have a single orphaned/dead share.  I wish I were so lucky.  After restarting my local node last night from upgrading to 0.9.1 I have found 2 shares, 1 of them is an orphan.  Over the past few days I've noticed my orphan rate has gone way up... from getting maybe 1 orphaned share in the first 15 shares I found, to getting a streak of about 8 orphaned shares in a row.

I know there have been tons of write-ups done on how to tune your local node, and I've read through them.  Unfortunately I'm just consistently getting a ton of orphans.  I'll keep trying to tune things to see if I can reduce the orphan rate.  Perhaps you could offer up some further suggestions?  Here's my setup:

Bitcoin-Qt and p2pool latest versions are running on a quad-core i7 (4850HQ @ 2.3GHz) with 16G RAM and a 512G PCI-e SSD.  It is on a wired gigabit internal network connected to the outside world at 35Mbps down 10Mbps up.  There is virtually no other traffic on this network (an iPhone and an iPad).  I have opened up ports 9332, 9333, 8333.  I have also tried a few of the different settings in bitcoin.conf (changing block size up and down, setting max connections from values of 6 to 50, etc).  I'm hashing away with an Antminer S1 over clocked to 200GH/s @ 393MHz with ~0.1% HW.  The S1 is on the latest firmware.  Yes, it's wired into the network (not wireless).

The biggest culprit I see is over the past week the reported Bitcoind GetBlock Template Latency has a mean of 0.572s (572ms seems way too high).  Over the past day, the mean is 372ms, which I feel is still ridiculously high.  Am I correct in my assumption here that this latency is likely what is causing me the pain?

Also, to give you an example of how things look, since I restarted everything last night after the upgrade, (11+ hours ago) I've found 2 shares, 1 of which is an orphan - effectively then 1 share added to the share chain.  I can certainly accept that it is taking me longer than the "expected" time to find shares.  Unfortunately, when I finally *do* find that share and it is then orphaned, it really has a negative impact.

[roy7]

2) You don't have a single orphaned/dead share.  I wish I were so lucky.  After restarting my local node last night from upgrading to 0.9.1 I have found 2 shares, 1 of them is an orphan.  Over the past few days I've noticed my orphan rate has gone way up... from getting maybe 1 orphaned share in the first 15 shares I found, to getting a streak of about 8 orphaned shares in a row.

Oh I've had some. I just restarted it a day or two ago. I was trying to find some ways to reduce the orphans further. I guess I could plot orphaned shares too. Next step for the interface is to add a list of all shares at the bottom like recent blocks.

I know there have been tons of write-ups done on how to tune your local node, and I've read through them.  Unfortunately I'm just consistently getting a ton of orphans.  I'll keep trying to tune things to see if I can reduce the orphan rate.  Perhaps you could offer up some further suggestions?

The main thing I'm trying at the moment is using -n to connect to the largest public nodes I can find. This way my shares might get spread more quickly, and/or I'll get updated on someone else's shares more quickly. I added the couple nodes with the highest hash rate I could locate, as well as one that had the highest incoming/outgoing connections.

The biggest culprit I see is over the past week the reported Bitcoind GetBlock Template Latency has a mean of 0.572s (572ms seems way too high).  Over the past day, the mean is 372ms, which I feel is still ridiculously high.  Am I correct in my assumption here that this latency is likely what is causing me the pain?

I don't actually know on that one. I assume share orphans are more a factor of the speed your found shares make it out to the network vs other people's found shares. If all users have the same orphan rate then the orphans don't matter, because we all get a proportional amount of a found block.

[jonnybravo0311]

The main thing I'm trying at the moment is using -n to connect to the largest public nodes I can find. This way my shares might get spread more quickly, and/or I'll get updated on someone else's shares more quickly. I added the couple nodes with the highest hash rate I could locate, as well as one that had the highest incoming/outgoing connections.

Interesting idea.  I hadn't thought to force connections to known large nodes.  I assume you can either a) pass multiple nodes or b) provide multiple -n parameters in the startup?

a) ./run_p2pool.py -n host1:port host2:port
b) ./run_p2pool.py -n host1:port -n host2:port

I'll give that a try to see if it helps propagate my shares more quickly.

Again, thanks for the help

Side note... 14 hours of uptime on the node, 2 shares found (1 orphan)... arghh... lol.  Come on Lady Luck, shine down on the p2pool hashers!

[jonnybravo0311]

Hey roy7,

So, I decided to check your stats page again.  Now you've found 11 shares (3 more since this morning when I first checked).  I've found exactly 0 more.

Am I just exceedingly unlucky, or have you been exceedingly lucky, or is something more nefarious going on here on my end?  Over 16 hours since the restart after upgrading Bitcoin-Qt to 0.9.1 and I've found 1 share...

Edit: Alright, that's just weird... when I refreshed the stats on your side it now says you've found 10 shares (? orphan, ? dead).  Ummm... I KNOW it showed 11 just a minute ago... lol

[roy7]

Hey roy7,

So, I decided to check your stats page again.  Now you've found 11 shares (3 more since this morning when I first checked).  I've found exactly 0 more.

Am I just exceedingly unlucky, or have you been exceedingly lucky, or is something more nefarious going on here on my end?  Over 16 hours since the restart after upgrading Bitcoin-Qt to 0.9.1 and I've found 1 share...

You must be unlucky? The interface tells me the time to share for 186 GH/s is currently 4h 3m 37 s. I don't see how/why bitcoind would mess you up. I'm also running 0.9.1.

[jonnybravo0311]

Hey roy7,

So, I decided to check your stats page again.  Now you've found 11 shares (3 more since this morning when I first checked).  I've found exactly 0 more.

Am I just exceedingly unlucky, or have you been exceedingly lucky, or is something more nefarious going on here on my end?  Over 16 hours since the restart after upgrading Bitcoin-Qt to 0.9.1 and I've found 1 share...

You must be unlucky? The interface tells me the time to share for 186 GH/s is currently 4h 3m 37 s. I don't see how/why bitcoind would mess you up. I'm also running 0.9.1.

LOL... with luck like that... seriously... 1 share in 16 hours... that's just plain awful.  I could probably calculate it by hand faster

Edit: I noticed that the versions showing on our nodes are different.  Yours shows 13.4-34-gabbbdd3-dirty.  Mine is 13.4-24-gf0eeb48-dirty.  I just did a git pull from forrestv repo last night when I updated to 0.9.1.  How'd you get the 4-34 version?  You running off some branch/fork?

[roy7]

LOL... with luck like that... seriously... 1 share in 16 hours... that's just plain awful.  I could probably calculate it by hand faster

Edit: I noticed that the versions showing on our nodes are different.  Yours shows 13.4-34-gabbbdd3-dirty.  Mine is 13.4-24-gf0eeb48-dirty.  I just did a git pull from forrestv repo last night when I updated to 0.9.1.  How'd you get the 4-34 version?  You running off some branch/fork?

I have various patches applied but I didn't realize that would increment the version number. I'm running forrestv's repo for BTC, p2pool-n repo for VTC, and rav3n's repo for Uno. Here's a graph of my p2pool fork for BTC:

https://github.com/roy7/p2pool/network

Looks like I'm only running mmouse's minerstats and my own vardiffbyaddress. However I thought I also had iongchun's auto-worker-diff applied, but maybe I never pushed that up to my fork. If I have time tonight I'll clean it up some.

[jonnybravo0311]

Ahh... I've got rav3n's and forrestv's.  Are you merge-mining the BTC/VTC/UNO?  What kind of impact, if any, does that have vs just mining BTC?  I assume you'd start the p2pool with something like:

./run_p2pool.py --merged walletID@host:port ...

Yeah?

Edit: Well, you're obviously not merge-mining the VTC since it's scrypt-n

[roy7]

I merge mine Namecoin on UNO and BTC. That's it so far. Haven't tried United Scrypt, Huntercoin, etc.

[kano]

Three blocks were found in 21 hours.  I see the logic though, three rounds took longer.

Irony ...

Embarrassed to admit you're wrong?

[IYFTech]

Right, I'm checking out. These 4, 5 or 6+ day blocks don't even pay my electric bill 

Adios amigos.

[smooth]

Right, I'm checking out. These 4, 5 or 6+ day blocks don't even pay my electric bill 

Adios amigos.

You could save up a bit from the 3-block days. Just saying.

[IYFTech]

Right, I'm checking out. These 4, 5 or 6+ day blocks don't even pay my electric bill 

Adios amigos.

You could save up a bit from the 3-block days. Just saying.

Still not enough. Still having to reboot once a week are you?

Just asking. 

[smooth]

Right, I'm checking out. These 4, 5 or 6+ day blocks don't even pay my electric bill 

Adios amigos.

You could save up a bit from the 3-block days. Just saying.

Still not enough. Still having to reboot once a week are you?

Just asking. 

No reboots, just p2pool instance restart. Yes still set up to do that, no idea if its still needed but everything works as-is so I leave it alone.