RBF (Replace-by-Fee)

¿Qué hace un nodo cuando llega una segunda transacción que gasta lo mismo?

Imagina que envías un pago con una tasa de comisión baja y la red se congestiona. Pasan las horas y la transacción sigue en la mempool sin que ningún minero la quiera. Tu billetera (wallet) puede firmar otra transacción que gasta al menos una de las mismas entradas y paga más. Los nodos que la aceptan descartan la original y las transacciones que colgaban de ella, y difunden la nueva. Solo una de las dos podrá confirmarse.

Eso es Replace-by-Fee (RBF). La definición de Bitcoin Core es mecánica: hay conflicto cuando dos transacciones gastan una o más entradas iguales. El reemplazo sustituye a las transacciones en conflicto directo y a sus descendientes en la mempool, siempre que cumpla las reglas. Nada en el consenso impide tener dos versiones circulando. Es una política de retransmisión de cada nodo, y por eso conviene decir «los nodos que la aceptan»: otras versiones o configuraciones pueden pensar distinto.

Las reglas que aplica Bitcoin Core 31.1

La documentación de la 31.1 (8 de julio de 2026) numera seis reglas, de las que la 1 y la 2 aparecen como eliminadas. Quedan cuatro:

• Regla 3. La comisión absoluta del reemplazo es, como mínimo, la suma de lo que pagaban las transacciones sustituidas.
• Regla 4. La comisión adicional paga el ancho de banda del reemplazo a la tasa de -incrementalrelayfee.
• Regla 5. Las transacciones con las que el reemplazo entra en conflicto directo no pueden estar repartidas en más de 100 clústeres distintos (un clúster es un grupo de transacciones sin confirmar unidas por relaciones de padre e hija).
• Regla 6. El diagrama de tasas de la mempool tiene que mejorar de forma estricta.

Un ejemplo sencillo. La transacción original pesa 200 vB y paga 400 sat, es decir, 2 sat/vB. El reemplazo pesa lo mismo y paga 2.000 sat (10 sat/vB). Regla 3: 2.000 es mayor que 400, se cumple. Regla 4: con el incremento de 0,1 sat/vB, el extra mínimo es 0,1 × 200 = 20 sat, y el reemplazo añade 1.600 sat, se cumple. Como la original y el reemplazo van solos, la regla 6 equivale a pagar más comisión y más tasa, y también se cumple.

Esos 20 sat son lo que exige un nodo con la 29.1 o posterior. Un nodo con la 29.0 o anterior pide 1 sat/vB, es decir, 200 sat en este ejemplo, así que un reemplazo que solo cumple el mínimo nuevo puede no llegar a todos los mineros.

Ahora cambia el caso: la original ya tenía una hija en la mempool que pagaba 600 sat. El mismo reemplazo de 200 vB, que no gasta otras transacciones sin confirmar, tiene que pagar al menos 400 + 600 = 1.000 sat por la regla 3 y 1.020 sat con la regla 4. Son 5,1 sat/vB, cuando quien solo mirara la tasa de la original pensaría que bastan 2,1. La regla 6 también se comprueba, y aquí se cumple.

La regla 3 existe por una razón concreta. Según el documento de Core, exigir solo una tasa mayor permitiría saltarse el mínimo de retransmisión de los nodos y hacer que la red retransmitiera una y otra vez reemplazos algo más pequeños sin añadir comisión alguna. Por eso la comisión absoluta cuenta.

Cuando la original y el reemplazo van solos, sin padres ni hijas sin confirmar, las notas de la 31.0 resumen el caso así: basta con que el reemplazo pague más comisión y más tasa. Las reglas 3 y 4 siguen vigentes, de modo que ese «más» tiene el suelo del incremento. Si el reemplazo gasta de un padre sin confirmar, eso ya no basta. La regla 6 y el diagrama de tasas, con sus casos límite, se explican a fondo en cluster mempool. Aquí basta una frase: se acepta el reemplazo si, para cualquier espacio que haya que llenar con lo mejor de la mempool, el minero cobra lo mismo o más que antes, y más en algún caso (salvo el efecto del final del bloque, cuando lo siguiente ya no cabe entero).

Lo que cambió con las versiones recientes:

