Cluster mempool: cómo ordena Bitcoin Core las transacciones

El problema: dos órdenes que no se hablaban

Imagina cinco transacciones. A paga 3 sat/vB y es la madre de B, C y E. B y C pagan 1 sat/vB y son las madres de D, que paga 11. E paga 9. Es el ejemplo con el que Suhas Daftuar explicó el problema en Delving Bitcoin (2024). Daftuar no da los tamaños; aquí se supone que las cinco pesan lo mismo, que es lo que hace cuadrar sus cifras.

La mempool antigua usaba dos criterios distintos, los dos basados en la tasa de comisión (feerate), lo que se paga por cada vbyte, en sat/vB. Para elegir qué minar miraba la tasa de ancestros: lo que paga una transacción junto con todo lo que tiene que entrar antes. Para decidir qué desalojar cuando se llenaba miraba la tasa de descendientes: lo que paga junto con todo lo que cuelga de ella.

Con los números del ejemplo, la tasa de descendientes más baja es la de A: (3 + 1 + 1 + 11 + 9) / 5 = 5 sat/vB. Si la mempool se llena, se desaloja A y con ella todo lo que cuelga, E incluida. Pero la tasa de ancestros más alta es la de E: (3 + 9) / 2 = 6 sat/vB. Es decir, E sería de lo primero que se minaría. El nodo tira lo que un minero se llevaría antes. Daftuar lo resume así: el desalojo «does not guarantee that the first transaction evicted would be the last transaction mined».

Dos casos en que el RBF antiguo se equivocaba

El mismo desajuste afectaba al reemplazo. Las reglas de RBF de Bitcoin Core eran las de BIP-125 más una propia: el reemplazo debía pagar una tasa mayor que cada transacción con la que entraba en conflicto directo. Comparaban comisión absoluta y tasa de unas transacciones con otras, sin mirar cómo quedaba la mempool. Daftuar da dos casos en el mismo hilo.

Aceptaba un reemplazo peor. A paga 1 sat/vB y pesa 100 vB. Su hija B paga 99 sat/vB y pesa 100 vB. El paquete A+B suma 10.000 sat en 200 vB: 50 sat/vB. Alguien envía A', que gasta lo mismo que A, pesa 10.000 vB y paga 3 sat/vB (30.000 sat). Las reglas de Core lo aceptaban: paga más en total que A y B juntas y paga una tasa mayor que A. Pero se lleva por delante un paquete de 50 sat/vB para poner uno de 3. El minero cobra peor.

Rechazaba un reemplazo mejor. A paga 1 sat/vB y pesa 10.000 vB (10.000 sat). Su hija B paga 100 sat/vB y pesa 100 vB (10.000 sat). Llega B', que también es hija de A, pesa 10.000 vB y paga 49 sat/vB (490.000 sat). Se rechazaba porque su tasa (49) es menor que la de B (100). Sin embargo, el paquete A+B' rinde 500.000 sat en 20.000 vB: 25 sat/vB, frente a 20.000 sat en 10.100 vB, unos 1,98 sat/vB, de A+B. Era un reemplazo claramente mejor y no entraba.

La cluster mempool resuelve las dos cosas con una sola idea: un único orden, el del minado, que sirve para todo.

Clúster, linealización y chunk

Un clúster es el conjunto de transacciones de la mempool conectadas por relaciones de padre e hijo, en cualquier dirección. Si una transacción gasta salidas de dos grupos distintos, los fusiona en uno. Una transacción sin parientes sin confirmar es un clúster de una sola pieza.

La linealización es un orden topológico del clúster: ningún hijo aparece antes que su padre. Entre todos los órdenes posibles interesa el que se parezca más a lo que haría un minero, que primero toma los subconjuntos de mayor tasa. Bitcoin Core calcula las linealizaciones con el algoritmo SFL (spanning-forest linearization), PR #32545 de Pieter Wuille, fusionado el 19-12-2025. Según el PR, linealiza de forma óptima en decenas de microsegundos los clústeres de hasta 64 transacciones vistos en datos históricos, aunque hay casos patológicos más lentos.

Con la linealización se forman los chunks (grupos que se minan juntos). Se mira cada prefijo del orden, se elige el de mayor tasa, se retira como primer chunk y se repite con lo que queda. Por construcción, los chunks salen con tasa decreciente. Un chunk típico es un padre barato con el hijo que lo paga: ya no importa la tasa de cada pieza, importa la del chunk.

Un ejemplo más simple, con números redondos. Un padre P pesa 100 vB y paga 100 sat (1 sat/vB). Tiene dos hijas: H1 pesa 100 vB y paga 900 sat (9 sat/vB) y H2 pesa 100 vB y paga 200 sat (2 sat/vB). Los prefijos de la linealización P, H1, H2 son:

