CPFP (Child Pays for Parent)

Una transacción atascada y una salida que se puede gastar

Imagina que alguien te paga con una tasa de comisión de 1 sat/vB y el mercado de comisiones pide 10. La transacción espera en la mempool y tú no puedes tocarla: no tienes las claves de sus entradas, así que no puedes reemplazarla. Pero sí controlas una de sus salidas. Con ella puedes construir una transacción nueva, la hija, que gasta ese dinero aún sin confirmar y paga de más. Eso es CPFP (Child Pays for Parent): la hija paga por el padre.

El truco funciona por una razón de orden. Un minero no puede meter la hija en un bloque sin el padre, porque la hija gasta una salida que solo existe si el padre va antes, en el mismo bloque o en uno anterior. Así que los valora juntos. Si el conjunto rinde más por vbyte que otras transacciones esperando, se mina entero.

El cálculo: la hija paga por los dos

La tasa que importa es la del conjunto. Según la documentación de paquetes de Bitcoin Core (doc/policy/packages.md, versión 31.1), la tasa de un paquete es el total de comisiones dividido entre el tamaño virtual total de todas sus transacciones. Un ejemplo con números redondos:

• El padre pesa 200 vB y paga 200 sat. Su tasa es de 1 sat/vB.
• Se quiere llegar a 10 sat/vB para el conjunto.
• La hija pesa 150 vB.

El paquete pesa 200 + 150 = 350 vB. A 10 sat/vB hacen falta 3.500 sat en total. El padre ya aporta 200, así que la hija paga 3.300 sat. Repartidos entre sus 150 vB, son 22 sat/vB. La comprobación: (200 + 3.300) / 350 = 10 sat/vB.

La fórmula general es esta:

comisión de la hija = tasa objetivo × (vB del padre + vB de la hija) − comisión del padre

Si sale negativo, el padre ya llega solo y no hace falta CPFP. De la fórmula sale el error más repetido sobre CPFP: la hija no paga la tasa objetivo, paga más. Cuanto más barato y más grande sea el padre, más tiene que compensar. Y si el padre arrastra ancestros sin confirmar más baratos que el objetivo, se suman sus vB y se restan sus comisiones en la misma fórmula, porque entran en el mismo conjunto.

Qué ve el minero: del paquete al chunk

Hasta la 30.x, Bitcoin Core armaba la plantilla de bloque por la tasa de cada transacción junto con sus ancestros, y para desalojar y anunciar usaba otras medidas. Desde la 31.0, según sus notas de versión, las tres cosas usan el mismo orden: la tasa a la que se espera minar cada transacción, teniendo en cuenta el conjunto o chunk de transacciones que se incluirían juntas, por ejemplo un padre y su hija. La definición de chunk, la linealización y los ejemplos con varios hijos están en clúster mempool. Aquí basta con la idea: para el nodo, {padre, hija} es un chunk a 10 sat/vB en el ejemplo anterior.

Un matiz: para que el minero vea la hija, tiene que tener también al padre en su mempool, antes o a la vez que ella. Lo segundo es la retransmisión de paquetes, más abajo.

Quién puede usarlo

Puede usar CPFP cualquiera que pueda gastar una salida del padre. Tres casos:

• El receptor, con la salida que le pagaron.
• El que pagó, gastando su salida de cambio.
• Cualquiera, si la salida es un ancla sin clave (P2A, más abajo).

Esa es la diferencia de fondo con RBF, que solo puede ejecutar quien controla las entradas de la transacción original. Tiene un precio: CPFP ocupa más espacio en la cadena, porque añade una transacción entera, mientras que RBF sustituye una por otra. A cambio, no toca la original. El txid no cambia, algo que importa en contratos firmados de antemano que ya referencian ese identificador.

Tampoco son excluyentes. Una hija CPFP se puede reemplazar por otra mejor con RBF. Y la billetera (wallet) tiene que permitir gastar salidas sin confirmar, algo que suele controlarse con coin control.

Cuando el padre ni siquiera entra: la retransmisión de paquetes 1P1C

Hay un caso más incómodo. Si el padre paga menos que el mínimo dinámico de la mempool de un nodo, por ejemplo tras una subida por congestión, ese nodo lo rechaza. La hija quedaría huérfana, porque su padre no está en ninguna parte. Antes de 2024, la hija no servía de nada en esa situación.

La solución es la retransmisión de paquetes, y hoy solo cubre un caso: un padre y un hijo (1P1C, one parent one child). No hay un mensaje nuevo entre nodos: las transacciones viajan por separado, con los mensajes de siempre, y es el nodo que las recibe quien las valida juntas.

