Cluster mempool - Revision history

NotATether: Add Prior mempool model, Clusters and linearization, and Deployment sections

2026-09-13T07:35:12Z

Add Prior mempool model, Clusters and linearization, and Deployment sections

← Older revision		Revision as of 07:35, 13 September 2026
Line 1:		Line 1:
	The '''cluster mempool''' is a redesign of Bitcoin Core's unconfirmed transaction pool that groups transactions into connected components (clusters) and orders them by linearized chunk feerate. It replaced ancestor-and-descendant limits with cluster limits. Bitcoin Core 31.0 shipped the design as the mempool implementation. The change is policy and mining-algorithm internal structure, not a consensus change. It is related to but distinct from the broader topic of the [[Mempool\|mempool]].		The '''cluster mempool''' is a redesign of Bitcoin Core's unconfirmed transaction pool that groups transactions into connected components (clusters) and orders them by linearized chunk feerate. It replaced ancestor-and-descendant limits with cluster limits. Bitcoin Core 31.0 shipped the design as the mempool implementation. The change is policy and mining-algorithm internal structure, not a consensus change. It is related to but distinct from the broader topic of the [[Mempool\|mempool]].

			== Prior mempool model ==

	The pre-cluster mempool tracked, for each transaction, its unconfirmed ancestors and descendants. Mining used ancestor feerate as a proxy for whether a transaction would be selected soon. Replacement policy used that proxy plus absolute-fee and count caps. The proxy is inaccurate for graphs with several fee-payers, which led to [[Transaction pinning\|pinning]] and to block templates that left fees on the table. Child-pays-for-parent carve-out was a special case that allowed Lightning a second child; it is incompatible with a strict cluster size limit. Suhas Daftuar and others proposed bounding each connected component so that an exact linearization (an ordering of the cluster into monotonically nonincreasing feerate chunks) is computable. Incentive compatibility of a replacement then reduces to comparing feerate diagrams.		The pre-cluster mempool tracked, for each transaction, its unconfirmed ancestors and descendants. Mining used ancestor feerate as a proxy for whether a transaction would be selected soon. Replacement policy used that proxy plus absolute-fee and count caps. The proxy is inaccurate for graphs with several fee-payers, which led to [[Transaction pinning\|pinning]] and to block templates that left fees on the table. Child-pays-for-parent carve-out was a special case that allowed Lightning a second child; it is incompatible with a strict cluster size limit. Suhas Daftuar and others proposed bounding each connected component so that an exact linearization (an ordering of the cluster into monotonically nonincreasing feerate chunks) is computable. Incentive compatibility of a replacement then reduces to comparing feerate diagrams.

			== Clusters and linearization ==

	Two transactions are in the same cluster if they are linked by any chain of unconfirmed parent/child edges. Bitcoin Core 31.0 defaults to at most 64 transactions and 101 kB virtual size per cluster. Those limits can be changed with debug arguments. There are no separate ancestor or descendant count limits. Within a cluster, a linearization algorithm produces a sequence of chunks: subsets that a miner would include together. Transactions are scored by the feerate of their chunk. That score is used for selecting transactions into block templates, evicting transactions when the mempool reaches its size limit, announcing transactions to peers, and deciding whether a replacement or a package improves the mempool. RPCs <code>getmempoolcluster</code> and <code>getmempoolfeeratediagram</code> expose cluster membership, chunk grouping, and the mempool-wide feerate diagram.		Two transactions are in the same cluster if they are linked by any chain of unconfirmed parent/child edges. Bitcoin Core 31.0 defaults to at most 64 transactions and 101 kB virtual size per cluster. Those limits can be changed with debug arguments. There are no separate ancestor or descendant count limits. Within a cluster, a linearization algorithm produces a sequence of chunks: subsets that a miner would include together. Transactions are scored by the feerate of their chunk. That score is used for selecting transactions into block templates, evicting transactions when the mempool reaches its size limit, announcing transactions to peers, and deciding whether a replacement or a package improves the mempool. RPCs <code>getmempoolcluster</code> and <code>getmempoolfeeratediagram</code> expose cluster membership, chunk grouping, and the mempool-wide feerate diagram.
Line 11:		Line 15:
	Linearization aims to produce an ordering a miner would actually prefer under chunk feerate, not merely under ancestor feerate. When two replacements compete, comparing feerate diagrams asks whether the proposed mempool would confirm more fee sooner across the relevant feerate range. That comparison is tractable only because each cluster is bounded. Unbounded graphs made exact incentive checks too expensive for relay.		Linearization aims to produce an ordering a miner would actually prefer under chunk feerate, not merely under ancestor feerate. When two replacements compete, comparing feerate diagrams asks whether the proposed mempool would confirm more fee sooner across the relevant feerate range. That comparison is tractable only because each cluster is bounded. Unbounded graphs made exact incentive checks too expensive for relay.

	Wallet authors still build ordinary transactions. The practical constraint is to avoid attaching many unconfirmed parents or siblings that would merge clusters past the 64-transaction or 101 kBvB limits. [[TRUC]] packages stay inside a two-transaction cluster by construction. Mining RPCs continue to return block templates. Internally those templates are assembled from chunk scores rather than from the older ancestor-score heuristic.		== Deployment ==

			Wallet authors still build ordinary transactions. The practical constraint is to avoid attaching many unconfirmed parents or siblings that would merge clusters past the 64-transaction or 101 kBvB limits. [[TRUC]] packages stay inside a two-transaction cluster by construction. Mining RPCs continue to return block templates. Internally those templates are assembled from chunk scores rather than from the older ancestor-score heuristic. Mining templates built from chunk feerate can include packages that ancestor-score ranking would have deferred. Fee estimators that still assume ancestor buckets may need updates as cluster linearization becomes the default selection model.

	== See also ==		== See also ==

NotATether: Expand See also links

2026-09-13T07:20:42Z

Expand See also links

← Older revision		Revision as of 07:20, 13 September 2026
Line 21:		Line 21:
	* [[Fee estimation]]		* [[Fee estimation]]
	* [[Transaction pinning]]		* [[Transaction pinning]]
			* [[Anchor output]]

	== External links ==		== External links ==

NotATether: Add wallet cluster limits and mining templates

2026-09-13T07:20:40Z

Add wallet cluster limits and mining templates

← Older revision		Revision as of 07:20, 13 September 2026
Line 10:		Line 10:

	Linearization aims to produce an ordering a miner would actually prefer under chunk feerate, not merely under ancestor feerate. When two replacements compete, comparing feerate diagrams asks whether the proposed mempool would confirm more fee sooner across the relevant feerate range. That comparison is tractable only because each cluster is bounded. Unbounded graphs made exact incentive checks too expensive for relay.		Linearization aims to produce an ordering a miner would actually prefer under chunk feerate, not merely under ancestor feerate. When two replacements compete, comparing feerate diagrams asks whether the proposed mempool would confirm more fee sooner across the relevant feerate range. That comparison is tractable only because each cluster is bounded. Unbounded graphs made exact incentive checks too expensive for relay.

			Wallet authors still build ordinary transactions. The practical constraint is to avoid attaching many unconfirmed parents or siblings that would merge clusters past the 64-transaction or 101 kBvB limits. [[TRUC]] packages stay inside a two-transaction cluster by construction. Mining RPCs continue to return block templates. Internally those templates are assembled from chunk scores rather than from the older ancestor-score heuristic.

	== See also ==		== See also ==

NotATether: Add linearization and feerate diagrams

2026-09-13T07:20:39Z

Add linearization and feerate diagrams

← Older revision		Revision as of 07:20, 13 September 2026
Line 8:		Line 8:

	Bitcoin Core 31.0 is the first release in which the mempool is the cluster mempool. Mining software that consumes Core's template RPCs inherits the new ordering. Other node implementations may retain ancestor/descendant mempools. Wallets do not need a new transaction format, but Lightning and vault protocols that depended on carve-out need a TRUC migration before operators upgrade those nodes. Fee market forecasting remains covered under [[Fee estimation]].		Bitcoin Core 31.0 is the first release in which the mempool is the cluster mempool. Mining software that consumes Core's template RPCs inherits the new ordering. Other node implementations may retain ancestor/descendant mempools. Wallets do not need a new transaction format, but Lightning and vault protocols that depended on carve-out need a TRUC migration before operators upgrade those nodes. Fee market forecasting remains covered under [[Fee estimation]].

			Linearization aims to produce an ordering a miner would actually prefer under chunk feerate, not merely under ancestor feerate. When two replacements compete, comparing feerate diagrams asks whether the proposed mempool would confirm more fee sooner across the relevant feerate range. That comparison is tractable only because each cluster is bounded. Unbounded graphs made exact incentive checks too expensive for relay.

	== See also ==		== See also ==

NotATether: Create Cluster mempool stub: Core 31.0 cluster limits/linearization; TRUC/package relay; Replace by fee; no CPFP carve-out

2026-09-12T19:54:11Z

Create Cluster mempool stub: Core 31.0 cluster limits/linearization; TRUC/package relay; Replace by fee; no CPFP carve-out

New page

The '''cluster mempool''' is a redesign of Bitcoin Core's unconfirmed transaction pool that groups transactions into connected components (clusters) and orders them by linearized chunk feerate. It replaced ancestor-and-descendant limits with cluster limits. Bitcoin Core 31.0 shipped the design as the mempool implementation. The change is policy and mining-algorithm internal structure, not a consensus change. It is related to but distinct from the broader topic of the [[Mempool|mempool]].

The pre-cluster mempool tracked, for each transaction, its unconfirmed ancestors and descendants. Mining used ancestor feerate as a proxy for whether a transaction would be selected soon. Replacement policy used that proxy plus absolute-fee and count caps. The proxy is inaccurate for graphs with several fee-payers, which led to [[Transaction pinning|pinning]] and to block templates that left fees on the table. Child-pays-for-parent carve-out was a special case that allowed Lightning a second child; it is incompatible with a strict cluster size limit. Suhas Daftuar and others proposed bounding each connected component so that an exact linearization (an ordering of the cluster into monotonically nonincreasing feerate chunks) is computable. Incentive compatibility of a replacement then reduces to comparing feerate diagrams.

Two transactions are in the same cluster if they are linked by any chain of unconfirmed parent/child edges. Bitcoin Core 31.0 defaults to at most 64 transactions and 101 kB virtual size per cluster. Those limits can be changed with debug arguments. There are no separate ancestor or descendant count limits. Within a cluster, a linearization algorithm produces a sequence of chunks: subsets that a miner would include together. Transactions are scored by the feerate of their chunk. That score is used for selecting transactions into block templates, evicting transactions when the mempool reaches its size limit, announcing transactions to peers, and deciding whether a replacement or a package improves the mempool. RPCs <code>getmempoolcluster</code> and <code>getmempoolfeeratediagram</code> expose cluster membership, chunk grouping, and the mempool-wide feerate diagram.

Child-pays-for-parent carve-out is removed. Protocols that needed it are expected to use [[TRUC]] (1-parent-1-child, sibling eviction) or to stay within cluster limits. One-parent-one-child [[Package relay|package relay]] can accept a parent below minrelaytxfee, including zero fee, for both TRUC and non-TRUC packages, with the restriction that extra unconfirmed parents of the child must already be in the mempool. Cluster mempool does not by itself prevent all pinning. Absolute-fee pinning and replacement-count pinning still require topology restrictions or other rules for the worst adversarial cases. TRUC remains useful after cluster mempool for that reason. Related replacement policies include [[Replace by fee]] and [[Full RBF]].

Bitcoin Core 31.0 is the first release in which the mempool is the cluster mempool. Mining software that consumes Core's template RPCs inherits the new ordering. Other node implementations may retain ancestor/descendant mempools. Wallets do not need a new transaction format, but Lightning and vault protocols that depended on carve-out need a TRUC migration before operators upgrade those nodes. Fee market forecasting remains covered under [[Fee estimation]].

== See also ==
* [[Mempool]]
* [[TRUC]]
* [[Package relay]]
* [[Replace by fee]]
* [[Full RBF]]
* [[Fee estimation]]
* [[Transaction pinning]]

== External links ==
* [https://bitcoinops.org/en/topics/cluster-mempool/ Bitcoin Optech: Cluster mempool]
* [https://bitcoincore.org/en/releases/31.0/ Bitcoin Core 31.0 release notes]
* [https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393 Delving Bitcoin: An overview of the cluster mempool proposal]

[[Category:Technical]]
[[Category:Mining]]