How does mempool Decide what transaction to prioritize

[Realwhot]

Lately I’ve been trying to move beyond the “Bitcoin number go up” side of things and actually understand what’s happening under the hood.

One area that’s been messing with my brain a bit is the mempool and how transactions are prioritized.

At first I thought it was simple:

You send a transaction → it enters the mempool → miners pick it → confirmed.

But the deeper I read, the more complicated it seems.

Here are a few things I’m honestly still confused about and would love clarification on from people who’ve actually run nodes or studied the protocol deeply.

1. Is transaction selection only about fee rate?

Everyone always says “higher sat/vByte wins,” but is that the full story?

Do miners strictly sort transactions by fee rate, or are there other things involved like:

[]transaction size
[]age
[]transaction dependencies
[]mempool policies

• or even private agreements?

For example, could a miner deliberately include a lower-fee transaction first for some reason?

2. Does all nodes have the exact same mempool?

This part surprised me when I started reading.

I used to imagine Bitcoin had one giant global mempool everyone shared equally, but apparently that’s not really how it works.

So now I’m wondering:

[]can two nodes have completely different mempool contents?
[]can one node see a transaction while another hasn’t received it yet?

• during congestion, do nodes start dropping different transactions independently?

If that’s true, then the mempool is more like a local view each node maintains rather than a perfectly synchronized global queue.

3. What actually happens to low-fee transactions during congestion?

Say I broadcast a transaction with a terrible fee.

Does it:

[]just sit there indefinitely,
[]eventually get dropped,

• or keep bouncing around the network until someone mines it?

And if nodes drop it from memory, does the transaction basically become “invisible” unless rebroadcast?

I’ve seen people say:

“Your transaction is stuck.”

But technically, what does “stuck” even mean inside the network?

4. Replace By Fee (RBF) still confuse me.

I understand the idea that you have to rebroadcast the same transaction with a bigger fee to attract miners.

But I still don’t fully understand the mechanics.

Is RBF automatically honored by all nodes?

Can some nodes reject replacements?

Can miners completely ignore the replacement and mine the original anyway?

What happens if different nodes accept different versions temporarily?

The more I think about it, the more it feels like mempool policy is partially standardized but also partially discretionary.

5. Can miners include transactions “out of order”?

This is something I rarely see discussed.

Imagine someone contacts a mining pool privately and says:

“I’ll pay you directly if you include my transaction immediately.”

Could a miner:

[]prioritize that transaction regardless of mempool ordering,
[]include a low-fee transaction intentionally,

• or even mine transactions that never propagated widely?

In other words, how much of transaction selection is consensus… and how much is simply miner preference?

6. About block templates…

I recently learned miners build something called a block template before mining.

From what I understand, they’re basically trying to maximize total fee revenue within the block size/weight limit.

If that’s true, are miners effectively running an optimization algorithm every time they assemble a block?

Because once transaction dependencies, package fees, CPFP, and weight limits come into play, it sounds way more complicated than:

“Pick highest fee transactions first.”

7. Does mempool age matter at all?

This is the question that really got me thinking.

Suppose:

Transaction A has a low fee but has been waiting for 5 days

Transaction B has a higher fee and was broadcast 10 seconds ago

Does the older transaction gain any priority over time?

Or is Bitcoin mempool logic basically:

“Fees rule everything forever”?

Because if age doesn’t matter at all, then the mempool behaves less like a queue and more like a continuous fee auction.

I’d really appreciate insights from people who:

[]run full nodes,
[]monitor mempool activity,
[]mine,
[]or understand Bitcoin Core internals better than the average user.

The more I study Bitcoin, the more I realize the mempool is probably one of the most misunderstood parts of the system.

[Charcol]

Your post would probably have been the best decision for the "Bitcoin Technical Support" board. Because every question in your post is directly related to the discussion on the "Bitcoin Technical Support" board.

[Upgrade00]

1. Is transaction selection only about fee rate?

Everyone always says “higher sat/vByte wins,” but is that the full story?

Do miners strictly sort transactions by fee rate, or are there other things involved like:

[]transaction size
[]age
[]transaction dependencies
[]mempool policies

• or even private agreements?

For example, could a miner deliberately include a lower-fee transaction first for some reason?

Feerate already accounts for the size, as it's the amount of sats per vbyte and this is the most important metric to miners, they are there to maximize profits at the end of the day. They can independently include or exclude a transaction from their block but the common occurrence is the tx with the highest feerate getting in first.

2. Does all nodes have the exact same mempool?

This part surprised me when I started reading.

I used to imagine Bitcoin had one giant global mempool everyone shared equally, but apparently that’s not really how it works.

So now I’m wondering:

[]can two nodes have completely different mempool contents?
[]can one node see a transaction while another hasn’t received it yet?

• during congestion, do nodes start dropping different transactions independently?

If that’s true, then the mempool is more like a local view each node maintains rather than a perfectly synchronized global queue.

