Se retoma discusión para que todas los envíos de bitcoin sean reemplazables por tarifa

RBF, siglas en inglés de “transacciones con remplazo por tarifa” es una herramienta en Bitcoin (BTC) que permite “destrabar” los envíos de dinero que no se han confirmado. Se logra al aumentar el coste por tarifa.

Actualmente esta herramienta es optativa. Sin embargo, el desarrollador Jeremy Rubin ha retomado una discusión en la que se propone hacer que las RBF que se encuentren activadas por defecto en todas las transacciones de Bitcoin.

La idea original fue planteada por el programador Antoine Riard en junio del 2021, según lo reportó CriptoNoticias, en su momento. Sin embargo, dicha propuesta contenía ciertas limitantes que hacían poco viable la implementación, hasta que estas no fueran resueltas.

Seis meses después de la primera discusión, Rubin propone colocar una especie de contador que impida que se envíen dos transacciones simultaneas hasta no haber completado 10 minutos de espera entre una y otra (este es, aproximadamente, el tiempo que tarda en minarse un bloque de Bitcoin).

Es decir, a un usuario mal intencionado le será imposible enviar dos transacciones de forma casi inmediata, hasta que no se cumpla el tiempo del contador.

Según destaca el artículo de Bitcoin Optech que recoge esta propuesta, el contador de Rubin podría añadirse a la propuesta de Riard de una “torre de vigilancia” que verifique las transacciones. En este caso, 10 minutos se considera que es tiempo suficiente para detectar cualquier irregularidad.

¿Cuál sería el beneficio de RBF por defecto en Bitcoin?

Las ventajas de este tipo de herramientas se encuentran en la reducción de los tiempos de espera en épocas en que la red se congestiona. Por ejemplo, en mayo de 2021, Bitcoin vivió el periodo de dificultad más alto de su historia, lo que coincidió con la caída del hash rate luego del veto en China a la minería. Eso decantó en una red congestionada.

En escenarios como este, utilizar RBF puede ser beneficioso, ya que permite reducir los tiempos de espera, y evitar que una transacción quede atorada hasta que bien sea confirmada, o sea “purgada” de la mempool, cuyo proceso puede durar hasta 14 días, los cuales los fondos se encontrarán bloqueados, sin poder utilizarlos.

Por qué aún no se cuenta con RBF por defecto

El principal motivo por el que no se activa por defecto esta propuesta en la red, es el potencial que implica para ataques de doble gasto. Debido a que algunos comerciantes aceptan pagos con 0 confirmaciones de red, muchos optan por no recibir pagos en Bitcoin marcados con RBF.

Bajo el estándar RBF, un usuario puede engañar a la red mandando una transacción con una comisión muy baja, e inmediatamente enviar otra, con RBF, cambiado la dirección de destino, pero utilizando los mismos fondos con una comisión más alta.

En este escenario, la transacción con mayor comisión será la primera en confirmarse, dejando la otra como una transacción inválida debido a que los BTC ya fueron gastados. Este tipo de ataque se le conoce como ataque DoS.

Claro está, este tipo de estafas solo pueden darse en una red congestionada con altas tarifas por minería. En una red con poco movimiento, como ha ocurrido en los últimos meses, transacciones con las comisiones más bajas (1sat/Byte) se confirman en el primer bloque a salir, debido al poco volumen.

Cabe aclarar que para poder hacer algo así se requiere gran conocimiento técnico, ya que las aplicaciones de monederos para usuarios básicos no permiten enviar dos transacciones RBF cambiando la dirección de destino.

La propuesta aún tiene sus objeciones

Antoine Riard, creador de la propuesta original, comentó que la ide de Rubin le parece “nueva” pero que no está seguro de que resuelva el dilema de un ataque DoS. Esto debido a que la contraparte maliciosa puede compartir la transacción antes de realizar el pago original al comerciante.

Al igual que lo hizo en la propuesta original, Riard insta a utilizar un sistema de seguimiento de salidas de gastos. Este básicamente, verificaría que las UTXO a utilizar en una transacción ya no se encuentren en la mempool, evitando así que el comerciante acepte transacciones que pudiesen comprometer el pago.

Por el momento, la discusión no ha pasado de ser una propuesta, ya que no se ha llegado a una versión real que se pudiese considerar como candidata a implementarse en el código fuente de Bitcoin.