Imagina que alguien te ha enviado bitcoin con una comisión baja y el pago sigue sin confirmar. Si tu monedero permite usar CPFP con ese pago, puedes crear otra transacción, quizá a otra dirección tuya. La original se llama transacción madre y la nueva, transacción hija: esta gasta una salida, es decir, una cantidad con condiciones de gasto, creada por la madre. Para cobrar la comisión de la hija, el minero necesita también a la madre. El pago original no cambia; ofrecer más comisiones puede ayudar a confirmarlo, pero no garantiza cuándo ocurrirá.
Anna espera recibir 100 000 sat. La abreviatura sat significa satoshi, la unidad más pequeña de bitcoin. Ya ve el pago, pero el remitente eligió una comisión baja y todavía no está en un bloque. Su monedero le permite gastar esa salida sin confirmar. Anna crea con ella otra transacción a una dirección propia y ofrece una comisión mayor. No está pagando al remitente ni a un servicio especial: paga una comisión de transacción normal de Bitcoin. El minero no puede confirmar la nueva transacción sin la original, porque la salida que gasta no existiría en la cadena que se está validando. La madre debe haberse confirmado antes o aparecer antes que la hija en el mismo bloque, junto con los demás antecesores sin confirmar que sean necesarios. Lo contrario no se exige: la madre puede confirmarse sin la hija. [3] [5]
Veamos un ejemplo sencillo sin otros antecesores pendientes. La madre ocupa 200 vB y paga 200 sat. El byte virtual, vB, mide un tamaño derivado del peso de la transacción; sat/vB indica cuántos satoshis se ofrecen por cada unidad. La hija ocupa 100 vB y Anna paga 2 800 sat por ella. Si solo tiene una salida, de los 100 000 sat recibidos le quedan 97 200 sat. En conjunto, ambas transacciones pagan 3 000 sat por 300 vB: 10 sat/vB. La hija por sí sola ofrece 28 sat/vB, pero el minero también debe incluir a la madre, cuya comisión es baja. Mirar solo la cifra alta de la hija deja fuera esa dependencia. Es un cálculo ilustrativo, no una recomendación de tarifa actual; el monedero comprueba los tamaños reales y la comisión total necesaria. Otros antecesores necesarios cambiarían el cálculo. Un detalle avanzado: al aceptar localmente un paquete, las transacciones ya aceptadas no vuelven a contarse y el nodo —un programa que verifica y retransmite transacciones— puede usar comisiones modificadas. La tarifa que muestre en ese contexto no tiene por qué coincidir con el cálculo conjunto sencillo para un minero. La comisión modificada es un valor local que usa el nodo para decidir; no cambia la comisión que realmente paga la transacción. [3]
CPFP no es un botón con el que cualquiera pueda acelerar una transacción ajena. Necesitas poder gastar una salida de la madre y cumplir sus condiciones, incluidas las firmas. Anna puede hacerlo como destinataria; el remitente podría usar una salida que le devuelve el importe sobrante, llamada change. Ver una cantidad en un explorador o en una Watch-only Wallet no basta. Una Watch-only Wallet sirve para seguir los pagos, pero no guarda las claves privadas necesarias para gastar esos fondos. Además, el monedero debe admitir el gasto de esa salida sin confirmar. Antes de firmar, comprueba qué salida gastas, adónde irá el dinero, cuánto quedará y cuál será la comisión total. Si la salida es pequeña, la comisión puede consumir una parte considerable de su valor. [5]
Replace-by-Fee (RBF) crea una nueva transacción en conflicto para sustituir a la original. Comparte con ella al menos una entrada gastada, pero no necesita tener exactamente el mismo conjunto de entradas. CPFP conserva el pago original y su identificador, y añade otra transacción. Con RBF debes cumplir las condiciones de las entradas de la sustituta; con un CPFP normal, las de una salida del pago original. Por eso el destinatario puede tener la posibilidad de usar CPFP aunque no pueda firmar la sustitución del remitente. Enviar un pago independiente con una comisión alta no ayuda: la hija debe depender realmente del pago pendiente. [3]
Una tarifa conjunta mayor da al minero un motivo más para incluir ambas transacciones, pero no reserva espacio en el siguiente bloque. Pueden llegar otras que paguen más, o algunos mineros pueden no recibir el paquete. Sigue las confirmaciones tanto del pago original como de la hija. Que un nodo indique que ha aceptado una transacción no significa que esté confirmada en un bloque. Si el remitente sustituye el pago original mediante RBF, la hija que apunta a su antigua salida no puede enlazarse por sí sola a la nueva transacción: habrá que revisar la situación. Crear una hija tampoco convierte un ingreso sin confirmar en un pago asegurado. [3]
Las siguientes secciones profundizan en las reglas y en el uso de un nodo propio. Mempool es la lista de transacciones pendientes de un nodo concreto, no una cola única de toda la red. Un paquete es un grupo de transacciones presentado conjuntamente. Conviene distinguir tres decisiones: si la transacción es válida, si el nodo la acepta y si un minero la selecciona. El consenso determina la validez de transacciones y bloques. La política del mempool determina la aceptación y retransmisión locales; las reglas del minero, la selección para un bloque candidato. CPFP no modifica el consenso. Un paquete económicamente atractivo puede incumplir la política local, y su aceptación por un nodo no obliga a otros nodos ni mineros. [3] [5]
Las formas de transmitir juntas a la madre y a la hija evolucionan. Package CPFP significa evaluar transacciones relacionadas como un paquete. Un RPC es un comando para interactuar con el nodo; minrelaytxfee designa su tarifa mínima para la propagación ordinaria. TRUC es un régimen especial de transacciones con relaciones restringidas entre antecesores y descendientes. La historia que sigue se refiere a las versiones indicadas de Bitcoin Core. Bitcoin Core 26 añadió el RPC submitpackage y package CPFP: la hija podía ayudar a una madre por debajo de la tasa mínima dinámica del mempool, pero entonces no por debajo de la tasa mínima de retransmisión. Esa restricción no es permanente. Core 31 permite una madre por debajo de minrelaytxfee, incluso con comisión cero, en la retransmisión compatible de paquetes de una madre y una hija, también para transacciones fuera de TRUC; las demás madres sin confirmar de la hija ya deben estar en el mempool. La aceptación local sigue sin garantizar una propagación idéntica por toda la red. [1] [2]
Un nodo no puede aceptar redes de dependencias de cualquier tamaño. Un antecesor es necesario antes de otra transacción; un descendiente gasta salidas situadas más adelante en esa cadena de dependencias. WU significa unidades de peso de la transacción, y la topología describe cómo se conectan las transacciones. Estos límites técnicos pertenecen a la política de la versión del nodo correspondiente. Los límites protegen memoria, recursos del procesador y ancho de banda. Las versiones antiguas de Core limitaban número y tamaño de antecesoras y descendientes; Core 31 sustituyó esos límites del mempool por límites de clústeres conectados. Persisten límites de paquete independientes: la documentación de Core 31 indica un máximo de 25 transacciones y un peso total de 404000 WU. El peso no es el tamaño virtual. Una topología incorrecta, un conflicto o incumplir las reglas locales sobre las formas de transacción aceptadas (standardness) puede impedir CPFP incluso con suficiente comisión. [2] [3]
Cuando las transacciones pendientes dependen unas de otras, no siempre se pueden evaluar económicamente por separado. Cluster Mempool permite considerar sus grupos conectados. Un cluster es el grupo conectado completo; un chunk es un grupo menor que se procesa durante la selección de transacciones. No son fragmentos de bloques ya confirmados. Bitcoin Core 31 utiliza Cluster Mempool: un clúster reúne transacciones conectadas mediante relaciones madre–hija en cualquier dirección. Los límites predeterminados son 64 transacciones y 101 kB de tamaño virtual por clúster; son configurables. El orden tiene en cuenta grupos que se minan juntos, llamados chunks, y sus tasas. El CPFP carveout histórico permitía una excepción limitada al límite de descendientes; Core 31 lo eliminó y el límite de cantidad de transacciones del clúster no puede eludirse así. [2] [4]
Los comandos de esta sección no son intercambiables. Una prueba puede limitarse a describir un resultado; enviar un paquete puede aceptar y propagar de verdad transacciones firmadas. El campo vsize indica el tamaño virtual. Un monedero habitual puede encargarse de estos detalles por el usuario. En Core 31, getmempoolentry muestra, para una transacción presente en el mempool de ese nodo, comisiones, vsize, dependencias y datos del chunk; getmempoolcluster muestra el clúster relacionado. El RPC testmempoolaccept realiza una prueba local sin aceptar ni difundir; con varias transacciones, las antecesoras deben preceder a las hijas y no puede haber conflictos entre ellas ni con el mempool. El RPC submitpackage presenta realmente un paquete compatible para su aceptación en el mempool y retransmisión; no es solo una prueba. Revisa los resultados de cada transacción, la versión y la configuración; ningún resultado garantiza la inclusión en un bloque. [2] [6] [7] [8] [9]
Para obtener la imagen más completa, lee esta entrada junto con Replace-by-Fee (RBF), Transaction Fees, Fee Rate, Mempool, Transacción, UTXO. También enlazan con esta entrada Change Address, Confirmación, Doble gasto, Fee Rate.