What are the downsides to increasing the PPLNS windows/length of the sharechain?
For p2pool specifically, or for pools in general? I'm assuming the former.
P2pool needs to store all of the shares in the sharechain plus a few. If the sharechain is 8460 shares long, this means that p2pool needs to store at least 8460 shares in its sharechain. In practice, p2pool stores about 2x as many shares as that, so the sharechain length is typically around 16,000 shares in length. Each share references each transaction in the block that that share would have made, using somewhere between 2 bytes (in my lowmem branch for transactions that have been included in previous shares) and 70-ish bytes (for new transactions, including Python's object overhead). With roughly 2000 transactions per share, that turns into about 10 kB (lowmem) to 50 kB (p2pool master) per share, or 160 MB (lowmem) to 800 MB (master) of memory consumption. Multiply those numbers by something like 4 if you're using pypy.
There are also some minor CPU usage costs on sharechain size when processing shares (e.g. calculating payouts for the coinbase), but they're mostly alleviated by using a skiplist in the work-done-by-user calculations.
I would like to strip all transaction data out of the share data structure in the share chain in order to cut this memory footprint issue and reduce the CPU requirements for processing shares, but until that is done, increasing the share chain length is a bad idea.
The coinbase transaction would not change much in size for typical p2pool use because it almost always contains at least one share per active p2pool user anyway. A single ASIC miner is generally able to mine more than one share per 3 days (the current PPLNS length target).
The coinbase transaction size is not currently a significant problem for p2pool, as it only takes up a few kB once every few weeks. If p2pool grew bigger and if blocks got more frequent, it could make sense to pseudorandomly determine which users get paid out from each block, or to keep a separate balance state for each user that is independent from the payouts, and make payouts only when that balance state exceeds some reasonable threshold.
Is there somewhere to check whether larger miners are setting their share difficulty too high? That it negatively affects small miner's variance.
You can go onto a p2pool node and use the share chain explorer to look at different shares, the difficulty used for that share, the mining address that created it, and the minimum difficulty that p2pool would have allowed for that share if the miner had chosen a low-diff share.
. Because i am thanksfull you talking to my an spend me these time.
. i dont get twistet installed to pypy.