Enviar un pago no equivale a confirmarlo. Hasta que un minero lo incluya en un bloque, los nodos —programas que verifican y retransmiten transacciones de Bitcoin— pueden guardarlo en su Mempool, una lista local de transacciones pendientes. Bajo ciertas condiciones, RBF les permite aceptar en su lugar otra transacción que gaste al menos uno de los mismos UTXO: una salida que aún no se ha gastado. La sustitución necesita firmas válidas y debe enviarse a la red; una comisión mayor por sí sola no garantiza una confirmación rápida.
Anna envió 20.000 sat, pero su pago sigue pendiente. La abreviatura sat significa satoshi, la unidad más pequeña de bitcoin. Su cartera ofrece aumentar la comisión mediante RBF. En un ejemplo sencillo, la transacción original gasta 50.000 sat: entrega 20.000 sat al destinatario, paga 200 sat de comisión y devuelve 29.800 sat a Anna como cambio. La sustitución puede mantener los 20.000 sat del destinatario, elevar la comisión a 2.000 sat y devolver 28.000 sat a Anna. Estas cifras explican el mecanismo; no recomiendan una comisión actual. Antes de firmar, Anna comprueba la dirección, el importe del destinatario y la nueva comisión total. La cartera debe poder firmar las entradas necesarias; quizá haya que conectar de nuevo la cartera de hardware. La sustitución tiene otro txid, el identificador de la transacción, por lo que puede ser necesario enviar al destinatario un nuevo enlace de seguimiento. Aumentar la comisión no es lo mismo que crear un segundo pago independiente con otros UTXO: ambos pagos independientes podrían confirmarse y acabarías pagando dos veces. [1] [2] [12]
Una cartera puede mostrar un ingreso antes de la primera confirmación. Se llama zero-conf: el pago se ha visto, pero aún no está en un bloque. Otra versión puede confirmarse primero y el ingreso mostrado puede desaparecer. Por eso, una etiqueta ‘RBF desactivado’ no demuestra que el pago sea seguro. Entregar productos a cambio de un pago sin confirmar implica asumir un riesgo comercial. Una vez incluida en un bloque, RBF no puede reescribir la transacción. Una posible reorganización de la cadena es un riesgo distinto, por el que se esperan más confirmaciones en pagos importantes. [1]
RBF no exige mantener al destinatario original. Una sustitución puede aumentar la comisión y seguir pagando a la misma persona, o enviar los fondos a otro lugar. Ambas versiones intentan gastar el mismo UTXO: son intentos en conflicto, técnicamente un Double Spend. Ese término no determina por sí solo si hay fraude. Sin embargo, un atacante no puede firmar sin más el pago de otra persona: la sustitución debe cumplir las condiciones de gasto, incluidas las firmas necesarias. Si una cartera ofrece ‘cancelar’ mediante una sustitución que te paga a ti mismo, está intentando adelantarse a la transacción original; no es una revocación garantizada. [1]
RBF cambia la propia transacción pendiente. Child Pays for Parent (CPFP) conserva la original y crea otra que gasta una de sus salidas. Para cobrar la comisión de la nueva, el minero debe incluir también la original y puede valorar la tasa conjunta. La nueva transacción se llama hija y la original, madre. Puede crearla quien pueda gastar esa salida, como el destinatario del pago o el remitente que utiliza su cambio. Las posibilidades dependen de la cartera, las firmas necesarias y las relaciones entre transacciones. CPFP no sustituye el pago original ni garantiza un plazo de confirmación. [2]
El Mempool no es una única cola compartida por todo Bitcoin. Cada nodo mantiene su lista y sus reglas para aceptar y reenviar transacciones pendientes. RBF forma parte de esa política local, no del consenso que determina la validez de los bloques. Un minero puede elegir una transacción en conflicto válida que otro nodo no guardaba. Un Full Node comprueba entonces el bloque completo según las reglas de Bitcoin; su anterior preferencia en el mempool no determina el resultado. Que un nodo acepte una sustitución no promete que todos la acepten. [1] [6]
Al usuario le importan dos cifras distintas: cuánto paga en total y qué tasa ofrece por el tamaño de la transacción. Con un tamaño hipotético de 200 vB, 200 sat equivalen a 1 sat/vB; con ese mismo tamaño, 2.000 sat equivalen a 10 sat/vB. El byte virtual, vB, es una unidad de tamaño derivada del peso de la transacción. Al reconstruirla puede cambiar el tamaño, por lo que la cartera debe recalcular también la tasa. La comisión total es una cantidad de satoshis; la tasa es una cantidad por byte virtual, en sat/vB. En una sustitución individual de Core 30, la comisión debe cubrir la suma de las comisiones de todas las transacciones expulsadas más el coste según incrementalrelayfee y el tamaño de la sustitución. Su tasa debe superar las de las transacciones directamente conflictivas. No basta una tasa mayor ni añadir satoshis; Core 30 usa por defecto incrementalrelayfee de 0,1 sat/vB, pero la configuración puede diferir. [2] [9]
Puede haber otro pago pendiente que dependa del primero: alguien gasta una salida de la primera transacción, todavía sin confirmar. Estas transacciones posteriores se llaman descendientes. Si se elimina su transacción madre, tampoco ellas pueden permanecer utilizables en el mempool, así que el nodo debe considerar todo el grupo afectado. Sustituir una transacción madre también puede expulsar del mempool a descendientes que gastan sus salidas. No siempre se comparan solo dos transacciones. Para una sustitución individual, Core 30 limita a 100 la suma de los recuentos de descendientes de las transacciones directamente conflictivas, incluidas ellas mismas; los descendientes compartidos pueden contarse varias veces. Las comisiones y relaciones del paquete influyen en el éxito. [2]
El nodo también debe impedir que alguien lo sature recalculando sustituciones sin parar. Es una protección contra DoS, un ataque a la disponibilidad del servicio. Un UTXO es una salida sin gastar de una transacción anterior; una entrada de la nueva transacción hace referencia a ella. Las reglas siguientes describen Bitcoin Core 30, no una ley inmutable de Bitcoin. La política de Bitcoin Core 30 para una sustitución individual también restringe nuevas entradas sin confirmar y la cantidad de transacciones expulsadas. Debe cumplir las reglas locales sobre las formas de transacción aceptadas (standardness), las de retransmisión y las de validez; gastar el mismo UTXO no basta. Los límites protegen la capacidad de procesamiento, la memoria y el ancho de banda; las sustituciones de paquetes deben evaluarse por separado según la versión del nodo. Core 31 cambió esta política con Cluster Mempool, que evalúa en grupos las transacciones pendientes conectadas entre sí. Una sustitución debe mejorar el llamado feerate diagram, que compara las comisiones acumuladas con el espacio ocupado progresivamente. Siguen existiendo otras condiciones, como una comisión total suficiente y el importe adicional por retransmitir la sustitución. No apliques automáticamente los límites de Core 30 descritos arriba a versiones posteriores: comprueba las reglas de tu nodo. [2] [13]
¿Por qué algunas carteras siguen mostrando un interruptor RBF? Los nodos que aplicaban la política original opt-in RBF exigían una señal previa que permitiera la sustitución. Bitcoin Core 24 permitió configurar full-RBF sin esa condición, Core 28 lo activó por defecto y Core 29 eliminó el interruptor mempoolfullrbf. Los detalles de BIP125 que siguen explican la señalización original, no una regla universal de todos los nodos actuales. BIP125 describe una señal opt-in explícita cuando al menos una entrada tiene nSequence inferior a 0xfffffffe, y también la señal heredada de un antecesor sin confirmar. Es una política histórica, no una condición de consenso. Full-RBF permite evaluar una sustitución sin esa señal; su ausencia no garantiza que un pago no pueda sustituirse. [1] [3] [4] [5] [6]
Esta sección está dirigida a quien opera su propio nodo. Las RPC son órdenes para consultar o controlar el software; no hace falta conocerlas para utilizar el botón de aumentar la comisión. getmempoolentry muestra el estado de una transacción si está en el mempool de ese nodo; testmempoolaccept prueba una única sustitución candidata firmada contra el mempool y las reglas actuales del nodo, sin transmitirla. No promete aceptación por otros nodos ni inclusión en un bloque. Core 28 activó full-RBF mediante el valor predeterminado de mempoolfullrbf; Core 29 eliminó esa opción. getmempoolinfo informa de parámetros de comisión, pero su campo fullrbf está obsoleto en Core 30; comprueba siempre versión y configuración real. [5] [6] [7] [8] [10] [11]
Para obtener la imagen más completa, lee esta entrada junto con Transaction Fees, Mempool, CPFP (Child Pays for Parent), Doble gasto, Confirmación, Fee Rate. También enlazan con esta entrada Change Address, Confirmación, Doble gasto, Fee Rate.