• Hasta la 30.x, además de las reglas 3 y 4, el reemplazo debía pagar más tasa que cada transacción con la que entraba en conflicto directo, no podía añadir entradas sin confirmar nuevas (la antigua regla 2) y la regla 5 contaba 100 transacciones desalojadas, no 100 clústeres. En la 31.0 la comparación de tasas y la regla 2 desaparecen, y el diagrama ocupa su lugar.
• El incremento por defecto, DEFAULT_INCREMENTAL_RELAY_FEE, era 1.000 sat/kvB (1 sat/vB) en la 29.0 y es 100 sat/kvB (0,1 sat/vB) en la 31.1. El cambio llegó con la 29.1 (PR #33106). Las notas de la 29.1 advierten de que, mientras estos valores más bajos no estén extendidos por la red, las transacciones con tasas menores no tienen garantizada su propagación ni su confirmación.

Historia: de la señal opcional al full-RBF

RBF no nació con un BIP. El historial de Core sitúa una primera implementación, con señal opcional y sin señal heredada, en la versión 0.12.0 (PR #6871). El BIP 125 (David A. Harding y Peter Todd, 4 de diciembre de 2015, estado Deployed) se escribió a partir de esa implementación. Define la señal: una transacción avisa de que acepta ser reemplazada si alguna de sus entradas tiene un nSequence menor que 0xffffffff - 1, es decir, 0xfffffffd o menos. El BIP describe además una señal heredada de los ancestros sin confirmar. Core nunca la aplicó para aceptar reemplazos (CVE-2021-31876).

El resto de la cronología:

• Versión 0.16.0: la billetera gráfica de Core empieza a marcar sus transacciones como reemplazables por defecto (PR #11605). El apartado History de la documentación de Core dice 0.18.1, pero las notas de la 0.16.0 lo sitúan ahí.
• Versión 24.0.1 (la 24.0 se etiquetó y sus binarios llegaron a subirse, pero no se anunció como versión oficial): el full-RBF se puede activar con una opción (PR #25353), desactivada por defecto.
• Versión 28.0 (2 de octubre de 2024): el full-RBF pasa a ser el comportamiento por defecto (PR #30493).
• Versión 29.0: se elimina la opción (PR #30592). Las notas lo explican así: con la adopción generalizada de esta política, los usuarios ya no ganan nada desactivándola, y por eso la opción desaparece y el full-RBF queda como comportamiento estándar.

La documentación lo resume: la señal ya no se exige desde ese PR. Hoy un nodo Core acepta el reemplazo de cualquier transacción sin confirmar, la haya marcado o no. La señal sigue existiendo en las transacciones y muchas billeteras la ponen, pero Core ya no la mira para decidir si acepta un reemplazo. Un detalle de herencia: la RPC getmempoolinfo conserva el campo fullrbf, marcado como obsoleto y fijo en true, aunque la opción -mempoolfullrbf ya no existe.

Tres usos, y uno que da problemas

El uso normal es subir la comisión (bump): la transacción sigue pagando a los mismos destinatarios, pero con más tasa. El segundo es «cancelar»: el reemplazo devuelve los fondos a una dirección propia. Funciona solo si el reemplazo se confirma antes que la original. Si mineros o nodos conservan la original y no aceptan el reemplazo, puede confirmarse la original. Y una transacción ya confirmada no se puede cancelar con RBF, porque ya no está en la mempool.

El tercer uso es cambiar las salidas: juntar pagos, o redirigirlos. La mecánica es idéntica a la de quien intenta engañar a un comercio, y de ahí viene el problema siguiente.

El riesgo de aceptar pagos sin confirmar

Un cliente paga en una tienda y el comercio ve su transacción en la mempool. Con full-RBF, el cliente puede firmar otra que gasta las mismas entradas hacia una dirección suya, con más comisión, y los nodos Core la aceptan. Si el minero confirma la segunda, la tienda se queda sin pago y con el producto entregado.

Esto no es un fallo nuevo. Una transacción sin confirmar nunca fue definitiva: un minero siempre pudo incluir otra en conflicto. Lo que cambia es que ya no hace falta convencer a nadie. Antes, un comercio podía al menos rechazar las transacciones que señalaban reemplazo, y ese filtro hoy no protege. Que una transacción no lleve la señal no la hace segura.

La conclusión práctica es esperar confirmaciones proporcionales al importe, tal como describen finalidad probabilística y doble gasto. Para pagos instantáneos, el camino es Lightning.

RBF frente a CPFP

Las dos técnicas desatascan una transacción, pero no las usa la misma persona. RBF ocupa menos espacio, porque la transacción sigue siendo una en vez de dos, pero solo puede hacerlo quien controla las entradas. CPFP lo puede hacer quien tenga una salida, incluido el receptor.

Paquetes y pinning

Desde la 28.0, Core también acepta que un padre y su hija lleguen juntos y reemplacen lo que choca con el padre, contando la comisión de la hija (PR #28984). Antes, la hija no contaba para las reglas del reemplazo. Las condiciones, que recoge packages.md en la 31.1, son estrechas: un solo padre y una sola hija, sin ancestros en la mempool; como mucho 100 clústeres en conflicto; el paquete paga más comisión total que lo sustituido, con el extra de la regla 4; la tasa del padre queda por debajo de la del paquete; y el diagrama de tasas mejora (comprobación del PR #29242).

El pinning consiste en impedir o encarecer que otro reemplace o acelere una transacción. El BIP 431 (borrador, 10 de enero de 2024) describe varias formas. La principal usa la regla 3: el atacante cuelga descendientes de tasa baja de la transacción que quieres reemplazar, y tu reemplazo tiene que pagar también lo que suman ellos. El BIP recoge además una variante en la que el descendiente paga mucha comisión, lo que sube la cuenta de la regla 3, pero gasta también de otra transacción grande y de tasa baja, así que tampoco sirve para acelerarla. Otra forma usaba la regla 5. Cuando tu reemplazo choca con varias transacciones a la vez, el atacante les cuelga descendientes hasta que entre todas pasan de 100. En la 31 ya no funciona, porque la regla cuenta los clústeres de los conflictos directos y los descendientes caen en el clúster de su padre. Los nodos con la 30.x o anteriores siguen contando transacciones, y ahí el ataque sigue valiendo (el BIP 431 es anterior a ese cambio). La tercera, llenar el límite de descendientes (de clúster, en la 31) de una transacción con salidas de varias partes, no bloquea el RBF sino el CPFP.

El ataque necesita que el atacante pueda colgar transacciones de la que tú tienes que reemplazar o acelerar, ya sea porque es suya y choca con la tuya (dos versiones de una transacción compartida) o porque tiene una salida en ella. Pasa en los contratos entre dos partes; en un pago normal de una sola persona es raro. Importa en Lightning y en otros contratos. La mitigación de TRUC (clúster de dos e hija de hasta 1.000 vB) y su uso en Lightning se detallan en cluster mempool.

Qué billeteras lo permiten

Depende de cada una, y conviene comprobar si ofrece subir la comisión, cancelar o CPFP. Algunos casos:

• Bitcoin Core. DEFAULT_WALLET_RBF vale true: marca sus transacciones como reemplazables. Con bumpfee y psbtbumpfee sube la comisión. Desde la 28.0, si se pasa fee_rate, ya no está obligado al incremento recomendado de 5 sat/vB (WALLET_INCREMENTAL_RELAY_FEE, 5.000 sat/kvB), aunque debe cubrir la comisión original más el incremento de la mempool (PR #27969). Desde la 30.0, ambas RPC y la interfaz gráfica permiten subir la comisión bajo full-RBF y ya no exigen la señal del BIP 125.
• Sparrow. Con clic derecho sobre la transacción pendiente ofrece «Increase Fee (RBF)» y «Cancel Transaction (RBF)» si todas las entradas son de la billetera y, por defecto, si la transacción lleva la señal de RBF; e «Increase Effective Fee (CPFP)» si alguna salida es tuya (código de Sparrow 2.5.5). Más sobre esta billetera en Sparrow Wallet.
• Billeteras de hardware. El reemplazo es una transacción nueva y se vuelve a firmar en el dispositivo, normalmente mediante PSBT.

Qué significa esto para ti

Si envías, pagar la tasa justa y subirla después si hace falta es un método sensato si tu billetera permite subir la comisión de esa transacción. Compruébalo antes de enviar, porque algunas solo lo ofrecen si la original lleva la señal. Ten en cuenta que el reemplazo tiene otro txid: si el receptor sigue el pago por el antiguo, avísale. Para elegir la tasa, mira la entrada de mercado de comisiones. Si recibes, trata cualquier pago sin confirmar como una promesa, no como dinero. Y si desarrollas, recuerda que el aumento mínimo depende del incremento de los nodos y mineros que tienen que aceptar el reemplazo (0,1 sat/vB por defecto desde la 29.1, 1 sat/vB antes); mientras convivan los dos, dejar margen es más seguro. Lo que cuenta es la comisión absoluta y el diagrama, no solo la tasa.

Todo lo anterior describe Bitcoin Core 31.1, la última versión publicada a 6 de octubre de 2026.