RBF en Bitcoin: cómo acelerar una transacción atascada

RBF en Bitcoin, o Replace-by-Fee, permite sustituir una transacción no confirmada por otra que entra en conflicto con ella y paga una comisión mayor. Para un remitente que todavía controla las monedas necesarias para construir una sustitución válida, RBF suele ser la forma más limpia de aumentar el incentivo para los mineros sin esperar a que la transacción original desaparezca de las mempools. En Bitcoin Core 31.0, la validación de sustituciones funciona con la nueva cluster mempool y una regla de diagrama de feerates destinada a mejorar económicamente el estado de la mempool tras la sustitución.

RBF es una política de mempool y propagación, no una garantía del consenso de Bitcoin. Una cartera puede no mostrar un botón para aumentar la comisión, distintos nodos pueden ver mempools diferentes y un minero puede confirmar una versión válida antes de que la sustitución se propague ampliamente. Un diagnóstico más seguro identifica quién controla los inputs o una salida no confirmada y qué método de aumento de comisión está disponible ahora.

Puntos clave

• La política actual de Bitcoin Core no exige la antigua señal opt-in de BIP125 para que una transacción sea sustituible por política, aunque las interfaces de las carteras todavía pueden mostrar «RBF activado» o «reemplazable».
• RBF suele ser una herramienta del remitente porque la sustitución gasta al menos uno de los mismos inputs que la transacción original no confirmada.
• CPFP, o Child Pays for Parent, puede servir cuando el destinatario o el remitente controla una salida no confirmada que puede gastar en una transacción hija con una comisión alta.
• Aumentar una comisión exige cumplir la política del nodo, no solo seleccionar una tasa que parezca superior en un explorador.
• Cuando la original o la sustitución se confirma, el aumento de comisión termina; RBF no reescribe una transacción confirmada.

Qué cambió respecto a la explicación antigua de RBF

Muchas guías de Bitcoin todavía empiezan por la regla histórica de BIP125: un input utilizaba un número de secuencia inferior a 0xfffffffe, señalando que el remitente aceptaba la sustitución. Esa descripción sigue siendo útil para entender la historia, y BIP125 continúa siendo una especificación importante, pero ya no describe por sí sola la situación operativa de la política actual de Bitcoin Core.

La documentación vigente de reemplazos en la mempool de Bitcoin Core registra que full RBF pasó a ser la política predeterminada en la versión 28.0 y que la señal ya no es obligatoria. En la versión 31.0, el rediseño de la cluster mempool añadió otra prueba: la sustitución debe mejorar estrictamente el diagrama de feerates de la mempool. Para una transacción simple que forma por sí sola un cluster, las notas de la versión indican que basta con que la sustitución tenga una comisión absoluta y una tasa por vbyte mayores que la original. Los clusters más complejos pueden tener restricciones adicionales.

Una etiqueta «RBF: no» de un explorador puede reflejar la señal histórica sin demostrar que todos los nodos de propagación actuales rechazarán una sustitución. Tampoco demuestra que tu cartera pueda construirla. Influyen la capacidad de la cartera, el control de los inputs, las salidas de cambio, el flujo de firma con hardware y las reglas de política.

Si el problema original es simplemente una comisión demasiado baja, conviene revisar primero cómo la mempool de Bitcoin y el mercado de comisiones reflejan la demanda de espacio de bloque. El fee bump resuelve una transacción concreta; no elimina la congestión.

RBF sustituye la transacción, no añade otro pago

Una transacción de Bitcoin gasta UTXOs específicos. Una sustitución RBF entra en conflicto con una transacción no confirmada al gastar uno o más de los mismos inputs. Como ambas versiones no pueden terminar confirmadas tal como están escritas, los nodos que aceptan la sustitución eliminan de su mempool la transacción original pertinente —y, cuando corresponde, sus descendientes— y conservan la nueva si cumple las reglas.

Por eso RBF no es lo mismo que «enviar el pago otra vez». Si creas una segunda transacción independiente hacia el mismo destinatario, ambas pueden confirmarse y el destinatario puede recibir dos veces el importe previsto. Una sustitución RBF correcta reutiliza inputs en conflicto y normalmente mantiene el pago previsto mientras cambia la comisión, a menudo reduciendo el cambio o ajustando inputs y outputs mediante la lógica de fee bump de la cartera.