Mempools arr fairly standard from node to node. Each node can have different settings so the transactions they hold may not always be exact, but several settings/policies are standard so it's unlikely for 2 nodes to have completely different transactions.
How txs are dropped too depends on the nodes settings, it's usually set at 2 weeks but it can vary with some nodes.

Mempool is very much synchronized, if it weren't txs will not have any order in how they are confirmed.

3. What actually happens to low-fee transactions during congestion?

Say I broadcast a transaction with a terrible fee.

Does it:

[]just sit there indefinitely,
[]eventually get dropped,

• or keep bouncing around the network until someone mines it?

And if nodes drop it from memory, does the transaction basically become “invisible” unless rebroadcast?

I’ve seen people say:

“Your transaction is stuck.”

But technically, what does “stuck” even mean inside the network?

This depends on the general setting, it'll usually sit in for about 2 weeks with most nodes after which it will be dropped but it could also be dropped if most nodes go above their size limit and have to include priority txs. It can also be rebroadcasted at anytime and remain in the pool indefinitely.

I'll return to the other questions in a bit if they've not already been answered by that time.

[stwenhao]

For example, could a miner deliberately include a lower-fee transaction first for some reason?

Of course. For example: https://mempool.space/testnet/tx/2703e6d0215261d4916e0436438a366f4198fe473ff856036e01306ddce20315

This miner included his zero fee transaction first, before other transactions.

Does all nodes have the exact same mempool?

No. Each node has its own mempool.

can one node see a transaction while another hasn’t received it yet?

Of course.

What actually happens to low-fee transactions during congestion?

By default, it is dropped after two weeks. However, any node can decide to store it forever, and broadcast it later.

But technically, what does “stuck” even mean inside the network?

It means that a given node can refuse to drop it for whatever reason (for example because of using the old software).

If you use the latest version, then transactions with lower fees can be replaced by bigger fees. Which makes it possible to "unstuck" it.

Is RBF automatically honored by all nodes?

Only by those, who upgraded their code.

Can some nodes reject replacements?

Yes.

Can miners completely ignore the replacement and mine the original anyway?

Of course.

What happens if different nodes accept different versions temporarily?

Nothing, because after reaching a single confirmation, everyone will know, which version was placed in a block. And all new blocks on top of it simply couldn't include a second version, without invalidating that block.

This is the whole reason, why miners are needed in general. Because Alice could create two transactions: one sending coins to Bob, and one sending coins to Charlie. She could broadcast different transactions to different nodes. And then, whatever miners include first, will be enforced in practice.

Can miners include transactions “out of order”?

Only if transactions are independent. If you have Alice to Bob transaction, and Bob to Charlie transaction, using Bob's coins, received from the previous transaction, then they have to happen in order. But if they are completely disconnected, then miners can swap them as they wish.

or even mine transactions that never propagated widely?

Of course. You can send a transaction only to a given miner, and nowhere else. If that miner will include it directly into the block, then the rest of the network will get it, only when that block will be mined. This is how people get non-standard transactions confirmed, or solve transaction puzzles, where revealing the public key would allow moving the coins by someone else (because of weak N-bit private key).

If that’s true, are miners effectively running an optimization algorithm every time they assemble a block?

Yes. They just create a template, where they pick some transactions, and then they constantly replace some transactions with others, to get more fees out of it. But in general, mining is NP-hard, and they solve the knapsack problem here.

Does the older transaction gain any priority over time?

It was the case in the older versions: https://en.bitcoin.it/wiki/Miner_fees#Priority_transactions

Now, it is counted in satoshis per virtual kilobyte.

[hmbdofficial]

Of course. You can send a transaction only to a given miner, and nowhere else. If that miner will include it directly into the block, then the rest of the network will get it, only when that block will be mined. This is how people get non-standard transactions confirmed, or solve transaction puzzles, where revealing the public key would allow moving the coins by someone else (because of weak N-bit private key).

once the miner includes your transaction in the block and broadcast that block, how does the rest of the network react if the transaction was never in the public mempool? Do nodes accept it cleanly as part of the block, or do you miners see it sometimes it as trn- mempool -conflict or other validation issues ?

[hosemary]

once the miner includes your transaction in the block and broadcast that block, how does the rest of the network react if the transaction was never in the public mempool? Do nodes accept it cleanly as part of the block, or do you miners see it sometimes it as trn- mempool -conflict or other validation issues ?

Once a node receives a new block, it check whether the block is valid or not. If the block is valid, the nodes adds it to their copy of the blockchain.
It doesn't matter whether the node had the transactions in their mempool or not.

Also note that each node has its own mempool and therefore there are always transactions that nodes adds to their copy of the blockchain even though they never had them in their mempool.

[stwenhao]

how does the rest of the network react if the transaction was never in the public mempool?

