<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://en.bitcoin.it/w/index.php?action=history&amp;feed=atom&amp;title=Cluster_mempool</id>
	<title>Cluster mempool - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://en.bitcoin.it/w/index.php?action=history&amp;feed=atom&amp;title=Cluster_mempool"/>
	<link rel="alternate" type="text/html" href="https://en.bitcoin.it/w/index.php?title=Cluster_mempool&amp;action=history"/>
	<updated>2026-09-13T04:13:44Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.43.9</generator>
	<entry>
		<id>https://en.bitcoin.it/w/index.php?title=Cluster_mempool&amp;diff=71300&amp;oldid=prev</id>
		<title>NotATether: Create Cluster mempool stub: Core 31.0 cluster limits/linearization; TRUC/package relay; Replace by fee; no CPFP carve-out</title>
		<link rel="alternate" type="text/html" href="https://en.bitcoin.it/w/index.php?title=Cluster_mempool&amp;diff=71300&amp;oldid=prev"/>
		<updated>2026-09-12T19:54:11Z</updated>

		<summary type="html">&lt;p&gt;Create Cluster mempool stub: Core 31.0 cluster limits/linearization; TRUC/package relay; Replace by fee; no CPFP carve-out&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;The &amp;#039;&amp;#039;&amp;#039;cluster mempool&amp;#039;&amp;#039;&amp;#039; is a redesign of Bitcoin Core&amp;#039;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]].&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;code&amp;gt;getmempoolcluster&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;getmempoolfeeratediagram&amp;lt;/code&amp;gt; expose cluster membership, chunk grouping, and the mempool-wide feerate diagram.&lt;br /&gt;
&lt;br /&gt;
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]].&lt;br /&gt;
&lt;br /&gt;
Bitcoin Core 31.0 is the first release in which the mempool is the cluster mempool. Mining software that consumes Core&amp;#039;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]].&lt;br /&gt;
&lt;br /&gt;
== See also ==&lt;br /&gt;
* [[Mempool]]&lt;br /&gt;
* [[TRUC]]&lt;br /&gt;
* [[Package relay]]&lt;br /&gt;
* [[Replace by fee]]&lt;br /&gt;
* [[Full RBF]]&lt;br /&gt;
* [[Fee estimation]]&lt;br /&gt;
* [[Transaction pinning]]&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
* [https://bitcoinops.org/en/topics/cluster-mempool/ Bitcoin Optech: Cluster mempool]&lt;br /&gt;
* [https://bitcoincore.org/en/releases/31.0/ Bitcoin Core 31.0 release notes]&lt;br /&gt;
* [https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393 Delving Bitcoin: An overview of the cluster mempool proposal]&lt;br /&gt;
&lt;br /&gt;
[[Category:Technical]]&lt;br /&gt;
[[Category:Mining]]&lt;/div&gt;</summary>
		<author><name>NotATether</name></author>
	</entry>
</feed>