To elaborate on my illogical response...
things that don't make sense to me:
- You adjust your pseudo share size to adjust the share difficulty on the pool. That means you get less shares, which means you keep less payout. Why do that? Wouldn't you be better off pointing 10% of your hashrate to the pool and the other 90% somewhere else?
Pseudo share size has nothing to do with share difficulty on the pool or payouts. Those are the little Accept X/Y your miner prints every few seconds or so. It just lets the pool know you are alive and plot graphs, etc. To actually get paid you need to submit a share where the difficulty is higher than the minimum share difficulty for the pool (or higher than your share difficulty target if it's higher than the minimum).
To get more or less pseudo shares you use +. For instance, if you run a local node you could spam it with tiny shares by adding +1 to your payment address. Has no effect on income.
To get more or less real shares you use /. Any /DIFF set below the network minimum is ignored, and your target diff to get on share chain is the minimum. Any /DIFF higher than the network minimum means you'll get on the share chain less often, but the shares are more valuable (your target share difficulty is the value stored to calculate your payout, all shares on share chain do not have equal value, maybe this is your confusion?). The maximum target diff you can set is 30x the network minimum. If you set it higher, it'll adjust every time the minimum target adjusts.
- Unless sharesize matters when you adjust your pseudo share size. If sharesize does matter, then how can it not affect the share difficulty if 6 small shares an hour or one large share every hour has the same result?
In a normal PPLNS pool, the payment window is all of the shares of work submitted (what p2pool calls pseudo shares), and there is only one type of share. All work submitted is logged and is in the payment window for a certain amount of work N. N is usually some multiple of the coin's difficulty.
In p2pool, the shares a normal pool would count are ignored and only shares of a certain difficulty target are counted. This is because there's no central database to record all of the info. We're decentralized and nodes can't trust each other. So the payment database, instead of being MySQL or similar, becomes a bitcoin style block chain, we call it the share chain. The share chain contents are the PPLNS payment database for p2pool. It has a specific target speed just like bitcoin. The share chain target is 30 seconds. The minimum difficulty to get a share onto the share chain is adjusted similar to bitcoin's difficulty algorithm, so the share chain grows by one share (block) every 30 seconds.
So the minimum difficulty for shares to get on the share chain is soley a factor of time. How long is it taking to add shares to the share chain? Just like bitcoin itself, the diff adjusts so the target rate is hit. The contents of the shares on the share chain don't matter.
(Side note: It's endlessly confusing that "share" might be a pseudo share, a real paying share that is recorded on share chain, or a "block" on the p2pool sharechain.)
So your question above, if you are talking about pseudo shares, it doesn't matter.
The issue is that the share chain has a finite number of "shares" (blocks) available. When it's full the older ones are expired. Even if the
luck has been bad pool hash rate has dropped to where we aren't finding N work before the share chain length maximum is hit, opposed to the PPLNS window on a normal pool would still be counting those shares. This is a separate issue/concern of mine.
To even get on the share chain at all, you need to find a share (in your client) with a difficulty that is higher than your target share difficulty. I'll give an example below.
- If the time between shares affects share difficulty, that means it's based entirely on luck! If the pool hashrate remains constant, and luck goes sour and people start getting less shares, does the share difficulty suddenly decrease? Likewise, if luck increases, does share difficulty increase?
Yes, and this is exactly how bitcoin works as well. Difficulty is set based on actual shares found. Real hash rate doesn't matter, it's only the observed hash rate from actual found blocks that changes the difficulty target.
So why bother with /DIFF and using a higher one than you need to? Take a small coin with a p2pool share chain target of 1 minute, and two miners:
If Miner A has speed S and miner B has speed 99*S and are both mining on the p2pool node with the same difficulty targets (for simplicity ignore there being a vardiff, say both miners use /1, and the minimum share diff is a tiny number like on a scrypt coin) then A will find 1 out of every 100 shares and B will find 99 out of every 100 shares in some period of time. We want to find one share per minute for the share chain, so the minimum network difficulty will adjust so that shares come in once a minute. Thus, miner A finds 1 share every 100 minutes and miner B finds 99 shares every 100 minutes. As the p2pool network speed (or just miner B's speed) grows, miner A's rate of finding shares will get slower and slower. These shares all have a value of "1" for our example.
If a paying block is found when we have these 100 shares in the share chain:
Miner A is paid 1 * 1 / 100 of the block reward =
1%Miner B is paid 99 * 1 / 100 of the block reward =
99%(The math is # of shares * value of shares / total share chain value, assuming each of a miner's shares have same value, it's actually a sum of each individual share value in practice.)
Now let's say miner B feels bad for miner A and wants to help reduce his variance on when he gets paid. So whereas miner A might be mining diff 1 shares, miner B is going to change over to ADDR/99 to mine diff 99 shares. There is a 30x cap, so p2pool will actually make /30 the maximum it will use.
Now, in a specific period of time, miner A will find S shares and miner B will find 3.3*S shares (since his diff target is 30 times higher vs his 99x faster speed). With the network difficulty from up above, A is still finding 1 share every 100 minutes but now B is only finding 3.3 shares every 100 minutes instead of slightly less than 1 per minute. This means the share chain is way too slow. Network minimum difficulty will drop until both miners combined average 1 share per minute. Once adjusted, in this 100 minutes of much lower minimum difficulty, miner A will find about 23.25 shares for every 76.75 shares miner B finds (please pretend we can have fractional shares to make the math clean).
The advantage is that miner A now finds shares on the share chain every 4.3 minutes (100/23.25) instead of one every 100 minutes. You can see that's a massive drop in his wait time. Miner B only goes up to about 1.3 minutes per paying share. What happens to the payouts?
The total value of shares on the share chain are 23.25 * 1 + 76.75 * 30 = 2325.75
Miner A is paid 23.25 * 1 / 2325.75 of the block reward =
1%Miner B is paid 76.75 * 30 / 2325.75 of the block reward =
99%So the end result is that Miner B can increase his time per share from 1.01 minutes to 1.3 minutes in order to let Miner A drop his time per share from about 100 minutes to 4.3 minutes. The miners still make the same average income over time.
You can imagine how big this effect becomes between a large mining farm and a single 180GH Antminer S1 miner.
TLDR: Sorry.