By default, they accept the new block as valid, and reject all conflicting transactions, which they had in their mempools. Note that the coinbase transaction is also never in the public mempool, but it is normally accepted as valid.

Of course, some miners can try to reject a given block, but then, they usually need two blocks to do that. Because blocks are accepted, based on first-seen rule: if you produce a different block on the same height, then you need a second block on top of it, to trigger chain reorganization.

And also, sometimes two blocks can be broadcasted at almost the same time (and they can contain different transactions), and then, the next block will show everyone, which chain is the correct one.

[nc50lc]

I feel like you already know the answers to some of your questions considering some of the questions are related to the answers to the previous ones.
Confirming already researched subjects I guess.

Anyways, I'll just add some notes to these parts with keywords to DYOR:

4. Replace By Fee (RBF) still confuse me.

I understand the idea that you have to rebroadcast the same transaction with a bigger fee to attract miners.
-snip-
The more I think about it, the more it feels like mempool policy is partially standardized but also partially discretionary.

It doesn't have to be the same transaction, the replacement can use only one of the input of the original transaction, it can also replace all of the outputs set by the original transaction.

RBF is taking advantage of the "UTXO model" that Bitcoin uses:
Since it can only be spent once, a new transaction that spent any of the UTXO used as input by an unconfirmed transaction will make it its "replacement" whether there are originally 10 other inputs there.
Of course, it still depends on how both transactions will propagate and which one will be included to a block first.

And yeah, it's a decentralized system so you can't just force everyone to follow a certain policy.
Most of the standards are set by default, but node operators can still change it through either their config, using different client or changes in the code.

5. Can miners include transactions “out of order”?

Imagine someone contacts a mining pool privately and says:

“I’ll pay you directly if you include my transaction immediately.”

This is exactly what those "Transaction Accelerators" are.
You may not heard of it since it's not famous today with the implementation of "full-RBF" and overall lower average fee rate;
But in the past, people are getting in line to just use such free service if they can't bump their transaction.
(not to be mistaken with those rebroadcast services that advertised themselves as transaction accelerators)

Because if age doesn’t matter at all, then the mempool behaves less like a queue and more like a continuous fee auction.

That's a good interpretation, this is why we have full-RBF/opt-in RBF and it's enforced by the majority of the nodes.

[hmbdofficial]

Replace By Fee (RBF) still confuse me.

I do hope this my simple way of explaining it to you makes your understanding better. It’s when your transaction get stocked probably due to a very small that u decide to pay during  the process of initiating the the transaction. obviously miners will not pick your transaction to broadcast it and add it to be next block there for and if you don’t want your transaction stocked for long you have the option of Replace-by-fee RBF and also Child pay for parent CPFP

I understand the idea that you have to rebroadcast the same transaction with a bigger fee to attract miners.

But I still don’t fully understand the mechanics.

It’s just about how much fee you’re paying to attract miners actually, because Miners always priorities transactions  with higher fees. It’s just a simple logic, I want the work i start which got stocked because I didn’t pay enough fee for the labor done now, I’ll need to pay more fee to get it finish.

Is RBF automatically honored by all nodes?

Yes

Can some nodes reject replacements?

Every node is an individual entity even though there is a consensus in it protocol when it comes to transactions fee each node decides what fee is okay for them.

Can miners completely ignore the replacement and mine the original anyway?

What origin way? you mean paying a higher fee from the initial transaction? If that was done there won’t be stocked transactions and there will be no need for RBF

[satscraper]

For example, could a miner deliberately include a lower-fee transaction first for some reason?

AFAIK, in early‑age Bitcoin the reason miners included low‑fee transactions first was the coin‑age priority system. There was even a priority parameter that calculated UTXO age, but it stopped mattering for miners a long time ago. I don’t remember exactly when, but it’s no longer used. The reasons miners may include the lower‑fee transaction today might be 1)transaction is their own, or, 2) someone made an agreement with them.

[Zaguru12]

Can miners completely ignore the replacement and mine the original anyway?

What origin way? you mean paying a higher fee from the initial transaction? If that was done there won’t be stocked transactions and there will be no need for RBF

I think the question is actually about if someone does an RBF if the miners will actually drop the first transaction (original transaction) and replace it the new one, or they will decide to keep the original transaction. Actually the nodes have their own right of replacing or not replacing new transactions in their mempool, but one thing is most nodes are now full RBF enabled which means they accept transaction replacement. This is even logical since they most prioritize transactions base on fees

But let’s say for instance a node decides to keep the original transaction and not replaced it with the new then and then this node actually gets to mine a valid block with this transaction in it, other nodes will just verify if the block is valid and then add it to their blockchain and consequently remove that RBFed transaction from their mempool because it’s has already been invalidated since it’s input has already been spent by the original transaction.

So there is nothing actually wrong in nodes keeping hold of the old transaction but in reality the new transaction with higher fee is definitely going to be confirmed first due up fee priority and it will render that old transaction invalid