Calling this one done; I've added and extended some tests, I think the coverage is OK for what this does.

What's the rational behind storing the total fee in the sector info instead of storing the fee-per-qap?

• The fee-per-qap will be smaller (slightly less state).
• The fee-per-qap won't change (unless 0).

We'd have to multiply the fee-per-qap by the qap when updating the fee, but that seems relatively simple (we can even provide a method on the sector info).

Ugh, now I remember why this didn't feel complete - I need to mess with extensions and snaps in here which do the multiplication thing. Which does go to your point about storing the multiplier rather than the final fee.

The complication I can see would be storing an appropriate QAP multipler daily_fee in the deadline since we're going to have a messy mix of different sector-level QAP. But are you suggesting storing the full fee value in the deadline but only the multiplier in the sector?

SectorOnChainInfo.daily_fee -> SectorOnChainInfo.daily_fee_multiplier (or similar) would probably be in order if we wanted to do this.

A SectorOnChainInfo::daily_fee() method as a replacement for the current daily_fee value so that whenever we need it (deadlines, expirationsets), we can easily recalculate.

But are you suggesting storing the full fee value in the deadline but only the multiplier in the sector?

Exactly.

Another downside here is that it's not as nice for end users if we return SectorOnChainInfo as it is. Unless we do the calculation and present a modified version with the actual fee. Kind of annoying.

Storing full fee in SectorOnChainInfo

• All queries to get sector info show the fee as it is
• High accuracy of fee value
• Straightforward reconciliation and accounting on chain (Deadlines, ExpirationSet)
• Straightforward testing and verification

Storing fee multiplier in SectorOnChainInfo

• Getting sector info shows a per-QAP-byte number, needs to be multiplied correctly (also note there's no pure QAP number in SectorOnChainInfo for this multiplication, we have verified weight and duration and you have to untangle them to find QAP)
• Much smaller per-sector storage requirements
• Don't need to update fee info in sector for extensions and snaps (still need to update Deadlines and ExpirationSet)

On the size:

• Full fee, in all cases (32GiB QAP through to 640GiB QAP), requires 8 bytes of storage (e.g. 5,156,022,356,586 for 32, 103,120,447,131,726 for 640 with current CS).
• Per-byte QAP multiplier requires 3 bytes of storage if we use a BigInt or 2 if we just use a cbor int (e.g. 150 for current CS)
• Per-kilobyte QAP multiplier requires 5 bytes of storage (153661 for current CS, encodes to same size as plain CBOR or BigInt)

On the accuracy:

• With full fee, we can achieve fairly high accuracy using pre-scaling before division, we do a little bit of rounding down from the original 7.4e-15 just to get a nicer multiplier -> 2.1536e-25, but it moves in step with small movements of CS
• If we use a per-byte QAP multiplier then we miss out on scaling opportunities, so we end up with a quantised CS multiplier: CS has to move 4.6M FIL in either direction to change a multiplier (we're currently at a CS of 696.8M, per-byte for steps around this are: 148 for CS values between 687.3M to 691.8M, 149 for 691.8M to 696.6M, 150 for 696.7M to 701.2M)
• We could increase precision with a per-kilobyte value (5 bytes as above) which quantises CS at 4,534 FIL

Updated the branch with adjustment for snaps and extensions. As far as I can tell the only case where power changes with extensions is if you drop_claims. Fee adjustment is new_power/old_power * fee with a large scale in there to get it accurate. Tests added to confirm that the fee changes appropriately, on top of the existing zero-fee cases where a new fee gets added. I also do some checking of deadline and expiration queue state in the process to confirm it bubbles up into the right places.

In the latest commit, 946784f, I added a sanity check in the basic fee test: we should get within 1/5th of a nanoFIL of 5155.58 nanoFil for a fee on 32GiB QAP given a CS of 696.7M. This comes from the original 7.4e-15 multiplier from the FIP, so it's also checking my per-byte multiplier. The rest of the tests do relative amounts so this one helps make sure we're not spinning off wildly without realising it.