La política actual de Bitcoin Core impone varias restricciones económicas. La sustitución debe pagar al menos la suma de la comisión absoluta de las transacciones sustituidas. También debe añadir suficiente comisión para cubrir el coste de ancho de banda de propagar la sustitución a la tasa incremental del nodo. La documentación vigente indica un valor predeterminado de 0,1 sat/vB para incrementalrelayfee, aunque el operador del nodo puede configurarlo. La versión 31.0 también exige mejorar el diagrama de feerates y limita el número de clusters distintos afectados.

«Un satoshi más» no es una estrategia fiable. La cartera debe construir una sustitución con suficiente comisión absoluta y suficiente feerate para pasar la política y competir por espacio en bloque.

¿RBF o CPFP? Usa este árbol de decisión

El método correcto depende del control, no de quién tenga más prisa.

La matriz pone el control en primer lugar. Un explorador puede mostrar lo que observa, pero no puede darte autoridad para firmar.

Ejemplo calculado de aumento de comisión con RBF

Supongamos que una transacción no confirmada tiene 140 vB y pagó 10 sat/vB. Su comisión es:

140 vB × 10 sat/vB = 1.400 sats

Ahora la cartera construye una sustitución de 150 vB y eliges 25 sat/vB. La nueva comisión es:

150 vB × 25 sat/vB = 3.750 sats

La sustitución paga 3.750 sats en total, más que los 1.400 sats de la transacción original. El aumento de 2.350 sats también supera los 15 sats exigidos para propagar una sustitución de 150 vB con el valor predeterminado de 0,1 sat/vB de incrementalrelayfee. La cartera todavía debe cumplir la regla del diagrama de feerates y las demás reglas aplicables; el feerate objetivo depende del estado actual de la mempool.

Utiliza una estimación actual de comisiones y una vista previa de la transacción de sustitución en vez de una regla fija como «añadir 5 sat/vB». Bitcoin Core 31.0 también modificó su estimador para que el bucket mínimo de feerate pueda bajar de 1 sat/vB cuando el nodo dispone de suficientes datos, en línea con su política predeterminada más baja de propagación mínima. Eso no significa que una tasa baja vaya a confirmar rápido; significa que el estimador puede representar mejor periodos tranquilos.

Cómo acelerar una transacción con RBF de forma segura

Empieza confirmando que la transacción sigue sin confirmar. Consulta tu propio nodo si lo ejecutas o compara más de un explorador reputado si el estado es ambiguo. Guarda el TXID, los outputs, la comisión y el tamaño virtual aproximado. No asumas que la etiqueta «pendiente» de una cartera representa exactamente lo que ven los mineros.

Después utiliza la función nativa de aumento de comisión de la cartera, si existe. Una cartera bien diseñada construirá una transacción en conflicto y no un pago duplicado, conservará el output previsto del destinatario salvo que lo cambies deliberadamente y mostrará la nueva comisión antes de firmar. Si utilizas un firmante hardware, revisa en el dispositivo de confianza la dirección y el importe cuando el flujo lo permita.

Elige el feerate según las condiciones actuales y el horizonte de confirmación que necesitas. Una sustitución que apenas supera la política de propagación puede seguir detrás de muchas transacciones con mayor tasa. En el otro extremo, una comisión elegida por pánico puede sobrepagar mucho si la congestión ya se ha reducido.

Tras firmar, transmite la sustitución y comprueba qué transacción aceptan varios peers o exploradores. Es normal que algunas interfaces continúen mostrando el TXID original como transacción en conflicto o reemplazada. No envíes un tercer pago independiente solo porque un explorador tarde en actualizarse.

Finalmente, espera la confirmación y evalúa la finalidad de la forma habitual. RBF solo cambia la fase no confirmada. Nuestra guía sobre finalidad de transacciones de Bitcoin y riesgo de reorganización explica por qué una transacción gana seguridad operativa a medida que acumula bloques.

Cuándo CPFP tiene más sentido

Child Pays for Parent utiliza otra vía económica. En vez de sustituir el padre con comisión baja, quien controla uno de sus outputs no confirmados lo gasta en una transacción hija con una comisión suficientemente alta. Un minero que evalúa el paquete puede obtener suficiente comisión del padre y de la hija en conjunto como para incluir ambos.

Tomemos el mismo padre de 140 vB con 1.400 sats de comisión. Supongamos que la hija tendrá 110 vB y quieres que el paquete combinado de 250 vB promedie 25 sat/vB. El paquete necesita:

250 vB × 25 sat/vB = 6.250 sats

