Author

Topic: ¿RBF para cancelar transacciones no confirmadas? (Read 477 times)

legendary
Activity: 2338
Merit: 10802
There are lies, damned lies and statistics. MTwain
<…>
Realmente, más que reenviar la TX, se trataría de generar un nueva TX con los mismos inputs. La dirección de destino puede ser otra, y es así como hacen el timo rápido de la TX no confirmada: Te remiten la TX a tu dirección (normalmente con un fee bajo, para que no se confirme rápidamente), el destinatario no espera la confirmación y da por asentado que los fondos son "suyos", liberando su parte de la TX comercial (por ejemplo, envío de dinero o de Alts). El timador, vuelve ahora a enviar la TX, con los mismos inputs, a otra dirección (una suya por ejemplo).

Negocio redondo: El timador tan solo se ha gastado los fees (segundos), a cambio de algo probablemente más sustancial.
newbie
Activity: 19
Merit: 8
Cuando todavía no hay ninguna confirmación de la TX, es cuando se puede realizar un doble gasto de manera más sencilla. Puedes por ejemplo realizar un pago en un negocio, y a continuación realizar un envió de la misma cantidad a otra dirección que esté en tu poder, con un Fee más alto.


Me quedó la duda cuando dices "un envío a otra dirección que esté en tu poder".

Tenía entendido que esta opción solo deja reenviar una transacción a la misma dirección de destino, ¿es incorrecto?
legendary
Activity: 2338
Merit: 10802
There are lies, damned lies and statistics. MTwain
<…>
Esas serían las utilidades éticas. Las no éticas serían relativas a intentar engañar a un ingenuo, que de por válida una TX no confirmada como elemento para liberar su parte de la transacción comercial. Por eso, los receptores deben esperar siempre cuanto menos 1 TX, y si son más mejor (3..6). La primera confirmación es la que puede costar más tiempo, según el fee, pero las demás deben ir a razon de 10 min por TX adicional (en BTC) - el tiempo medio por bloque generado.
newbie
Activity: 19
Merit: 8
Bien, creo haber entendido.

Entonces, este protocolo serviría si por ejemplo incluí una tarifa demasiado baja por error o en caso de necesitar una confirmación + rápida.

¿Pero también sirve si un usuario quiere revertir un pago hecho a una dirección equivocada?
legendary
Activity: 2338
Merit: 10802
There are lies, damned lies and statistics. MTwain
Cuando todavía no hay ninguna confirmación de la TX, es cuando se puede realizar un doble gasto de manera más sencilla. Puedes por ejemplo realizar un pago en un negocio, y a continuación realizar un envió de la misma cantidad a otra dirección que esté en tu poder, con un Fee más alto. Lo más probable es que los mineros procesen esta segunda TX primero, lo que invalidaría la primera TX. Esto no siempre es con mala fe. Por ejemplo, si has enviado una TX con fees muy bajos, puedes intentar reenviar una con los mismos inputs, con fees más altos, para ver si se procesa antes que la primera, “acelerando” de facto su procesamiento, a costa de más fee.

De ahí que, como mínimo, has de contar con una confirmación de TX para darla por consolidada, aunque comúnmente, los Exchanges requerirán 3, y 6 para pagos de un importe elevado. Ahí cada cual puede poner el umbral donde considere (incluso más allá de las 6 confirmaciones).

Entre 1 y 6 confirmaciones, el doble gasto no se produciría potencialmente por enviar la misma cuantía nuevamente a un fee más elevado (como en el caso anterior descrito sin confirmación mediante), sino que estaría potencialmente sujeto a un ataque del 51% del Hash, que permitiría a un atacante controlar la validación de los bloques, e introducir o deshacer TXs ya confirmadas. Cuantas más confirmaciones, más hashrate sostenido hace falta, y se suele pensar que con 6 confirmaciones de TX, el coste de un ataque del 51% es poco probable dado su coste.

Este hilo no está mal para comprender cómo podría suceder (explicado sobre alts):
How does a double spend 51% attack work ? Explanation and examples.
newbie
Activity: 19
Merit: 8
Leyendo sobre el protocolo RBF, me surgieron varias dudas.
Supongo que las fuentes que aquí comparto están erradas o muy incompletas.

Resumen de lo que dicen:

Los 3 links afirman, sin explicar, que sería posible revertir una transacción de BTC no confirmada -0-, usando el protocolo RBF.

Con esta función, incorporada en algunas wallets -Electrum, Green de Blockstream, etc.-, sería posible crear una nueva transacción con el monto exacto transferido originalmente y enviarla a la misma dirección con una tarifa más alta. Esto podría incentivar a los mineros a procesarla, invalidando la transacción original.


Una vez una transacción es confirmada 3 o más veces, ya se agrega a un bloque de la cadena en modo irreversible. En otras palabras, una transacción confirmada no puede cancelarse, revertirse, etc. Bien.

Pregunta:

Pero si aún no tiene ninguna confirmación, ¿se podría usar este protocolo?.

¿Sirve usar esta opción para tratar de revertir una transacción aún no confirmada enviada a una dirección válida pero errónea?

También asocian este protocolo con el problema del doble gasto.

Supongo quienes los escribieron han mezclado muchas cosas y dejado fuera tantas otras.

LINKS

https://news.bitcoin.com/video-shows-how-easy-it-is-to-double-spend-btc-using-rbf/
https://coincentral.com/cancel-unconfirmed-bitcoin-transaction
https://www.academiablockchain.com/2019/05/21/como-cancelar-transacciones-bitcoin-no-confirmadas/
Jump to: