How are blocks built? Is it really just about maximizing revenue?

I'm curious about how blocks get constructed, especially with the new fees at 0.1 sat/b. Here’s what’s on my mind: a) You've got a block that’s half filled with transactions at 2 sat/vb. Then, there’s one more transaction that’s at 1.99 sat/vb, which could fill up another 30% of the block space. But then two more transactions come in at 1.98 sat/vb, each taking up 25%. So, what happens? Do miners prioritize higher revenue or just the order of the fees? b) Let’s say the first ten transactions are all at 100 sat/vb. Then, the next one comes in at 99 sat/vb and it’s a full block ordinal, while the rest are just at 0.1 sat/vb. Would it make sense for miners to go for profitability again, or would they just drop the full block size transaction? I’ve looked around for answers and it seems like miners should be focusing on profitability. So, why are some mining pools still going for blocks that are empty when they could easily fill them with smaller transactions from the mempool?

empty blocks can occur few a few reasons. Rapid fire hitting of blocks and an empty or close to empty memory pool is always a possibility for an empty block. Or some pools shoot for a short cut prebuilt header which creates a small head start. second case possibility. I am sure there are other ways someone may explain other reasons. The first one do one can do anything about and will happen at times. the second one is a bet that a pool makes ie a block of 3.125 + 0 every 59 minutes is better than a block of 3.125+0.05 =3.175 coins every 60 minutes those numbers are approximate but this is what antpool tries to do . And they certainly do hit more blocks with the shortcut they take and they certainly get less fees with the short cut they take. It would take a ton of math to figure if what they do pays off. as I do not know how much time they save and how much faster they make blocks. I estimated 1 block every 59 minutes vs 1 block every 60 minutes but maybe the number is 1 block every 32 minutes =0.533 hours short cut vs 1 block every 32 minutes and 30 seconds =no short cut it would be very challenging to figure out if they make more money their way. I can tell you this method is likely to work better with larger pools than pools with very little hash.  but I do not know how much speed they gain. as to why some pools decide to skip  >0.9 or lower fees once again the stats do not exist no one has studied which method works better. It could be it is being studied as I type. and we may see all pools go to 0.1 min or 0.2 min or whatever.

-ck has already come out as being against sub 1-sat fees and will not accept them for processing. I agree as it is encouraging what amounts to the 'new' spamming of the blockchain.

The answer is simple. Miners always try to maximize their profit. They will include one of the transactions paying 1.98 sat/vbyte and transaction(s) with lower fee rate to fill the block as much as much possible and maximize their profit. That's just because some miners have not changed their policy rules yet. More and more miners will accept such transactions in the future.

Thanks chatgpt but you don't make any sense! Interesting, I counted only two large pools that do the same viabtc and mara, a bit surprised that building a larger block could mean you lose the race as this seems to be the issue as far as I can understand.

the problem is how to figure out which is better for a pool to make money ck pool makes very few blocks as it is for solo so ck has the luxury of doing it pretty much any way that works. bigger pools making 10% of the blocks daily  have a harder call. I think they are researching as I type. We may see a full switch for the 10% pools to 0.1 sats per byte by summer of 2026 if they think it is better. One way to understand this is to have 1 or 2 big pools not doing it. viabtv and mara do it one way and ant pool and f2 pool do it the other. then then compare results in a year.

You raised a good question, and this topic is a bit more complicated than it seems. The first thing you need to understand is that most pools use a Branch n bound (bnb), knapsack, and Single Random Draw (SRD) algorithms to fill blocks with transactions, all of which fall under one term, which is "Coin selection." Now, obviously, this coin selection faces the unsolvable knapsack problem. However, the default behavior is "greedy highest-fee-rate packages"; the end goal is to get the most total fees available even if that means ditching the highest-paying transactions. In your example the protocol would ditch the 1.99 sat in favor of the two 1.98 sat transactions. However, there is another piece of information that you need to know: the default core settings that deal with fee rate play a massive role in the propagation and inclusion of transactions. There are two of them: minrelaytxfee and blockmintxfee. The former sets the minimum fee for transactions to be accepted into its mempool and to relay them while the latter sets the minimum for transactions that it would pass to getblocktemplate. It's safe to assume that most pools had their settings to the default, so not only were they not including transactions, they are not "seeing" them in the first place. Obviously, most 'greedy' pools started to relax that limit and based on my observation, here is the current status as of now Pools that dropped the limits: Antpool Foundry spiderPool F2pool Luxor Secpool MiningSquared Still running the default: SBI Innopolis Tech ViaBTC Mara pool   If the question is, Should pools stick to the default 1 sat policy or not?, then that would require a whole different topic and endless discussion, just like the ordinals debate that we have been having forever. No, not that; it's not building larger blocks that makes you lose the race. it's actually being out of sync. in compact block relay, you are always better off with having all the transactions stored in your mempool so that once you receive a new block, you can immediately verify it and start building the next block on top of it. if the block contains transactions that you don't already know about, you will need to request that from your connected peers. that could take a few extra seconds, which you could otherwise avoid simply by storing those transactions in your mempool even with the intention of never wanting to include them in your own block template There is no "problem in regards to profit," as far as I can see it. pools that still have their blockmintxfee set to 1 sat are losing money to pools that lowered that. when you leave half a block empty, you simply are losing money; however, the entire sum of those tiny transactions is very small, and is very freaking damaging to BTC as it increases the UTXO set at virtually no cost. having a large UTXO means full nodes need to store more data, use more RAM, and have slower validation of new transactions and blocks. The UTXO set problem is real, and once a UTXO is created, it will always be there until spent, giving spammers a cheap path to spam could result in catastrophic damage.

Yeah Mikey its even hard  for a major pool to know what to do. And the shortcut template along with allowing 0.1 or 0.2 or 0.3 up to 1.0 as a minimum all make it harder to track what is best. Just imagine if some genius adds sporadic ordinals to the mix.

It's kinda like an example of a high frequency trading strategy applied to a decentralized network. Basically you're betting on volume and speed over maximizing the value of each individual block. The logic is that if you're a big enough player those fractions of a second you save by not waiting for the mempool to fill up will over time add up to more total block rewards than the sum of all the fees you missed. I see it as a game of probabilities and large numbers and for a pool with a significant percentage of the network hash rate it might be the only logical way to compete at the very top. But do you think this kind of incentive could ever become the dominant method for all pools even smaller ones?

No, mining doesn't work like that; no pool waits for their mempool to fill up. While this is off-topic, here is how it works. Type 1 pools: They start mining before downloading and verifying the block (just the block header is enough); they save a little bit of time (a few milliseconds or maybe a whole second!) and these are subject to mining empty blocks not because their mempool is empty, but because they do not know which transactions were included in the last block, if they happen to include any of the already included transactions in their newly mined block, the block will be rejected by the entire network since it contains an output that has already been spent. Type 2 pools: They download the entire block, get all the transactions in it, remove them from their mempool and start mining the new block. These pools will never mine an empty block unless their mempool is actually empty (extremely unlikely to be the case). All of the above is unrelated to this topic, by the way. you could read my previous reply for more info.