Como el padre ya aporta 1.400 sats, la hija necesitaría aproximadamente 4.850 sats. Sobre 110 vB, eso equivale a unos 44,1 sat/vB para la hija. Esa tasa elevada compensa el bajo feerate del padre cuando el conjunto se evalúa como paquete.

El cálculo es un ejemplo de planificación, no una garantía universal de propagación. Las reglas de paquetes y clusters han cambiado con el tiempo, el soporte de las carteras varía y la hija puede tener otros ancestros no confirmados. Bitcoin Core 31.0 eliminó el antiguo CPFP carveout, a la vez que amplió en otros aspectos el comportamiento de paquetes de un padre y un hijo. Si la cartera ofrece un flujo probado de «accelerate» o CPFP, usa su vista previa en vez de adivinar manualmente la política.

Por qué puede fallar un intento de RBF

Un fee bump puede fallar aunque la transacción no esté confirmada. Una causa operativa común es que la cartera no controle o no pueda acceder a los inputs originales de una forma compatible con su flujo de sustitución. Un software watch-only, un firmante hardware no disponible, un multisig cuyo umbral no puede alcanzarse en ese momento o una retirada de exchange pueden impedir construir o firmar la nueva transacción.

La política también puede rechazar la sustitución. La nueva transacción puede no añadir suficiente comisión absoluta, no pagar bastante coste de propagación incremental, no superar la prueba del diagrama de feerates o interactuar con un cluster de una forma que el nodo no acepte. Por eso un error de cartera como «insufficient fee» no significa necesariamente que «la comisión de la red es alta». Puede significar que la sustitución concreta incumple una restricción de mempool.

Otro problema es competir contra una confirmación. Si la original entra en un bloque mientras preparas o propagas la sustitución, esta última deja de ser válida porque sus inputs ya fueron gastados. Es un resultado normal. Cuando cualquiera de las dos versiones se confirma, la versión confirmada gana bajo el consenso.

También puede haber visibilidad inconsistente. Bitcoin no tiene una mempool global única. Los nodos pueden recibir transacciones en momentos distintos, aplicar políticas diferentes, expulsarlas por presión de memoria o reconectarse después de perder una emisión. Un único explorador es un punto de observación, no un libro oficial de pendientes de toda la red.

Full RBF cambia la forma de pensar en pagos de cero confirmaciones

El viejo modelo mental de «si no señala RBF es seguro antes de confirmar» resulta especialmente peligroso. La documentación actual de Bitcoin Core indica que la señal ya no es necesaria para la política de sustitución. Más ampliamente, una transacción no confirmada todavía no forma parte de la cadena protegida por prueba de trabajo y no debería tratarse como liquidación confirmada solo porque una cartera la marque como no reemplazable.

Para pagos minoristas de bajo valor, cada negocio puede establecer sus propios controles de riesgo, pero la distinción técnica sigue existiendo. Nuestra guía sobre confirmaciones de Bitcoin cubre el paso desde la observación en mempool hasta la seguridad que aporta la profundidad de bloques.

No todas las transacciones no confirmadas serán reemplazadas de forma maliciosa, pero un receptor no debería utilizar una antigua señal opt-in como sustituto de una política de liquidación.

Casos límite que conviene revisar antes de actuar

Retiradas de exchanges

Si el exchange creó la transacción, normalmente no controlas los inputs. Aunque tu cartera receptora detecte que una comisión mayor ayudaría, no puede firmar una sustitución en nombre del exchange. CPFP solo será posible si el output recibido puede gastarse sin confirmar y tu cartera soporta ese flujo. En caso contrario, corresponde contactar con el exchange y esperar.

Multisig y transacciones colaborativas

Una sustitución puede requerir nuevas firmas bajo la misma política de firma. En una tesorería 2-de-3, por ejemplo, un coordinador no puede cambiar unilateralmente la transacción sin reunir los cofirmantes necesarios. Los protocolos colaborativos complejos también pueden sufrir transaction pinning, donde otro participante explota límites de política para encarecer o dificultar el aumento de comisiones. La referencia de Bitcoin Optech sobre transaction pinning explica el problema más allá de pagos ordinarios de un solo usuario.

Hardware wallets y flujos PSBT

Un firmante offline puede firmar una sustitución si la cartera coordinadora construye una transacción válida y la política lo permite. Debes tratar la sustitución como una transacción nueva a efectos de verificación: revisar otra vez destino, importe, cambio y comisión. Nunca firmes solo porque el ordenador afirme que es «el mismo pago».