P: 100 sat / 100 vB = 1 sat/vB.
P + H1: 1.000 sat / 200 vB = 5 sat/vB.
P + H1 + H2: 1.200 sat / 300 vB = 4 sat/vB.

El mejor es P + H1, a 5 sat/vB. Ese es el primer chunk. Queda H2 solo, a 2 sat/vB, que es el segundo. Se ha pasado de tres tasas sueltas (1, 9 y 2) a dos chunks (5 y 2).

El diagrama de tasas

El diagrama de tasas (feerate diagram) dibuja esa idea en una curva. En el eje X va el tamaño acumulado y en el Y las comisiones acumuladas, recorriendo los chunks de mayor a menor tasa. Responde a una pregunta concreta: si un bloque tuviera este espacio, ¿cuánto cobraría el minero? Para el ejemplo, los puntos son (0, 0), (200 vB, 1.000 sat) y (300 vB, 1.200 sat). La curva es cóncava: empieza empinada y se aplana, porque cada chunk paga menos que el anterior.

Esa curva es lo que permite comparar dos estados de la mempool. Si una curva queda por encima o igual que otra en todos los puntos y por encima en alguno, la primera es mejor para el minero sea cual sea el tamaño del bloque. Hay una salvedad: el final del bloque. Entre dos vértices, la curva supone que cualquier trozo de un chunk rinde su tasa media. Si un chunk no cabe entero, el minero puede meter una parte respetando el orden de padres e hijos, pero esa parte no rinde lo que dice la recta.

Para qué se usa

Con los chunks ordenados, el nodo resuelve tres tareas con el mismo orden:

Plantillas de bloque. Recorren los chunks de mayor a menor tasa y los meten mientras quepan. No hace falta un criterio de ancestros aparte.
Desalojo. Cuando la mempool supera su tamaño máximo, se quita entero el chunk de peor tasa, y se repite hasta que vuelve a caber. Es el inverso exacto del minado: lo primero que se tira es lo último que se habría minado. El desajuste del ejemplo de A a E desaparece. Sus chunks, con los mismos números, son {A, E} a 6 sat/vB y {B, C, D} a 13 / 3 ≈ 4,33 sat/vB. Lo que se desaloja primero es {B, C, D}; A y E se quedan.
Retransmisión. Los anuncios de transacciones a los pares también se ordenan por chunk, de modo que lo más valioso se propaga antes.

Para saber cómo se ve la mempool desde un nodo en la práctica, hay otra entrada: cómo leer la mempool desde tu nodo.

Límites nuevos frente a antiguos

Antes cada transacción tenía su propio límite de ancestros y de descendientes. Ahora el límite es del clúster entero. La tabla compara Bitcoin Core 30.0 (notas y doc/policy/mempool-limits.md) con la 31.1 (policy.h, init.cpp y wallet/spend.cpp, v31.1):

Aspecto	Antes (30.0)	Ahora (31.1)
Qué se cuenta	Ancestros y descendientes de cada transacción	El clúster entero
Número	25 ancestros y 25 descendientes, contando la propia	64 transacciones por clúster
Tamaño	101 kvB de ancestros y 101 kvB de descendientes	101 kvB por clúster
Excepciones	CPFP carve-out y otra para el RBF de un solo conflicto	Ninguna
Opciones	`-limitancestorcount`, `-limitdescendantcount` y las de tamaño	`-limitclustercount` y `-limitclustersize` (de depuración)
Billetera (wallet) de Core	25 y 25 al elegir monedas sin confirmar	Sigue en 25, para no crear cadenas que rechazarían los nodos con versiones anteriores

Las opciones antiguas de recuento siguen en la 31.1, marcadas como obsoletas y usadas solo por la billetera; las de tamaño quedan ocultas y sin efecto. Los valores por defecto son 64 transacciones y 101 kvB. El de recuento es también el máximo: -limitclustercount puede bajarse, pero no pasar de 64.

Qué cambia si encadenas transacciones o pagas por lotes

Lo que sigue se deduce de los límites; no son cifras de las notas de versión. En un nodo 31.x, una cadena lineal de transacciones sin confirmar puede llegar a 64 (antes, 25). Un pago por lotes cuyos receptores gastan enseguida lo recibido, sin esperar confirmación, puede acumular hasta 63 hijas si el clúster no pasa de 101 kvB. Antes eran 24, porque el límite de 25 descendientes contaba también al padre, o 25 si la última cumplía las condiciones del carve-out.

