I guess it depends on how many total shares your node has found. That's the % that relates to node fee payment. For example, if in the last 5 days you found 200 shares, then about 2 of them should be in the node's name and 198 in the miner's name. Apologies for sometime saying "pool" instead of "node", I tend to think of nodes as pools, but that is confusing.

P2Pool also works differently than any other pool. Such as:

The p2pool sharechain (that stores the PPLNS payment data) has a target speed of 30 seconds per block, which causes a lot of restart message spam to the miner.

Finding a share for a smaller miner can take a while, some miners believe this means they are getting "ripped off" because they don't understand variance.

Orphans/DOAs on the sharechain are common because of the fast target speed, some miners misunderstand this to be similar to orphaned blocks on the blockchain. As long as the orphan rate of shares between p2pool nodes is similar, then it isn't impacting miner payouts at all. (This is reflected in p2pool's Efficiency stat in the default interfaces.)

P2Pool is quite cool, as an experiment and to learn more about it I'm running some nodes on a new alt coin. I think the issues above can mostly be resolved with better miner education. Some way to reduce variance for smaller miners would be nice though.

Remember that p2pool isn't set up to pay the fee on a per-block basis. What happen is 1% of your pool's shares will be paid in full to that address, and 99% of the pool's shares will go to the miner's address. If you just recently started it up, is it possible you haven't found enough shares for the 1% to end up in the pool's name yet?

No because the only person who knows a miner's real hash rate is the miner. The pools estimate it based on the shares the miner submits. The network estimates it based on the # and speed blocks are being found.

I think it just reports the networkhashrate RPC command from the client (or whatever it is exactly called). You can get the same estimate from your local wallet.

Is p2pool support for PPC still non-existent and discouraged?

FYI looks like your pull request was all merged in. Nice to see you are still running strong and the p2pool network has grown so large.

Your miner updates to the new block info and keeps working. A hash either works or it doesn't. You are doing 180 billion of them per second. You don't save up work or make progress on a hard block. You just report the hashes (out of the 180 billion you did last second) that met your difficulty target.

New buyers really need to mine on something other than the single biggest pool in the world. De-centralize, people!

I looked at that thread but can't understand the problem. If stratum sets their difficulty to 1024 instead of 128 it means they'll submit shares 1/8 as often but the shares they do submit are 8x more valuable. Should have no effect on their net earnings.

Web site works fine for me.

Hmm I thought p2pool was supposed to be fairly light weight on bandwidth usage?

http://82.196.8.44:9332/static/graphs.html?Day

That's the biggest public node, with a mean of 10.4kB/s.

As tiny followup, say we want the 3.1 TH miner to have a .01% chance of having 0 shares in a 72 hour period. Don't want him to be upset. Difficulty 20590000 does that.

(20590000 * -ln(1.0 - .9999) ) * 2^32 / 3142484404906 / 60 / 60 = 71.99 Hours

Average time to find a share:

20590000 * 2^32 / 3142484404906 / 60 = 469 Minutes (7.81 Hours)

Or about 9.2 shares on the sharechain. A savings of 140 shares while keeping the risk of big miners getting no payment at all effectively at zero. (Just more variance in how much their actual payments are, to help lower variance for smaller miners.)

Edit: I didn't consider the orphan/DOA rate in p2pool's sharechain network. If you only submit a small # of giant shares, and one of them is orphaned, that could actually end up a sizable blow to your income?

Ok so I just amused and entertained myself by reading the past ~5 months of posts in this topic. I have some thoughts if anyone would care to comment and some questions at the end, and a thought experiment on setting the miner difficulty level to maximize keeping smaller miners in the share chain.

---

Setting up a vanilla public node as a pseudo-pool for people who don't want (or can't) run their own p2pool is kinda a waste of time. There are plenty of good ones already. I toyed with the idea of setting up a pool about 8 months back but getting enough hash to join to actually find blocks didn't seem realistic. I ended up setting up a TRC pool instead, which was fun. (I took HHTT's sockthing pool software, wrote a DGM payment algorithm for it, and set that up for in-coinbase payment for all fees like Eligius which was one of my inspirations to set up a pool. Then I had to code a front end from scratch. At the time I knew very little about p2pool.)

Setting up a new BTC pool these days either means you have tons of hash power of your own, or hooking into p2pool's existing hash power to reduce local miner variance. But even setting up a latency routed network of nodes so people are directed to the nearest one to them doesn't matter much, since they likely already use a public node already that is "near" them with low latency already. (I was thinking about, just as a fun project, setting up 8 public nodes in each of Amazon's data centers around the world and latency routing people to the fastest one for them.)

To make setting up a public node have some sort of purpose, what you need to provide is something of value compared to other centralized pools. This could be anything from paying merged mining to the miners, improved stats/graphs/info, worker offline notifications, some sort of value added thing like multipool's coin switching, a system for reduced variance for small miners, etc. Since many nodes already run at a low to zero fee, it boils down to providing non-financial value added services or features?

---

Are shares on the p2pool share chain limited to only a single payment address? If so, is this an intentional design decision?

If not, it seems if a node wanted to run as a mini-pool to help smaller miners they could track stats however they choose to internally but put all of the pending payment info for their miners into the share being worked on. So if the share is found, all miners are paid their portions of the node's share (as if the node had collected the payment itself then re-paid it out). There's still the trust issue about calculating the amounts due to each local miner, but you keep the coinbase payout feature and smaller miners get paid with less variance since the share isn't limited to only the one miner that found it. Coins are also never held by the node, which helps reduce hacker incentive. (Coinbase payouts was a core design goal of my TRC pool. I never, ever, wanted to be holding someone else's money.)

