Coincidence or Deliberate Action?

So, I was browsing the mempool earlier today and noticed something interesting. Fees seem pretty low right now, at least somewhat reasonable. Then I saw that ViaBTC mining pool just mined a block with hardly any transactions in it. I thought that was odd, so I checked their previous blocks and saw that out of their last five blocks, four had very few transactions compared to others I've seen before. The only thing that came to mind is that they might be focusing more on the block subsidy than on transaction fees, which could explain why they're including fewer transactions in their blocks. But I'm not really sure. What do you guys think? Just random chance, or do you think there's a plan behind this? P.S. They just mined another one with only 88 transactions, making it 5 out of 6.

I think some mining pools didn't start accepting transactions with lower fees than 1 sat/vB. And in that case, they simply don't see them, so they don't include them in their blocks. Here is how you can create low fee transaction manually: https://bitcointalk.org/index.php?topic=2848987.msg65603214#msg65603214 Probably, there are some options to do it from some GUI, but this change is quite recent, so wallets and mining pools didn't update their settings yet. Or: some of them may think, that 1 sat/vB as a minimum is a good choice, and shouldn't be lowered. Some ongoing pull request about it: https://github.com/bitcoin/bitcoin/pull/32959

I would have certainly liked to give it a try (i.e, tx with a very low fee), but I'm not sure how long it will take BlueWallet to implement it. And the manual procedure seems a bit complex, but I will take my time to give it a try before bluewallet or some other wallet implements theirs. (Saw a user sharing the info (from BlueWallet) from one of the links you provided.) Appreciate the detailed explanation...

I don’t really get the technicality of mining but, from mere observation of the image in the OP, The 4 which is presumably not filled blocks seems to record more transactions in numbers than it actually holds in Bitcoins and took more time. The transactions as per number of transactions for blocks that did accept 1sat/vByte did range between 4,499 - 5,094 number of transactions, holding at least 0.006BTC to 0.008BTC and took over 18+ minutes to conclude. While, the block that had more holdings in the value of 0.028BTC had a mining fee of at least 2sat/vByte and concluded in the shortest possible time between the 5 blocks which was in 9minutes. My deductions to this is that (only trying to understand and not as though I know these so, my deductions here are only implied from observation and in respect to what I’ve read thus far.): The 2sat/vByte block is a high transaction period block which applied high fees to filter while and was able to accommodate more high valued transactions while, The 1sat/vByte blocks is a low transaction period which used more time to accommodate several low valued transactions. Is there any relative value to how much transaction a block should contain? And what is the determinant to when a block is said to be filled and should be left alone to continue other blocks since, There is no defined time from observation of the image in the OP? and There is no capped value for Bitcoin or number of transactions that fills a block?

One upper limit for how many transactions can go into a block is 4,000,000WU (weight units, where 1 byte of witness data accounts for 1WU, while for non-witness transaction data 1 Byte accounts for 4WU. There's no relation between number of transactions in a candidate block and how long it takes to mine a valid blockheader hash. Depending on how many unconfirmed transactions are available in the mempool of a mining pool, a block candidate is commonly (quite simplified) assembled with transactions (or transaction packages in the case of child-pays-for-parents chains, parents must occur before child in block) from highest fee rate to lowest until the block is full (not exceeding 4M WU). This usually gives the mining pool maximum profit from available transaction fees in mempool. There are more limits to pay attention to, like number of Sigops can't exceed 80,000 (there has been at least one broadcasted invalid block exceeding this limit by a small amount, I think last year, big oopsie by certain mining pool, lol). In times when mempool isn't full enough to fill a block with transactions equal and above fee rate of 1sat/vB it makes economical sense to include transactions that pay less than 1sat/vB when those are available in mempool. Not all mining pools do that, so far. Some do...

It's not too complex although I don't really find an urgency in the need to. For months now I've constantly transacted with 1 sat/byte as fee rate which is fine since the time of confirmation is usually around the medium and fast set of transactions. When the mempool is having the fast set fees with an average of  1 sat/byte, 0.8 sat/ byte or less could get the transaction confirmed but it may not be fine to risk using less than 1 sat/byte since a majority of pools these days still have it as their purge fee. Though fees are still a little high compared to a year or two ago, plus they also depend on your number of UTXOs, it's still quite fair considering the average sender's UTXO count.