Pero eso es lo que acepta un nodo 31.x. Mientras queden muchos nodos y mineros con versiones anteriores, que siguen en 25, una cadena más larga puede no propagarse. Por eso la billetera de Bitcoin Core 31 sigue limitándose a 25. Y hay topologías anchas que antes cabían y ahora no, porque antes no había tope para el grupo entero, solo para lo que cada transacción tenía por encima y por debajo.

El límite es del clúster, y en un clúster entran las transacciones de terceros que gasten tus salidas sin confirmar. Si un tercero lo llena, no puedes añadir una hija para hacer CPFP. No es nuevo: con el límite de descendientes pasaba lo mismo, y el carve-out era el parche para el caso de dos partes. Lo que cambia es que ese parche ya no existe.

RBF por diagrama de tasas

Bitcoin Core numera sus reglas de reemplazo en doc/policy/mempool-replacements.md. En la 31.1 quedan la 3, la 4, la 5 (cambiada) y una 6 nueva. La 1 (la señal de reemplazo) ya se había retirado en la 29.0, con el full-RBF. La 31.0 quita la 2 (no añadir entradas sin confirmar nuevas) y la comparación de tasas con los conflictos directos. Lo que queda:

Regla 3. La comisión absoluta del reemplazo debe ser al menos la suma de las comisiones de lo que sustituye: los conflictos y todos sus descendientes. Si el original paga 1.000 sat y su hija 400, el reemplazo paga al menos 1.400 sat.
Regla 4. La comisión extra paga el ancho de banda del reemplazo a -incrementalrelayfee, 0,1 sat/vB por defecto desde la 29.1. Un reemplazo de 500 vB debe pagar al menos 50 sat más.
Regla 5. Las transacciones con las que entra en conflicto directo no pueden estar repartidas en más de 100 clústeres distintos. Antes el tope era de 100 transacciones desalojadas.
Regla 6. El diagrama de tasas de la mempool tras el reemplazo debe mejorar de forma estricta: por encima o igual en todos los puntos y por encima en alguno. Si las curvas se cruzan, se rechaza.

Cuando la original y el reemplazo van solos, sin padres ni hijos sin confirmar, el resultado coincide con lo de siempre: si paga más comisión y una tasa mayor, entra. Fuera de ese caso, no: un reemplazo que paga más pero gasta de un padre barato sin confirmar puede bajar la curva y quedarse fuera. Con los dos ejemplos de antes:

