Mempool

From Bitcoin Wiki
(Redirected from Transaction pinning)
Jump to navigation Jump to search

The mempool (memory pool) is a node's collection of valid, unconfirmed transactions that it may later include in a block or relay to peers. There is no global mempool. Each node maintains its own pool according to consensus rules plus local policy, so two honest nodes can disagree about which unconfirmed transactions they hold.

A transaction is accepted only if it is consensus-valid given the current UTXO set and the transactions already in the pool, and if it passes local policy. Typical policy includes a minimum relay fee rate, standard scripts, and a maximum pool size after which the lowest-feerate transactions are evicted. Transactions that spend outputs not yet known to the node are kept in a separate orphanage until their parents arrive. The mempool is not consensus-critical. A miner may include any consensus-valid transaction, including one its peers would not relay.

Cluster mempool

Bitcoin Core 31.0 reimplemented the pool as a cluster mempool. Transactions that share any chain of unconfirmed parent or child relationships form a cluster. Clusters are ordered by the feerate of linearized chunks. Default policy limits each cluster to 64 transactions and 101 kB of virtual size. Ancestor and descendant limits are no longer enforced. Replacements are accepted only if the resulting feerate diagram is strictly better than before. The CPFP carve-out is removed. Protocols that needed it are expected to use TRUC. The change is not a consensus change.

Transaction pinning

Transaction pinning is a class of mempool-policy attacks in which one party makes fee-bumping of a shared unconfirmed transaction prohibitively expensive, or impossible, by exploiting relay and replacement limits that exist to resist denial of service. The victim still holds a valid signature. Policy, not consensus, is what blocks a timely confirmation. Pinning matters for multiparty contracts such as Lightning Network commitment transactions, where more than one person can attach a descendant or submit a conflicting replacement.

One style inflates the absolute fee a Replace by fee replacement must beat by attaching a large low-feerate child to the shared parent (BIP 125 rule 3 requires a higher absolute fee than the transactions being replaced, not a higher feerate by itself). Another style fills package or cluster limits so the honest party cannot attach a child-pays-for-parent bump. TRUC bounds the topology to one parent and one child with a small child size limit and sibling eviction. Cluster mempool reduces some pins and removes CPFP carve-out, but does not eliminate all absolute-fee pins. A miner who sees the honest transaction can still include it.

See also

External links