Replace By Fee

Replace By Fee (RBF)

Cuando escuches o leas el termino Replace By Fee ( o por sus siglas en inglés: RBF) en el ámbito de Bitcoin, debes saber que se refiere a una característica que se implementó en Bitcoin Core a partir de la versión 0.12.0 y fue propuesta y ampliamente debatida en el BIP125 (Bitcoin Improvement Proposal).

 

De forma simple y rápida, RBF implica que una transacción de Bitcoin pueda ser reemplazada por otra similar pero con una comisión de minería (fee) superior a la primera para poder pagar más de lo que inicialmente se había establecido.

 

Vamos a tratar de profundizar un poco más a través de un ejemplo, así vamos utilizar a los ya tradicionales Alice’s y Bob (Alice y Bob estarán cansados de ser ejemplo!).

 

Alice quiere enviar a Bob 1 bitcoin, para hacerlo realiza un transacción (tx1), la cual es firmada por las claves de Alice para ser enviada a la dirección de Bob (address1), y parte de la clave para entender el funcionamiento de RBF es saber que el valor que envías se corresponde a determinados UTXO’s, para ello Alice tiene en su cartera más de 1 Bitcoin, pero para enviar ese valor (1 bitcoin) a tenido que seleccionar más de un UTXO, y a tomado un UTXO con valor de 0.40 bitcoins, otro con valor de 0.50 bitcoins y un tercero por valor de 0.10 bitcoins, en total la suma es de 1 bitcoin. Para pagar la comisión de minado de esa transacción decide hacerlo por un valor de 1 sat/byte (fee1) y digamos que fee1 es un valor muy bajo para lo que se está pagando en la red por otras transacciones.

 

Pasadas 3 horas la transacción aún no ha sido minada y como Alice tiene una cierta prisa en que le llegue el bitcoin a Bob, decide “acelerar” la transacción, para lo cual envía una nueva transacción tx2 a la dirección address1 (de Bob) y aquí viene lo importante, tiene que incluir en la transacción, los mismo UTXO’s que uso en la tx1, lo cual es indispensable. Y ahora pagando una fee más alta, ahora decide pagar 10 sat/byte (fee10), el cual es un valor alto para lo que se esta pagando por otras transacciones, lo cual incrementará las posibilidades de que esa tx2 sea incluida en un bloque por parte de los mineros y pueda ser “minada” en un tiempo menor.

 

Así que recordemos, este tipo de transacciones no se consideran doble gasto por parte de la red y se siguen retransmitiendo, siempre y cuando paguen una tarifa más alta que la transacción precedente y hagan uso de los mismo UTXO’s.

 

Las condiciones que debe cumplir una transacción para poder considerarse calificada para hacer uso de la característica RBF son:

  • La transacción debe estar en la mempool y no haber sido minada (por eso aún esta en la mempool)

  • La transacción debe tener habilitada la función de RBF (una buena parte de las carteras modernas lo soportan) al firmar la transacción.

  • La transacción que reemplaza a la anterior debe ser firmada con las mismas firmas de la anterior,

  • Además como ya indique, deben tomar exactamente los mismos UTXO’s que en la primera transacción.

 

Precauciones.

Supongamos, retomando el ejemplo de Alice y Bob, que Alice ha comprado un artículo a Bob, y ha pagado usando bitcoin y con la opción de RBF habilitada y paga un fee muy baja (1 sat/byte).

 

A continuación le indica a Bob que la transacción ya ha sido enviada e incluso le comparte el TXID de la misma y le dice que ya solo es cuestión de un poco de tiempo. Bob que confía, le da el artículo a Alice y se queda esperando que la transacción sea minada. Pero Alice tan pronto tiene su artículo ha decidido utilizar la opción de RBF, firmando una nueva transacción con los mismos UTXO’s para enviar de regreso a su cuenta. Esta situación estaría conduciendo a un doble gasto.

 

Esta situación es posible, por lo que es importante entender el concepto y saber que en una transacción, hasta que no haya sido tomada por un minero e incluida en un bloque, esa transacción es susceptible de ser reemplazada.

 

De ahí que siempre se recomiende esperar a que haya confirmaciones sobre la transacción antes de realizar intercambios de valor.

 

La siguiente pregunta que suele surgir del punto anterior, es vale, ¿pero cuantas confirmaciones debo esperar?, y la respuesta no es única, depende de por ejemplo, el valor de lo que estés intercambiando, no es lo mismo pagar un par de zapatos y esperar 1 confirmación, que vender una casa y esperar a que la transacción tenga 20 confirmaciones.

 

El que la transacciones tenga mayor número de confirmaciones la hace más segura y prácticamente imborrable de cadena de bloques y tendrás la certeza de que no se podrá revertir fácilmente.

 

Si no entiendes bien esto, te recomiendo leas un poco más sobre como funciona Bitcoin.

Otra alternativa para acelerar transacciones: Child pays for parent

 

Existe otra forma (que yo conozca) de acelerar o hacer que una transacción con una fee muy baja sea de interes para los mineros y con ello hacer el efecto de acelerarla, es conocida como Child-pays-for-parent (CPFP por sus siglas en inglés). Se implemento en la versión 0.13.0 de Bitcoin Core.

 

