Bitcoin Forum

Edit: Ok, so it seems that something similar to this already exists: PPLNS. My bad.

While I'm not fundamentally against pool hopping as I believe people should use whatever legitimate advantages that they can to their favour, I think it will become a problem in the future for anybody not hopping. I envisage the future of mining containing a small number of individuals or small groups with large hashing power. For instance, 10% of the miners with 90% of the total hashing power. It would be in their best interests to pool hop to maximise their earnings, and would make it more difficult for smaller players who don't hop.

My simple solution? Calculate payouts based on the fraction of submitted shares submitted during a time window just before finding a block.

For instance, let's say there's a fairly large pool which has the hashing power to average one block per hour. Pool hoppers would be jumping out of the pool after the round has latest longer than 43.5% of the expected shares (reference here: https://forum.bitcoin.org/index.php?topic=3165.0) which is about 25 minutes for our "60 minute average block time" pool. My proposal to this pool to prevent hopping would be to calculate payout based on the 20 minutes (or less) before the block was found. Let's say the pool finds a block at 08:43. Payout would be calculated on the shares submitted between 08:23 and the share that found the block.

Because every share has an equal chance of finding a block as any other share, the miner does not know where this "20 minute" period will be. This "20 minute period" should be a representative sample of each miner's effort to find each block.

The size of the window in which payout is calculated should be decided on a pool-by-pool bases depending on the hashing power of the pool. It should be less than the time it takes for 43.5% of the average number of shares per round to be submitted. For instance, Deepbit might use a 10 minute window. Obviously, payouts for rounds which are shorter than this time period would be calculated from the full round length.

The only disadvantage I see is slightly more variance for non 24-7 miners and low power miners (such as CPU miners), especially on the smaller pools with longer rounds.

Update: The above (the strikethrough text) has been decided to be slightly incorrect (see future posts). Block finding boundaries must be crossed to prevent hopping and the 43.5% rule does not matter. For instance, if the "window" is 60 minutes and the pool finds blocks in less than that time, some shares must be paid out for more than once, with each payment in proportion to the amount number of shares in total in the "window". The length of the window therefore does not matter, provided round boundaries are crossed meaning 24 hour windows are possible in theory to reduce variance on smaller pools.

Congratulations, you just pretty much reinvented PPLNS (Pay-Per-Last-N-Shares).

Ah, so I have. Sorry about that :(.

I was going off the methods I saw here https://en.bitcoin.it/wiki/Comparison_of_mining_pools and a fairly brief forum search.

Don't be ! It's arguable an obscure method indeed, since it's not used in any pool at the moment.

You can see PPLNS in action (from a hopper's POV or a regular miner's POV) on this page : http://eligius.st/~luke-jr/samples/800MH/

What do you do on very short (30 second) rounds then, then the number "N" has not yet been reached?

Obviously all the shares would be counted.  It only takes affect when the time is greater than "N".  The pool would drop the shares submitted prior to "N" from consideration after "N" is reached.

...
what about the miners that work for x hours on a long block....  take the miners offline to do. well whatever we do when we take a miner offline..  then all the work that was done would be lost....  I am not going to use a pool that would do that.

A pool that is averaging many hours per block will also have a time window for shares which is several hours long.

Conversely to what you said, what about when a pool has been working for x hours on a long block and you join the pool right before they find it. You're then getting paid out a larger proportion to what you submitted the whole round. These possible situations average out exactly over a long period of time.

Like I said in the OP, non 24-7 miners would see a much larger variance in their payouts; both up and down. It will tend to even out over a long period of time by the law of large numbers.

Exactly, so Pool hopping could be still worth it, as there are SOME shares that are then worth far more than others.

If you consider shares across "rounds" this might help though.

(1000 shares submitted for the first block, 100 for the second block --> look at the last 500 shares of the first block for payout there and the last 400 of the first block and 100 of the second block for the payout of the second one).
I'm not sure if this stays fair if difficulty changes though.

Also as jjiimm_64 said: if you can't mine 24/7 reliably such a pool is not good to use at all compared to a PPS one.

This is not true. While in a very short round the shares are worth more than others, it does not make it possible to pool hop.

Let's say a hopper jumps into a pool just after it's found a block in the hope it will find the next one quicker than the time period that payout shares are to be collected over. Let's say this share counting window is 20 minutes, and the hopper only stays in the pool for the first 10 minutes. He then jumps to the next pool in the hope that the previous pool now finds the share in less than 20 minutes so that each share he submitted is worth more. If this happens then the hopper has profited. If this doesn't happen and the round lasts any longer than 30 minutes then the hopper earns absolutely nothing from that pool that he spent 10 minutes in as the payout share collecting window is sliding with the length of time of the round.

Earning more per share in the shorter rounds vs maybe earning absolutely nothing in the longer rounds (for a hopper) should tend to even out over a long period of time by the law of large numbers meaning that hoppers earn exactly the same as non hoppers, only with greater variance.

As it is STILL a proportional system, as soon as some shares are predictably worth more than others (in a 20 minutes sliding window that is restarted at each found block, every share in the first 20 minutes is worth more than any other share later in that round - the only difference is that later on you get 0 instead of a smaller payout) you can very likely (ab-)use this to your advantage.

Anyways:
This method is still unfair (in the sense of: creating massive variance) to users that mine irregularly compared to a PPS system. As difficulty is changing, even by the "law of large numbers" you might run into situations where a high variance kills a LOT of your reward(s) and you'll never be able to make up for it.

It is not possible to abuse this system as far as I know. If you think you know of a way then please explain it :). The point is that you do not know when that "20 minute" sliding window will be as every share is equally likely to solve a block at a given difficulty as any other. If you don't know when it will be you can't hop around pools aiming for just this window.

About the variance: I don't thin it would be that much more than it is now unless you're a very scarce miner only doing a few random hours mining per week on a small pool with average rounds longer than a few hours

Maybe I'm missing something, but I don't see why this prevents or even discourages pool hopping. The reason you would want to leave a proportional pool is because once there are a large number of shares trying to earn the current block, each share you add is expected to be worth less. With this scheme, you still have the same incentive to leave a pool if it has gone a long time without finding a block.

First, by leaving, you have no effect on the value of the shares you have already submitted. They'll either be part of the last N shares or they won't. So you'll still get paid the same for the work already done.

And your new shares are still worth less. This will be a block where >N shares will be submitted in total, while in some blocks <N shares will be submitted in total. So you know that any shares you submit now will be worth less than the expected per-share value if you wait until the pool finds a block to start submitting shares.

So this does nothing to discourage pool hopping. With this scheme, it is still to the miner's advantage to leave a proportional pool and submit to a pay-per-share pool if the proportional pool has gone a long time without solving a block.

Worse, if N is large, it actually encourages pool hopping because there's a good chance that joining the pool right after it finds a block will bring a 'jackput' 50/[<N] payout rather than the usual 50/N payout. And if N is small, it penalizes slower miners who may not get any shares in at all during the payout window.

There is no incentive to leave after a long time not finding a block. All results prior to the time window are thrown away, and there is no way of telling if your shares will be in the window or not while mining.

I think you’re missing the point that the each share submitted during the window is worth more than the expected value of a single share in a normal proportional system, even if the window is the full length. Each share in the window is worth more than double (essentially triple) the expected value of a single share otherwise.

No it’s not. The risk you are taking by continuing to submit to the "windowed" pool is that the shares you are submitting are worth much more than shares at a normal proportional or PPS pool, provided that they are inside the window.

This still needs some proper mathematical calculations, but I’m pretty sure the "jackpot" payout for very short rounds is cancelled out by the fact that any hopper trying to do this will then have all of their shares from the start of the round dropped as soon as a particular round is longer than the window.

Maybe not the most simple solution for some, but IMHO the most awesome for sure - use SMPPS (http://eligius.st/wiki/index.php/Shared_Maximum_PPS), the most kickass payout system invented.
With this system you get paid for exactly the amount you deserve, pool-hoping or not. The only drawback is that the payout could be delayed a bit, if the pool is unlucky. But from my own experience at ars, I would say this is not really a problem at all.
Currently this is implemented at arsbitcoin.com and eligius.st

The real proble is that over time the pool can be arbitrarily much in minus/plus to it's miners.

Imagine the pool having a minus of 1000 BTC at the time the reward halves!

You all have missed the defining characteristic of true PPLNS, which is that it crosses round boundaries. If there are less than N shares in the current round, shares from the last round(s) are paid. For every block found, the last N shares (variant: which were not yet paid) are paid, regardless of which round they belong to.

Implemented in this correct way, PPLNS is indeed hopping-proof.

If you want hopping-proof without crossing round boundaries, use the geometric method (http://forum.bitcoin.org/index.php?topic=4787.0).

IMO SMPPS is a bad method.

There is an incentive to leave after a long time not finding a block. You know that your future shares will payoff at most 50/N. Once the pool finds a block, there's a chance that future blocks will pay off more than that. So the incentive to leave is that you know the payoff for any shares submitted will be below the pool's average payoff.

And there is no penalty. If the pool soon finds a block, all of your existing shares will payoff (or not payoff) just the same if you leave the pool as if you keep mining for it.

Right. And all your past shares have the same probability to be in the window or not in the window if you leave the pool or if you stay. So that's not a reason not to pool hop. And your future shares have no higher probability to be in the window just because the pool hasn't found a block. So that's not a reason not to pool hop.

In other words, this scheme provides no reason not to pool hop.

But it does provide a reason to pool hop. A share found soon after the pool finds a block has a chance at being in a 50/[<N] payout. So those shares will be worth more than average. It follows that shares that are in a 50/N payout must pay out less than average. So there is a reason to pool hop as soon as you suspect that a block has acquired more than N shares.

But those shares have the same chance to be in the window as always. And they have no chance to be in a 50/[<N] block. So they are worth less than average.

No, not at all. The jackpot rounds are pure win for people who submit shares during them. Pool hoppers will only want to participate when there's a chance for a jackpot since those rounds will pay above average. As soon as there is no chance for a jackpot, there's an incentive to pool hop, since those shares have no chance at being in a jackpot round and will have an expected payout below average.

As has been said, the N shares must cross a round boundary. There must be no jackpots.

why is that? the only problem I see is that an unlucky pool will get a bad reputation for delaying payments for shares a long time

Ok, I see what I was missing now and agree that not passing the round boundary does allow for a slight benefit to hoppers. If this system was modified to pass round boundaries making all windows the same length it should be a watertight system again. This essentially becomes PPLNS.

Correct me if I'm wrong, but I believe crossing pool boundaries would mean the "window" could be as long as you wanted. Even 24 hours.

I believe that's correct, which is actually pretty nice.

There could still be 'jackpot' rounds if multiple blocks are found within the window. But there is no way to know that a share is more or less likely to be in the jackpot before you work for it, so that provides no incentive to pool hop. Every share submitted has precisely the same chance to be part of the payoff for any number of found blocks.

In a nutshell, if an SMPPS pool with no fees runs long enough, with probability 1 it will eventually reach a point of such unluckiness that its payouts will be miniscule. Miners will leave and the pool will never recover. At that point miners with pending payments will never receive them. So, the claim that "you will get your due reward eventually" is refuted based on the pool's inevitable collapse.

First, defining the window in terms of units of time is bad. You need to define it in terms of number of shares.

But yes, I guess in the multiple-payment variant, you could make the window long. But this will also mean you'll have to make sure you're handling difficulty changes properly.

In the single-payment variant, the window must be less than the difficulty by some margin.

I don't understand why you say this. With SMPPS, every submitted share has precisely the same expected payout regardless of the past performance of the pool.

Defining in terms of time rather than shares is absolutely fine provided the period is long for the smaller pools. It also means it's always constant (in time) even when the hash rate of the pool fluctuates. A window which is always constant and defined by time makes it much simpler for the average miner to understand. Payments are not calculated by a miner's proportional time in a pool, but by the proportion of the shares they submitted in the window to the total number of shares in the window. The Window still slides with the discovery of a new block in that pool.

Yes, it would have to involve calculating payment from the same shares more than once if blocks are found over a much shorter period than the window. I'd think it may even be best to have a window longer than the expected time to find a block to decrease payout variance. You would not have to make any adjustments for difficulty changes.

I don't see a single-payment variant working well with this method.

It can be in shares or time. If the window contains more shares, it will likely also contain more found blocks, but they will be divided over the greater shares. The expected revenue per share will be precisely the same, and that's all that's needed.

If a time window has n shares and m blocks, the payout per share will be 50m/n. If later that time window has 2n shares submitted, it will be expected to find twice as many blocks. The payout will be 50(2m)/(2n) which is precisely the same.

Only if you assume people are willing to wait arbitrarily long for their rewards. The lower the pool's current balance, the longer it will take to get the full payout, and people will lose patience. Add to this the fact that people will fear the collapse of the pool, a self-fulfilling prophecy which will prevent ever getting the payment. When the pool is in the red, massive abandonment is a schelling focal point.

No, it will make the pool vulnerable to hopping based on pool hashrate fluctuations. It is more profitable to mine for the pool when the current hashrate is higher than the average over the current window.

They don't have to wait arbitrarily long. They only have to wait until the SMPPS pool accumulates whatever the number of shares chosen for N is. At that point, they will get whatever payment their share is going to generate.

I don't follow you. What do you mean by the "pool's current balance"?

The way a SMPPS pool works is this: People submit shares to the pool. The pool tries to find blocks. When it finds a block, it pays out on each of the N shares received prior to finding that block, paying 50/N bitcoins. N can be chosen large enough so that most shares pay out.

You do have to wait until the pool finds a block to get paid though. So this won't work very well for very small pools. But once a pool is large enough to find a block at least once a day, there's no reason to think it would shrink.

No it won't. When the hashrate is higher, the number of shares per window will be higher, resulting in lower payouts per block found. Of course more block will be found, equaling things out perfectly.

You're talking about PPLNS. I was talking about SMPPS. PPLNS is a great method as I've mentioned here and elsewhere.

Read carefully. I said "current hashrate > average hash rate over the window". The number of shares per window depends on the average hashrate over the window, not the current hashrate. Meanwhile, the chance your share will be included in a payout does depend on the current hashrate.

I understand this completely. The reason smaller pools should have a longer window is to reduce variance. Non 24-7 miners in small pools with a small window (relative to average time to find a block) are going to have payouts all over the place.

If you do PPLNS instead of PPLNM (with M standing for "minutes") you don't even need to consider time windows. You could then tune variance by just looking back more/less shares.

Meni Rosenfeld, could you do some math for me, since you seem to like to do it and like to say that SMPPS is a bad method?

I understand that over an infinite time period, there is a certain probability that a SMPPS pool will be very negative (or very positive, etc.)  

However, I have a question.  Based on the current stats at https://arsbitcoin.com/stats.php, (SMPPS Buffer size, current hashrate).  And assuming that current hashrate is constant (lets say 210 GH/s), BTC reward per block stays at 50, difficulty is constant (if this matters), what is the probability that the SMPPS buffer will go below 0 in the next year?

I think it should be possible to calculate this, but I am not very qualified to do so.  It seems like you are.

It seems obvious to me that, for example, it IS less likely that the buffer will go negative, within a year, now that the buffer is ~685 BTC vs starting with a 0 BTC buffer. Sure, it is still possible to reach a very negative buffer, but the higher the buffer is, the longer this is likely to take, correct?

And I know that we are lucky.  I'm not saying that everyone should switch to SMPPS, because the buffer could just have likely gone to negative ~685 BTC as positive.  I'm just curious what the numbers say for my current situation.



 

I'll need to think a little about this, in the meantime I'll solve the easier problem of what is the probability the balance will be negative exactly one year from now (which would be 50% if we started at 0). With the current parameters, the pool will find in a year 210*10^9*86400*365.24 = 6.627*10^18 hashes, which is 6.627*10^18/2^32 = 1.543*10^9 shares, which is on average 1.543*10^9/1564057 = 986.5 blocks. Since this is distributed Poissonly, this is also the variance in the number of blocks found, so the standard deviation is sqrt(986.5) = 31.41. Our current balance is 685/50 = 13.7 blocks, so using the normal approximation to the Poisson, the probability that our balance will be less than 0 is the probability that a standard normal variable will be less than -13.7/31.41 = -0.4362, which is 33.13%. So the head start we have doesn't help too much.

Of course, the probability that the balance will be negative at some point during the year is higher, stay tuned...

I'm considering different ways to implement variations of PPLNS in my pool. I like the idea of PPLNM, but I think it is vulnerable to pool hopping, as some said earlier in this thread.

PPLNM (pay-per-last-N-minutes):
If you mine for one hour while hashrate is low and leave before it goes higher for one hour,
1. there are fewer proofs-of-work in your hour, so they are worth more, and
2. there is a high chance of payout on those proofs, because the hashrate is high in the second hour.
This should result in above average pay.

Mining for an hour with high hashrate, then leaving before others mine one hour with low hashrate, has opposite effects. This means below average pay.

If the pool hashrate goes up and down, and you only mine at the bottom of the curve, you get a bigger share of the payments, doing a smaller share of the work.

Since there is an incentive for joining when the hashrate is going up, and leaving when it is going down, pool hoppers could create a rollercoaster effect on the pool hashrate, and the value of a proof-of-work would be very irregular. I guess it would take a few pool hoppers to make this happen though.

Maybe this is very exaggerated, but at least in theory pool hopping would work.

Ok, according to my model, the probability is about 66%. This is reaffirmed by simulations I've run.

This is assuming the pool's proportion of the total network hashrate is as given, if it becomes higher the probability will increase.

I don't think these will be the exact dynamics. There are two separate effects:

1. Stickyness: If you've already mined in this round, this increases your incentive to continue mining, since you'll raise the pool's hashrate and help it find a block before your old shares depreciate.
2. Opportunism: The probability that a block will be found before your new shares depreciate depends on the hashrate in the near future. On the other hand, their value if a block is found soon depends (inversely) on the average hashrate over the last N minutes. Thus, you are incentivized to mine when the hashrate is higher than the average.

What is the magnitude of the effect? Not too high, probably, but why take the risk when there is a purely advantageous alternative?

How is the probablity if there is a "withhold good proofs-of-work" attack with 1% of the pool's hashing power? What if the attacker has 50% of the hashing power?

This sort of attack would surely hurt any pool, but it would completely annihilate a small pool running any PPS-based payment method. I suppose someone would have to really hate you to waste hashing power destroying you instead of making money. But it's still a weakness with PPS-based methods, including SMPPS.


I agree, PPLNM may be just fine in practice, but PPLNS looks even safer.

Still, there is the question of picking N. You could choose N/2, N, N*2, or perhaps a fixed value, say 1 million? I'm still thinking about how the choice of N will influence payouts for 24/7 miners, "casual" miners, and pool hoppers.

How is PPLNS affected at or near the time the difficulty changes? Can the difficulty change benefit poolhoppers in some way?

Is this something you can easily plug into your simulator?

Thanks Meni Rosenfeld!

For the 1% case I get about 74% (I didn't triple-check it so I'm not certain that's correct). For 50% it will be virtually 100%.

The way I see it, Increasing N has the following effects:
1. No effect on the average payout per share, no matter the mining pattern.
2. Less variance, again for all patterns (perhaps felt the most by intermittent miners).
3. More time in the beginning of the pool where there aren't N last shares and you need to decide what to do with the leftovers (give to the operator? Charity? Distribute among miners proportionally?)
4. More time between mining to knowing what your due payment is and receiving it.
5. If difficulty changes are not handled properly, more disruption caused by them.

I think the way to handle difficulty changes while remaining 100% hopping-proof is:
1. Express N in terms of blocks. For example you can choose N to be 1 block, and it will remain 1 block even after difficulty change.
2. Assign to each submitted share a score of 1/difficulty (the difficulty at the time of submitting the share).
3. When a block is found, distribute the reward among the last shares with a total score of N, proportionally to their scores.

Note also that for the geometric method I have studied this matter more thoroughly and can confirm that it remains correct in face of difficulty changes.

You're welcome :).

*long confused post deleted*

Hey guys, I just want to make sure I understand what Meni is saying:

Shares to use from this round:
s1 = min(sum of all shares this difficulty, N * current difficulty)
Shares to use from last round:
s2 = min((1 - sum of all scores this round based on the last s1 shares) * N * old difficulty, 0)

All further calculations are based on only including the shares that you have submitted in the last s1 + s2 shares.

A miner's score:
(your valid shares this round / this difficulty + your valid shares last round / that difficulty)

A miner's payout:
50 * score

Looks ok, if "round" means "difficulty adjustment period". Note that for very small pools or long windows, it is conceivable that the window will include shares from two adjustment periods back, which you'll also have to include in the calculation.

Yes, it does. And I will do a full fix.

And also:
 + s2 does not need the min, since the left will be 0 anyway if the entire score comes from the current difficulty
 + you need to divide the miner score by N

Here is some psuedocode which tells you how many shares to go back for PPLNS where you set N as a multiple of the difficulty:

currScore = 0; //score for this block
score[] //score for each round (most current difficulty first)
totalScore = sum(all scores over all blocks);
difficulty[] //the difficulty history (most current difficulty first)
shares[] //shares to use for calculations from a difficulty
totalSharesDiff[] //total shares mined during a difficulty
diffCount = 0;
quit = false;


while(!quit){
   shares[diffCount] = min(ceiling((N - currScore) * difficulty[diffCount]), totalSharesDiff[currScore])
   
   currScore += shares[diffCount] / difficulty[diffCount]

   if(currScore >= max(N, totalScore))
      quit = true
   diffCount++;
}

usedShares = sum(shares[]) //how many shares we actually go back in the DB when calculating payout


Here is a sample:

difficulty:
100   //oldest
500
1000   //newest - will be first in the array

totalSharesDiff:
413  //oldest
712
109  //newest - will be first in the array

N:
2

shares[0] = min (2 * 1000, 109) = 109
currScore = 109 / 1000 = .109
.109 < 2


shares[1] = min (1.891 * 500, 712) = 712
currScore += 712 / 500 = 1.424 + .109 = 1.533
1.533 < 2

shares[2] = min (ceiling(.467 * 100), 413) = min (47, 413) = 47
currScore += 47/100 = 1.533 + .47 = 2.003
2.003 >= 2

usedShares=868

Let me know if people agree with this. If there are any pools that are interested in actually using this I can create some psuedocode for actually calculating payouts to miner's as well.

Although, there is no reason that you wouldn't just include a score column in the database, and then you could just pull last x scores where sum(scores) < N

Which is exactly what Meni said.

Don't I feel silly :)

Anyway, maybe the above might be useful for someone :P

So with 2 miners in the pool: miner A who submits 10 shares when difficulty was 10 and miner B who afterwards submits 1 share when the difficulty drops to 5 + hits a block, miner B gets 20% from the next block?

What I would also find interesting would be how to handle payout fluctuations (either right now already with transactions fees or more drastic in the future when the change to 25 BTC/block comes), especially in a PPS scenario.

Another thing I thought of is fractional reserving on SMPPS pools. If you don't do automatic payouts, or only at relatively high BTC values or intervals, you could temporarily go in a minus too without harming anyone (as you still have a lot of BTC from people that didn't pay out or can't pay out yet). Oblivious shares would still be much needed to make sure you don't get leeched by withholders, but in the end it could very well be possible to go in a minus too and still pay out full PPS values.

The big unknown part for me is how to deal with transaction fees in a PPS scenario (if you want to hand them out as pool operator too). Handing them out using PPLNS or similar systems would just sound like admitting defeat to me, but it might be the best thing to do in the end  (= VERY slowly switching from PPS to PPLNS over the years). For PPS I still would prefer something like RPPS with a floor: Paying out each round getwork_difficulty/global_difficulty per share to each share until there's no money left - starting from the most recent share.
This means some very old shares might never get paid (and you could/should include something that after 1 month or so shares that haven't been paid will never be paid and get deleted). There is some risk involved in mining in such a pool that some shares might not be paid, but in total it should be relatively safe to mine there (on/off as well as 24/7).

Assuming N = 1, yes. But this is fair, since PPS payouts would double as well, making it easier to earn BTC all over the network.


I would prefer that my pool operators take unneccessary risks that could bankrupt them. Basically they are taking a loan from the 'depositors' who haven't cashed out yet and are paying it out to people who have asked. If the pool ends up losing hashing, or something else, people won't get paid.


No one running PPS will want to hand out these fees, as they are taking tremendous risk already by running such a pool. And I would not mine at a pool where there was a chance that I would be underpaid when there are perfectly fair pools out there.

On the contrary, PPS is the only kind of pool which can easily pay transaction fees. For every share submitted you just pay B/difficulty where B is the total block reward at the time. If the operator worries about his risks, he takes a pool fee.

For any other scoring method, I don't know of a way to guarantee the expected payout for every share is always exactly the solo average, when the block reward is unknown a priori. This is something for which a solution will have to be found as it becomes more relevant.

What do you mean by total block reward at the time? Isn't that unknown until you solve a block?

I think I am confused as to what we are talking about.


As an aside, I want to thank you for trying to make mining better, even though there are still a preponderance of proportional pools ;)

When you calculate hashes of a header, you know what transactions are to be included in it, so you know what the reward of the block would be if the hash you find is valid (satisfies difficulty requirement). By extension, when you find a share, you know what the reward for it would have been if it was a valid block. So, if you're working on a header for which the coinbase+tx fees is B, if you mine solo your average payout is B/difficulty per share. This is also your average contribution if you mine for a pool. So in PPS, you're supposed to get B/difficulty for that share (minus fees).

You're welcome. It's an uphill battle but you must never lose hope :).

So essentially, you should get lower relative rewards just after the network finds a block, and higher rewards as the block gets older.

So basically, if you were intent on pool hopping, and had a really efficient system, you might mine a pool that pays out txfees right after the network finds a block, but if it has been a while (txfees are higher), you would solo mine instead?

Yes, just as if you mined solo.

This is a likely scenario, yes, but the details will depend on how the pool calculates payments.