This a great guide - thanks!
I have a couple of questions.
This thread, and others, have said:
The mathematical fact still remains that a well tuned p2pool will out pay any other pool. In fact, it will approach solo mining.
I'm new to bitcoin (as my rep will tell you), but I understand the concept of luck and variance. How specifically does p2pool "out pay" others? I currently mine on a no-fee (keep trans fees) PPLNS pool. My analysis shows that the trans fees are ~1% so p2pool will out pay there. How else? Is there some sort of reduced latency bonus? Or just a "no-downtime" gain? I read somewhere that >100% efficiencies are
"stealing" somehow gaining from others with low pool efficiency by getting their hash power but not always giving credit -- or something.
Among p2pool users there's indeed a competition for the best efficiency. It shouldn't be a problem though: people with really bad efficiency unable to make it better shouldn't mine on p2pool leaving only the most efficient ones (which will bring them closer to 100% efficiency). This is assuming their goal is maximum rewards, you can mine on p2pool for other reasons (you like the concept or find it a better solution for Bitcoin's overall health/robustness).
The advantage of p2pool vs classic pools is stated in the guide: it should have less orphans than classic pools because it's better connected to the Bitcoin network and thus should propagate blocks faster (this is a theoretical advantage, I'm not aware of anyone having measured it).
One thing I didn't write yet is the ability of merged mining. If you have moderately high hashpower (currently ~5GH/s) it should bring you additional coins. Namecoin has been between 5 and 13% as profitable as Bitcoin recently, being able to merge-mine it (Devcoin and Ixcoin are possible too) is an additional bonus. For example I set NMC merged-mining up early just to tinker with it (it wasn't really worth my time) and found a quite nice surprise when looking at my NMC wallet last month: 1000+ NMC where waiting there...
Also, this guide mentions using:
-Q 0 -g 1 --intensity d --gpu-dyninterval 50
Can you elaborate? the -g sets the miner to a single thread (opposed to 3 on my machine). Isn't that going to reduce my hashrate?
It depends on your setup, but I didn't measure any speedup with -g 2 on mine. The higher the number of threads and the higher your latency is, so if it doesn't bring any measurable benefit, you should keep it down.
I'm not sure about --gpu-dyninterval default value but the goal is to keep the GPU latency low without sacrificing too much hashrate. I've measured a ~0.3% lower hashrate when going from 250ms to 50ms but the amount of stales/doa was much lower too. Going lower was eating too much hashrate and I believe 50ms to be much lower than most people latencies with the P2Pool network.
These are good starting point, but if you want to grab a 1% worth of Bitcoin more you might want to study the impact of modifying them by comparing the
* (which is what matters for your p2pool's income) value for long runs (at least 24h).
the -Q 0 seems inefficient too
This is what is advised by p2pool. It seemed inefficient to me too, but I couldn't measure any impact vs -Q 1.
Finally, how is difficultly handled? Hosted pools can auto-adjust this "magically". How can I tell what I should set mine to (or leave it at) and how do I do it?
Difficulty is auto-adjusted automatically so that your miners keep submitting ~1 share every second (to avoid too much traffic and load and still get a good estimate of your hashrate).