This would also mean a share being worked on could include the pool fee (-f) with each share found, at the exact amount, instead of taking that % of shares in full. ie: If you run -f 1 and miner A finds a share, the share you send out to the network has payments of 99% of the total to Miner A and 1% of the total to the pool payment address. I'd think this would be much more intuitive to the node operator/miners/etc, and I'm guessing the only reason it doesn't work this way is that the share chain restricts each share to a single payment address?

---

Also, a question / thought. Did anything ever come of lenny_'s suggestion to increase a large miners difficulty higher so they only find (at most, on average) one share every hour? Personally I'd suggest cranking that up even higher as a default. The miner can override it back down with /diff if they insist. The purpose of this is to try and allow more, smaller, miners to fit into the share chain. By lowering global share difficultly, as well as individual miners having less total blocks. I realize the 1.67% or so adjustment is already in there but that's still 149 shares out of 8640. How little variance does a large miner actually need in reality? As long as you are on the share chain you are getting paid each time a block is found.

1 giant fat share is as good as 149 shares that add up to the same amount. It just smooths your payments out, between when giant fat share drops off and the next giant fat share comes on. I wouldn't suggest trying to actually scale large miners to only have 1 share every 3 days (they would in effect be more similar to how small miners are today then). But if we were to say that 6 large shares on the chain on average is enough to give them acceptably low payment variance (I'm pulling this number out of the air so I have someplace to start), then that frees up 143 shares for other miners...

Organofconti can chime in with his real math-fu if he likes (please do!), but as far as I can reverse engineer from my pool's stats calculations the magic would be this (we want to target a share every 12 hours on average, to aim for 6 blocks in the share chain)

Average time to find a block (share) in minutes = Difficulty * pow(2,32) / Hashrate / 60

720 Minutes * 60 * Hashrate / pow(2,32) = Difficulty

So given a worker's average hashrate, set their difficulty to the above.

For an example I took the biggest miner on the biggest public node. Their hash rate is reporting as 3142484404906. (3.1 TH) Share difficulty is at 651000. Right now their average time to find a share is:

652000 * 2^32 / 3142484404906 / 60 = 14.85 minutes

I don't know what local difficulty p2pool is serving them, but it should be higher than 652000 so they will only end up with around 1.67% of the shares. They will get about twice that if they are only getting difficulty 652000 work.

Solve for 1 block every 12 hours on average:

(720 * 60 ) * 3142484404906 / 2^32 = 31608000 Difficulty

So if we give this 3.1TH miner 31608000 difficulty work, his average time is 720 minutes (12 Hours)

50% CDF = (31608000 * -ln(1.0 - .50) ) * 2^32 / 3142484404906 / 60 = 499 minutes (8.31 Hours)
95% CDF = (31608000 * -ln(1.0 - .95) ) * 2^32 / 3142484404906 / 60 = 2156 minutes (35.93 Hours)
99% CDF = (31608000 * -ln(1.0 - .99) ) * 2^32 / 3142484404906 / 60 = 3315 minutes (55.25 Hours)
99.752% CDF = (31608000 * -ln(1.0 - .99752) ) * 2^32 / 3142484404906 / 60 / 60 = 4319.64 Minutes (71.99 Hours)

Which means, given 72 hours of work at this hash rate and miner difficulty level (the time it takes for the share chain to be totally new, correct?) the miner will fail to have found at least 1 share only .348% of the time. And as long as they have at least 1 share in the chain (at this way higher difficultly level) they are still getting paid on every block the p2pool network finds. The amount of payment will have some variance (since there are so few total shares), but whether or not they get paid at all is a virtually zero chance of getting nothing.

Obviously if 6 shares is too few or the .348% risk of having no shares in the chain too high, it can be adjusted however you want. But do even medium size miners need 10+ shares per day on the chain? Does a giant miner need 149 shares?

Ah okay. Sorry to hear that. The constant threat of hackers, DDOS, etc is frustrating.

As someone who sometimes thinks of doing the same thing this pool did, does anyone know why it eventually shut down?

Certainly the very biggest pools make a lot of money, and the next tier of pools make a profit. Personally I'd like to set up a network of pool nodes around the world with latency based routing to get you automatically to the fastest one and such. But the problem is paying for 6-10 servers around the world gets expensive when it's unlikely you can attract enough miners to even break even.

The shares for payment are on the p2pool payment block chain based on the addresses used to mine them (that is, the bitcoin payment addresses where the payments go). You could shut the node down and delete everything and those payments still get sent once a block is found, since the p2pool share blockchain is shared across the p2pool network.

Copying over the data directory/etc is useful if you want to keep your stats on the graphs/etc. If you don't care about that, then you don't need to copy things over. Any new work you do will credit whatever payment addresses you are mining with.

The only risk I can think of is if you were running the pool with a fee, and the pool was paying to the local bitcoind wallet and not an address you provided. If so be sure you have access to that wallet for any payments that arrive.

Plenty of info here.

https://github.com/MPOS/php-mpos/blob/next/README.md

It's an open source turnkey pool front end that works with the stratum-mining proxy as the backup, as I understand it.

Now that Amazon has EC2 instances that can use SSD for disk, I keep thinking how cool it'd be to run a p2pool node + bitcoind in a really high performance way. However is the speed savings from SSD just a waste of extra cost? It seems the low latencies people get from proper tuning are off of normal disk. (EC2 SSD is also "instance" storage, so it doesn't persist if the instance is stopped, which adds some complexity to back up the block chain and p2pool stats in a way you can restore late.)

Just wondering if my idle thinking about an all-SSD setup is a waste of time?