• Bitcoin Core 28.0, 2 de octubre de 2024 (#28970). El nodo rechaza el padre por tasa baja y solo apunta su identificador. Si después le llega una hija suya, la guarda como huérfana, vuelve a pedir el padre y, cuando este falla solo, valida los dos como paquete. Los padres TRUC (transacciones de versión 3 con la topología limitada, BIP-431) pueden pagar 0. Las notas avisan de que no admite hijas con varios padres sin confirmar y de que aún no es fiable ante un adversario.
• Bitcoin Core 30.0 (#31385). La hija puede tener otros padres sin confirmar, siempre que ya estén en la mempool, y el padre puede tener a su vez ancestros en la mempool.
• Bitcoin Core 31.0 (#33892). El padre puede quedar por debajo de -minrelaytxfee, incluso con 0 de comisión, aunque no sea TRUC.

La regla de validación: cada transacción se evalúa primero sola, y solo las que fallan se evalúan como paquete, con las ya presentes en la mempool descontadas. Con un nodo propio, submitpackage mete padre e hija juntos en tu mempool (admite incluso una hija con varios padres). A partir de ahí, que lleguen a los demás nodos depende de que estos hagan 1P1C: una hija con varios padres que no tengan en su mempool no viaja como paquete, y la propia RPC avisa de que aceptarla no garantiza que se propague.

La 31.1, publicada el 8 de julio de 2026, incluye todo esto, y a 6 de octubre de 2026 era la última versión publicada (la 32.0 seguía en fase de candidata). No hay un dato público de cuántos nodos y mineros usan ya la 31.x. Un padre no TRUC a 0 sat solo llega a un minero si todos los nodos del camino la usan.

Los límites en resumen

La hija no entra si el clúster ya está lleno. En la 31.x el límite es de 64 transacciones y 101 kvB por clúster (policy.h, v31.1), y cuentan también las transacciones de terceros que gasten otras salidas del mismo padre. Desaparece además el CPFP carve-out, la excepción que dejaba añadir una hija extra por encima del límite. CPFP sigue funcionando. Lo que se pierde es la plaza reservada para una última hija cuando un tercero ha llenado el clúster; los protocolos que dependían de ella pasan a TRUC. Y mientras queden nodos 30.x, en ellos sigue el límite de 25. Para los paquetes en sí, la documentación fija 25 transacciones y 404.000 unidades de peso (101 kvB). La billetera de Core sigue limitándose a 25 y 25 al elegir monedas sin confirmar. El detalle, con tabla comparativa, está en clúster mempool.

Anclas: CPFP preparado de antemano

Los protocolos con transacciones firmadas antes de tiempo, como Lightning, no pueden saber qué comisión hará falta el día que haya que cerrar un canal. Su respuesta es dejar en la transacción de compromiso (commitment) una salida pequeña, el ancla, pensada para hacer CPFP en ese momento.

En Lightning hay dos generaciones, según BOLT 3 (consultado el 6 de octubre de 2026):

• Con option_anchors: dos anclas de 330 sat, una por parte, y 16 bloques después de que se confirme el commitment cualquiera puede barrerlas. Las demás salidas no se pueden gastar hasta un bloque después de confirmarse, como mínimo, salvo por la vía de revocación, que castiga a quien publica un estado antiguo del canal. Así nadie cuelga hijas de ellas y la plaza del carve-out queda para el ancla. Hacían falta dos anclas porque cada parte puede tener que acelerar cualquiera de los dos commitments, el suyo o el de la otra parte, y estos no se pueden reemplazar entre sí (BIP-431). Además, cada ancla va atada a la clave de una parte para que la otra no le cuelgue hijas baratas (BOLT 3).
• Con zero_fee_commitments (BOLT 9): una sola ancla compartida de tipo Pay-to-Anchor (P2A). Cualquiera puede gastarla para hacer CPFP.

Gastar una salida P2A es estándar desde la 28.0 (#30352). Su script es OP_1 0x02 0x4e 0x73, un programa testigo de versión 1 con 2 bytes, 4e73. No lleva clave, de modo que no hay nadie que deba firmar. Su umbral de polvo es de 240 sat. El ephemeral dust, estándar desde la 29.0, permite una sola salida de polvo en una transacción si esta paga 0 de comisión, a condición de que quien gaste cualquier salida sin confirmar de esa transacción gaste también el polvo. Con zero_fee_commitments, el ancla recoge lo que sobra de las salidas demasiado pequeñas para crearse y del redondeo de milisatoshis, hasta 240 sat. Si no llega a 240, el commitment paga 0 y puede llevar ese polvo; si pasa, el ancla se queda en 240 y el resto va a los mineros.

El esquema encaja con TRUC (BIP-431, aún en estado Draft): una transacción TRUC sin confirmar puede tener un padre o un hijo sin confirmar, no los dos, y su hija no pasa de 1.000 vB. El commitment viaja como paquete 1P1C. Si un tercero cuelga una hija barata, puedes desalojarla pagando más: por reemplazo si tu hija gasta la misma ancla, o por sibling eviction si gasta otra salida del commitment. Como la hija de un TRUC no pasa de 1.000 vB, desalojarla cuesta poco. Las reglas completas y el estado de cada implementación de Lightning están en clúster mempool y, para el lado de los canales, en canales avanzados.

Qué significa esto para ti

Si recibes un pago atascado y puedes gastar la salida, CPFP es la herramienta. Calcula con la fórmula de arriba: la hija debe pagar por su tamaño y por el del padre. Cuando las comisiones están bajas, desatascar cuesta poco; mira la tasa del momento en un explorador de mempool antes de calcular. Un padre por debajo de 0,1 sat/vB, el mínimo de retransmisión por defecto en la 31.1, depende de la retransmisión de paquetes para propagarse.

Tres avisos prácticos. La hija se manda a una dirección tuya. Si la salida que gastas no cubre la comisión, añade otra entrada y vuelve a calcular con el tamaño nuevo: en el ejemplo, una salida de menos de 3.300 sat no basta. Y si eres quien cobra, acelerar no asegura el pago: con full-RBF, activado por defecto desde la 28.0 y no desactivable desde la 29.0, hasta que se confirme quien te pagó puede reemplazar el padre, y tu hija desaparece con él.

Si lo que quieres es acelerar un pago propio y controlas sus entradas, compara con RBF: suele ahorrar espacio, aunque cambie el txid. Para entender cómo se forma el precio que estás pagando, mira el mercado de comisiones.