Before a transaction enters a block, it sits in nodes' mempools. Consensus rules say what can go in a block. Policy rules, chosen by each node, decide what a node will store and relay. Bitcoin Core's defaults shape most of the network.
Key policy rules in Bitcoin Core
- Size: the mempool is limited to 300 MB by default. When it is full, the lowest-feerate transactions are evicted and the minimum fee rises.
- Expiry: transactions are dropped after 336 hours (two weeks) by default.
- Standardness: only known script types, limited transaction size, and outputs above the "dust" threshold are relayed.
- Minimum relay fee: very low-fee transactions are ignored.
- Package limits: chains of connected unconfirmed transactions are capped.
Feerate is king
Miners want the highest fee per weight unit, so fees are quoted in sat/vB. A 140 vB transaction paying 1,400 sats pays 10 sat/vB. Size depends on inputs and script type, not on the amount sent.
Bumping a stuck transaction
RBF (Replace-By-Fee): broadcast a new version spending the same inputs with a higher fee. The replacement must pay a higher absolute fee and feerate and cover its own relay. BIP125 defined opt-in signalling via nSequence, and since Bitcoin Core 28.0, full RBF is the default, so any unconfirmed transaction can be replaced.
CPFP (Child Pays For Parent): spend an output of the stuck transaction with a high fee. Miners evaluate the package, so the child pulls the parent in.
Pinning and package relay
In shared contracts like Lightning, a counterparty can "pin" a transaction, for example by attaching a large low-fee child, which makes replacement expensive. Bitcoin Core 28.0 added one-parent-one-child package relay and v3 "TRUC" transactions with tighter limits, so a low-fee parent can still be relayed with a high-fee child.
Takeaway
Zero-confirmation transactions are not final. Policy can change between versions, but consensus rules cannot change without a fork.