Caso 1 (aceptaba uno peor). El diagrama antiguo pasa por (200 vB, 10.000 sat) y luego es plano. El nuevo, el de A', sube a razón de 3 sat/vB: en 200 vB solo llega a 600 sat. Más tarde, en 10.000 vB, alcanza 30.000 sat y supera al antiguo. Las curvas se cruzan, así que se rechaza.
Caso 2 (rechazaba uno mejor). El chunk {A, B'} sale a 25 sat/vB frente a unos 1,98 de {A, B}. En 10.100 vB, la curva nueva lleva 252.500 sat y la antigua 20.000. Queda por encima en todo el recorrido, se acepta. Además cumple la regla 3 (490.000 sat frente a 10.000) y la 4 (480.000 sat extra cubren de sobra los 1.000 sat que exige un tamaño de 10.000 vB a 0,1 sat/vB).

El full-RBF por defecto llegó con la 28.0, y la opción -mempoolfullrbf se eliminó en la 29.0 (PR #30592, fusionado el 08-11-2024). La explicación de qué es el RBF y cuándo usarlo está en su entrada.

El fin del CPFP carve-out, TRUC y Lightning

El carve-out (PR #15681) era una excepción al límite de descendientes. Permitía una hija más, de hasta 10.000 vB y con un único ancestro sin confirmar, aunque se rebasara el límite. Se creó, según su propia descripción, para evitar el pinning (que una parte bloquee el reemplazo o la aceleración de la transacción de la otra) en protocolos de contrato entre dos partes, como Lightning. No encaja en un clúster: el límite ya no es de una transacción sino del conjunto, y un adversario podría usar el propio límite del clúster para impedir la hija. Las notas de la 31.0 dicen que desaparece y que nada puede saltarse el límite de recuento del clúster. Los contratos que lo necesitaban deben pasar a TRUC y sibling eviction.

TRUC (transacciones con topología restringida hasta confirmarse) se describe en BIP-431, de Gloria Zhao, informativo y en estado Draft. Una transacción con nVersion=3 es reemplazable y solo se relaciona con ancestros y descendientes también TRUC. Mientras no se confirma, puede tener un padre o un hijo sin confirmar, no los dos: el clúster no pasa de dos. La transacción pesa hasta 10.000 vB y la hija hasta 1.000 vB. Puede pagar menos del mínimo de retransmisión si viaja en un paquete que sí lo cumple.

Es estándar desde la 28.0, junto con otras tres piezas:

Sibling eviction (PR #29306): una segunda hija puede desalojar a la primera aunque no entren en conflicto, si cumple las reglas de reemplazo.
Las salidas P2A (Pay-to-Anchor, PR #30352): una salida sin clave que cualquiera puede gastar para hacer CPFP.
La retransmisión 1P1C, de un padre y un hijo como paquete.

La 31.0 amplía el 1P1C: el padre puede pagar por debajo de -minrelaytxfee, incluso 0, también cuando no es TRUC (PR #33892). Desde la 30.0, la hija ya podía tener otros padres sin confirmar, siempre que estuvieran en la mempool (PR #31385).

Para Lightning, hay que separar lo que dice cada fuente. Las notas de Core no nombran Lightning. Es BIP-431 el que dice que «LN commitment transactions rely on CPFP carve out» y que «Cluster Mempool necessitates the removal of CPFP Carve Out». En consecuencia, la especificación de canales cambia: BOLTs #1228 («Zero-fee commitments using v3 transactions», de t-bast) se fusionó el 04-05-2026 y define canales con transacciones TRUC, una sola ancla P2A y ephemeral dust (una salida por debajo del umbral de polvo que se permite si la gasta la hija del mismo paquete). LDK pasó a anunciar el bit de función definitivo en abril de 2026 (PR #4515). Eclair lo añadió en modo experimental en mayo de 2026 (PR #3192). En LND está en desarrollo (PR #10479, abierto a octubre de 2026).

Qué ve un usuario y qué ve quien tiene nodo

Un usuario normal casi no nota nada. Las notas de la 31.0 lo dicen así: «Most changes should be transparent to users». Cambian los límites de las cadenas sin confirmar y algunos reemplazos que antes se aceptaban o rechazaban ahora salen al revés.

Con un nodo 31.1 hay tres llamadas útiles:

getmempoolcluster <txid> devuelve el clúster de esa transacción: clusterweight, txcount y los chunks, cada uno con chunkfee, chunkweight y sus transacciones en orden de minado.
getmempoolfeeratediagram devuelve los puntos acumulados {weight, fee} del diagrama. Es de categoría oculta: no sale en help.
getmempoolentry añade chunkweight y fees.chunk y conserva los campos de ancestros y descendientes.

Ojo con las unidades. Los tamaños van en peso, ajustado por sigops, no en vbytes: hay que dividir entre 4. Un chunk que pesa 200 vB aparece con un chunkweight cercano a 800 (si no hay ajuste por sigops). Y las comisiones salen en BTC, no en sat.

Por qué es política y no consenso

Todo lo anterior son reglas de política: lo que un nodo acepta en su mempool y retransmite. No son reglas de consenso, que definen qué bloques son válidos. Un minero puede elegir qué transacciones mete en su bloque y en qué orden, siempre que cada una vaya detrás de la que gasta, y el bloque seguirá siendo válido para toda la red. Un nodo con otra mempool, sin clústeres o con límites distintos, sigue en la misma cadena. Por eso no hace falta soft fork ni hard fork. Por eso también estos cambios se notan poco a poco: mientras convivan nodos con políticas distintas, un reemplazo o una cadena larga pueden propagarse peor.

Bitcoin Core es la implementación más extendida, pero no manda sobre la política de los demás. Hay más información en Bitcoin Core y en el mercado de comisiones.

Fechas

El PR principal, bitcoin/bitcoin #33629 «Cluster mempool», de Suhas Daftuar, se fusionó el 25-11-2025. Retoma el #28676 (2023), que partía del issue #27677.
El PR #32545 (SFL, linealización) se fusionó el 19-12-2025.
Bitcoin Core 31.0 se publicó el 19-04-2026.
La 31.1 salió el 08-07-2026 y no cambia la política.
La 32.0 no estaba publicada a 6 de octubre de 2026: la lista oficial de bitcoincore.org muestra 31.1, 31.0, 30.3, 30.2 y 30.1.

Qué significa para ti

Si usas una billetera moderna y envías transacciones de una en una, no tienes que hacer nada. Si encadenas transacciones sin confirmar o haces pagos por lotes, tu nodo acepta más que antes (64 por clúster), pero no cuentes con que la red lo propague hasta que la mayoría actualice. Y el límite se comparte con terceros, así que no des por hecho que podrás añadir una hija para acelerar. Si desarrollas con Lightning, la vía es TRUC, ancla P2A y paquetes 1P1C, no el carve-out. Y si ejecutas un nodo, getmempoolcluster te enseña por qué una transacción sale a una tasa distinta de la que pagó: la que cuenta es la de su chunk.