GetBestMiningCandidate & F3

[Stebalien]

When we pick a base on which to mine, we compare:

1. The current chain head.
2. The last tipset we mined on.

If the last tipset we mined on is heavier, we'll stick with that. This leads to a problematic situation:

1. We try mining on X.
2. F3 finalizes Y at the same height, Y is lighter than X.
3. We will keep trying to mine on X until someone else mines a block on Y.

• One option here is to remove the lastWork field, I'm not 100% sure why we have it.
• Another is to change ChainTipSetWeight to take checkpoints into account and set the weight to 0 for any tipset not compatible with the current checkpoint. We need to be careful here in case the tipset weight is used anywhere else, but I don't think it is?
• The best option is probably just to ask lotus about the current checkpoint.

[Stebalien]

Note: I have no idea if this is actually the issue, but it's very suspicious. We need to audit all the miner code for unexpected gotchas.

[Kubuxu]

I'm pretty certain the reason for this existing is catchup mining, where when we fast loop and lotus takes too long to update the head. Also, it would be an issue almost for sure. It might not be the actual cause of what we observe, but I can see it crop up.

[Stebalien]

Ok, I'm pretty sure there's no point behind lastWork. It's only useful if lotus returns a block that's weighs less than the last block it returned. I guess maybe it's to solve the issue of lotus crashing, restarting, and... coming up with a worse block? I'm not convinced.

To be clear, lastWork literally just returns the best block we've seen from ChainHead. We don't update it anywhere except in GetBestMiningCandidate.

[Stebalien]

Oh! Maybe the concern is multiple lotus nodes where one is behind? I mean, this isn't really the right way to deal with that especially because we completely ignore anything we mined.

[Stebalien]

It looks like we keep it for side effects in some cases... E.g., we shove the null rounds it it.

[Stebalien]

Yeah, the issue is catch-up mining, but it's not about being "fast", it's about null rounds. When catching up, we keep trying to mine on every round after our last tipset until we either see a better head or win a block. Of course... we don't wait after winning which means it's kind of broken.

Unfortunately, I'm not sure if I can trivially remove the "take heaviest" rule because, due to F3, we can flip-flop. I.e.:

1. Take base A.
2. Try to mine 10 null blocks on A.
3. See a better base B, mine 10 null blocks on B.
4. F3 finalizes A, so we switch back to it.

At that point, we'd want to pick up at A+11, not A+1.

[Stebalien]

Ok, there's a simple fix: we can't mine at the same height anyways. So we'll just track the last height we've successfully determined we didn't win and use that to calculate nulls.

[Kubuxu]

Fixed in filecoin-project/lotus#12690