Esta caráteristica es un tanto más compleja y no todas las carteras la tienen implementada por lo que en caso de querer usarla debes o bien tener una cartera tipo Electrum Wallet, Samourai Wallet entre algunas. Como el objetivo es entender las opciones y conocer como funcionan a nivel teorico, no voy a entrar en los detalles tecnicos y esta enfocada a como funciona Bitcoin Core.

 

El CPFP consiste en gastar una transacción aun no confirmada, también incrementando la fee de la nueva transacción. Esto se puede conseguir de dos maneras:

  • En el primer ejemplo tomas la transacción que has enviado y con los datos de esa transacción creas una nueva a una dirección tuya (pero no la misma) con los mismos UTXOs y le incrementas la fee para que los mineros vean que no pueden confirmar la transacción  o bien haciendo uso de la trx que tu mismo haz enviado, crearías una transacción que tome los UTXO’s que estás enviando los envíen a
  • caso puedes tener una lista de txs que tienes pendientes de confirmar y que te permita usarlas para CPFP. Sería análogo a hacer RBF pero creando otra TX. En el segundo caso, deberías tener una lista de transacciones que tienes pendientes de recibir, y que te permitiera gastar directamente de ahi.
  • En el primer  

Para explicarlo vamos a pedirles nuevamente a Alice y Bob que nos ayuden:

«Alice paga 1 bitcoin a Bob por un artículo y al pagarle pone una fee muy baja (1 sat/byte), Bob sabe que debe esperar al menos una confirmación antes de entregarle el artículo a Alice. Pero Bob a su vez necesita pagar a Robert (su proveedor), por lo que dedice tomar la transacción que aún esta pendiente de confirmar  . Alice pasa la transacción de Eve a su banquero Bob, pero esta vez con una tarifa más alta. Los mineros ahora querrán confirmar la transacción barata de Eve para poder incluir la transacción más gratificante de Alice en su bloque.

RBF está actualmente en vivo desde el 0.12, pero se ha decidido por el gastador: A menos que el gastador marque la transacción como reemplazable con un número de secuencia no máximo, la transacción es definitiva.

 

haciendo que la trans    hará que los mineros consideren la posibilidad de confirmar la transacción del padre para que los honorarios de la transacción del niño se incluyan en el mismo bloque.

 

La CPFP no es un cambio en el protocolo, sino en la estrategia del minero. Dado que es racional que los mineros la apliquen (ganan más dinero), se espera que la mayoría de los mineros la apliquen. Al menos Eligius parece haberlo implementado. Como mencionó Pieter en los comentarios, cualquier minero que utilice la versión 0.13 o superior explotará utilizando las reglas de la CPFP.

¿Cuál debería usar?

Si eres el gastador y quieres que tu transacción se confirme más rápido, usa RBF. Si recibiste un pago y no puedes convencer al remitente de que suba la tarifa, o la transacción está marcada como no reemplazable, usa CPFP.

Mejor aún, envíe su transacción con la tarifa adecuada la primera vez.

Traducción realizada con la versión gratuita del traductor www.DeepL.com/Translator

Muchas gracias por tu tiempo, como siempre estos artículos los escribo con la intención de ayudarme a entender cómo funciona Bitcoin, pero también para poder ayudar a otros que como yo, buscan entenderlo.

 

Es probable que pueda contener algún fallo o error de mi parte, si fuera así te agradeceré me lo hagas saber, lo que escribo es parte de mi investigación y no esta basada en ningún artículo en particular, sino en revisiones al código o explicaciones que hacen algunos desarrolladores de Bitcoin, pero no me sirven más que para formar mi propia opinión y entendimiento.

 

Gracias y #estudiabtc!!!.

¿Te resultó útil este contenido? Déjanos un comentario por favor.
5/5


Puedes dejarme una propina vía Lightning network

 

o vía Paynyms de Samourai Wallet:

PM8TJR2yPtx5JS8e8CuwXBZMay67mg1RKrtVptBRZQD5qCyZc1rosVCbScFmzgYYrQtVmc6cJZ2hCK2nBra3KAXxXCKPU4K4vRPjnBqGCYKYRUwimKnA +crimsontruth10e

2 comentarios en «RBF»

  1. Muy bueno el articulo, llegue por el directo de youtube Bitcoin 2140, buscando informacion sobre RBF por la vulnerabilidad de las wallets,
    Entendi el tema de RBF, pero me queda duda sobre como un atacante puede reenviar una transaccion que este en la menpool con mas fee si no la puede firmar, el atacante. Solo la puede firmar el propietario de los Bitcoin.
    Como te puede extorcionar el atacante si el poder de firma lo tiene el propietario. Y si no puede extorcionar, que beneficio tiene el atacante? Es solo un malware?
    Porque si el propietario no firma el cambio del fees, el ataque queda bloqueado

    Responder
    • Muchas gracias por tu comentario y agradecido de que te haya gustado el artículo.
      Hablando específicamente del ataque que se comentaba en el directo, es un ataque posible, pero muy complicado, como bien dices el atacante debería tener acceso a tus firmas y eso no es posible a menos de que además de explotar la vulnerabilidad el atacante tenga acceso a tus claves y además tener acceso a un minero que le ayude. Te dejo este link dónde se explica con más detalle el tema: @nvk: This attack would require ….

      Responder

Deja un comentario

A %d blogueros les gusta esto: