Thoughts I've had on making p2pool more attractive to prospective node operators...
- Automated payouts of merge-mined coins built into p2pool. Unfortunately, the way the merge-mining works is that you are effectively solo-mining all your merged coins.
Finally, there's the issue of variance. Your average miner simply doesn't want to accept that he might go days without finding a share. He sees his miners plugged in. He sees them hashing. Why isn't he earning? On this point, I'm not sure what can be done to solve it. Dynamically adjust the share time along with the difficulty? Adjust the weighting of found shares based upon calculated miner hash rate? I believe that the issue of variance is p2pool's fatal flaw. Let's assume that EVERY miner everywhere suddenly had an epiphany and decided to join p2pool. Yay! We suddenly have 100PH/s! Uh-oh.... share difficulty has shot up to a billion...
I've written a p2pool merged coin payout tool which tries to help with paying out merged coins, but I'll admit it's of limited value. That's mainly because of a few things out of my control:
https://github.com/hunterbunter/p2pool-merged-payout-toolCurrently it takes the server balance of all the merged mined coins, takes a record of the hashpower for the previous month (can be hour/day/week/month/year) from p2pool, then works out the market value of each coin in btc, and calculates what each should get. It shows two payout tables, one if you want to pay out in a particular convenient coin (everyone gets one type of coin), and the other if you do a native payout (everyone gets a bit of every coin). It still requires manual processing, though, but if you can get everyone's payout addresses in a database, it's fairly easy to make payouts automated too.
Regarding the issue of variance, and especially the share-chain difficulty, I agree it's a crippling issue, but no more than the original bitcoin blockchain itself - at 100% p2pool, it becomes a case of every node acting like a minipool going for a block reward, except they can get a portion of a block rather than all or nothing....still better imo.
Within this environment, we can then choose automatic bitcoin payments from p2pool, where each miner takes the risk, or we can choose a middleman, who takes on the risk for profit. With automatic payments you don't have to trust a node that much, but you still take on the risk of variance yourself. A node operator can set up a hybrid node which offers other services, but charges a 100% pool fee (they control the coins, meaning trust issues). They could still charge an 'effective' 0% fee by distributing all funds received, though...it's just about processing.
A very simple hybrid pool would register all the different addresses people want a payout in, then either pay them out automatically or setup a login system where people can pay out at whim. I set up blisterpool to do the former - people register a bitcoin address and devcoin address pair which was locked in the db - it automatically pays out merged coins plus a bonus in devcoins when a block is found (incentive for testing the unofficial devcoin client, not particularly p2pool related). It's all a lot more work than a few install commands, though, but the option is there for people. I'm considering making it a 100% fee pool (0% effective) and adding this login system with services similar to GHash.io, just to see if it has any value to miners.
The big advantage of p2pool as a backend in this case, is that it allows new, small hybrid pool operators the chance of attracting people based on p2pool's hashing power, instead of trying to solo-mine a bitcoin block itself. P2Pool is still a good thing!
