What happened in Block 881182?

[epomis]

https://mempool.space/block/00000000000000000001381bdc2bb40f0a4ec81efc010bef6856ce6235d7bebd

When you compare the expected and actual block there are some transactions with a lot of identical inputs in the expected block, while they are missing in the actual block. Which makes sense to me.
But why were these transactions in the expected block in the first place?
And why didn't the miner fill up the empty block space with other transactions to receive more fees?

edit:
Seems to be a F2Pool thing, as some more blocks mined by them afterwards look like this:

881187: https://mempool.space/block/00000000000000000000df46af6797bd8d6c7e2062957a521f6c9d64718ad913
881190: https://mempool.space/block/0000000000000000000262c97a4a9ab43618a385509e44a684ebff215cfc1d67
881196: https://mempool.space/block/000000000000000000028ba6f977265daa7f1e7e2c65e7a38289ffe738e5b9bf
881210: https://mempool.space/block/000000000000000000002b3e5d494ec3b85b3f951cd297d560415d062b488489

Two F2pool blocks mined afterwards look "normal":
881194: https://mempool.space/block/000000000000000000005ad8ff2646e7faeea33f5c1efabbaa02f35f5702625d
881206: https://mempool.space/block/000000000000000000018d01068a9d95d53f13350f03608c6c745b8edd14a130

[nc50lc]

edit:
Seems to be a F2Pool thing, as some more blocks mined by them afterwards look like this

Notice that if the timestamp of those blocks are about a minute later than its previous block height, the block is almost empty?
And when it's a few minutes, it's almost full?
(take note that those aren't accurate by the second but it's a good indicator of how fast those are mined)

Based from your exmaples:

• 881187 - 18:27:02 (0.30398 MWU)
  881186 - 18:26:02 (1 minute before)
  
  
• 881196 - 19:58:26  (‎2.31 MWU)
  881195 - 19:56:12 (2 minutes before)
  
  
• 881190 - 18:49:29 (3.42 MWU)
  881189 - 18:36:56 (14 minutes before)

Based from that, I think their mining pool is already providing their miners "work" (starting with zero txns) even if the previous block isn't fully validated yet.
That is to be able to immediately start mining in the next split-second while preventing the previous block's already mined transactions to be included there; then include some transactions as their mempool updates.
Pools with high latency with their miners often end up with that result and may even result with empty block (just the coinbase txn) if the block is luckily mined in seconds.

[epomis]

Thanks for your reply and good find about the timestamps. This theory fits for most of the blocks.
Though, there are some more recent examples, where the block was found several minutes after the previous one:

block        min after previous block
881285  >7   https://mempool.space/block/0000000000000000000064944fa8989cb8aaf00a576340d96bebf85e5cb7e519

I'm no expert, but I think that would be enough time to deliver a filled template, to replace a quickly sent one, as you described.


I found something about it on X, @mononautical suggesting F2pool have some technical issues: https://x.com/mononautical/status/1884193711845957733

And this isn't the first time for them, it also has happened two weeks ago: https://www.bitgetapps.com/news/detail/12560604490141

[moderator's note: consecutive posts merged]

[nc50lc]

I found something about it on X, @mononautical suggesting F2pool have some technical issues: https://x.com/mononautical/status/1884193711845957733

Hmm, that must be the reason for some of their non-full blocks that are mined in (close to) normal block time interval.
As for the blocks that are quickly mined, perhaps there's an issue with that blockmaker node's mempool causing their strategy to include less transaction than normal.
Because it shouldn't take a minute to verify a block and update their mempool to send an updated "work" to their miners.

It would be better if F2Pool has an official post regarding that.