Una transacción que parece haber desaparecido

Si una transacción desaparece de una mempool, no vuelvas a pagar inmediatamente usando otros inputs. Comprueba si otro nodo todavía la conserva y si el destinatario ya la ha visto. Si la antigua transacción vuelve a propagarse o termina confirmando, un reenvío independiente puede producir dos pagos. Una sustitución deliberadamente conflictiva es más segura cuando controlas la operación y pretendes reemplazarla.

Errores habituales con RBF

El primero es confundir una comisión total mayor con un feerate mayor. Una sustitución mucho más grande puede pagar más sats en total y aun así ser poco atractiva por vbyte o incumplir la política. El segundo es tratar la etiqueta RBF de un explorador como si otorgara autoridad para firmar. No lo hace. El tercero es intentar «cancelar» una transacción enviando la misma cantidad a uno mismo sin entender que una cancelación válida debe entrar en conflicto con la original y cumplir la política.

Otro error es sobrepagar copiando una tasa de una captura antigua, una publicación social o un episodio anterior de congestión. Las condiciones cambian bloque a bloque. Y hay un error aún más grave: entregar la frase semilla o la clave privada a una web que promete «acelerar» la transacción. RBF legítimo no requiere revelar esas credenciales a un desconocido. Si un servicio las pide, detente.

BTC-Pulse Take

RBF se entiende mejor como un problema de control y política, no como un acelerador mágico. Si eres el remitente, controlas los inputs y tu cartera ofrece un flujo correcto de sustitución, RBF puede aumentar de manera eficiente la comisión de una transacción no confirmada. Si solo controlas una salida todavía no confirmada, CPFP puede ser la vía práctica. Si no controlas ninguna de las dos, ningún explorador ni supuesto «accelerator» puede concederte la autoridad de firma que falta.

En 2026, la decisión no debe basarse únicamente en la antigua señal opt-in. La política de sustitución actual de Bitcoin Core ya no exige esa señal y la versión 31.0 evalúa las sustituciones dentro del marco de cluster mempool. Utiliza herramientas de cartera actuales, condiciones de comisión actuales y control explícito de la transacción para elegir el método.

Preguntas frecuentes

¿Puedo usar RBF después de que una transacción de Bitcoin se confirme?

No. RBF se aplica a transacciones no confirmadas en la mempool. Cuando una transacción ya está confirmada, otra que gaste los mismos inputs entra en conflicto con el estado confirmado y no es válida, salvo que una reorganización posterior elimine aquella confirmación.

¿Puede el destinatario usar RBF?

Normalmente RBF lo usa el remitente porque la sustitución gasta los inputs originales. El destinatario suele no controlar esos inputs. Sin embargo, puede ser capaz de usar CPFP gastando un output no confirmado que sí controla mediante una hija con comisión alta.

¿Una transacción debe mostrar «RBF activado» en 2026?

No para la política de sustitución actual de Bitcoin Core. La documentación vigente indica que la señal ya no es obligatoria. Algunas carteras todavía muestran información de señalización histórica o la utilizan para decidir si habilitan su propio botón de aumento de comisión.

¿RBF puede cambiar la dirección del destinatario?

Técnicamente una sustitución conflictiva puede tener outputs distintos si sigue siendo válida y pasa la política. Los flujos normales de fee bump de las carteras están diseñados para conservar el pago previsto y ajustar la comisión, a menudo reduciendo el cambio. Revisa siempre la sustitución antes de firmarla.

¿Pagar una comisión mayor garantiza el siguiente bloque?

No. Una comisión mayor puede mejorar el incentivo relativo para incluir la transacción, pero la demanda de espacio, la selección de los mineros, las relaciones de paquetes y las nuevas transacciones influyen en la confirmación. Ningún feerate garantiza un bloque concreto.

Fuentes

• Bitcoin Core 31.0: notas de versión
• Política actual de reemplazos de mempool de Bitcoin Core
• BIP125: Opt-in Full Replace-by-Fee Signaling
• Documentación RPC de Bitcoin Core 31.0
• Bitcoin Optech: Replace-by-fee
• Bitcoin Optech: Transaction pinning

Este artículo es educativo. Un error al aumentar comisiones puede causar sobrepago, retrasos o pagos duplicados accidentales. Nunca reveles una frase semilla ni una clave privada a una web o cuenta de soporte que prometa acelerar una transacción.