Thread by @ishi0k

1- Hilo🧵activación de #FullRBF en Bitcoin Core 24.0. Es exagerado decir que, el debate por la activación de la versión 24.0 es similar a la guerra de bloques del 2017 con segwit; pero junto con el #BIP119 (covenants) propuesto por #JeremyRubin, ha generado buen debate en #BTC

2 - Hay algunos términos importantes que tomar en cuenta para considerar el impacto y el debate.
CERO-CONFIRMACIONES: significa que se acepta una transacción de #Bitcoin incluso antes de que los mineros la hayan INCLUIDO en un bloque, por lo tanto es una TX NO confirmada.

3- Otro termino importante es: RBF (Replace By Fee). Significa que #Bitcoin te permitía poder reemplazar el FEE (por uno más alto) que se paga a los mineros de TX (on-chain) que cumplieran #ciertas condiciones.

4- Uno más: RBF/OTP-IN (opcional). El valor predeterminado en #Bitcoin es que las transacciones por default NO son reemplazables. Para hacerlas reemplazables, se tiene que habilitar una una bandera/indicador, se puede hacer por medio de una wallet, no todas lo ofrecen.

5- Bitcoin Core tiene una regla: first seen (primero visto), si un nodo recibe una TX que contradice otra transacción, un posible (doble gasto), esta será rechazada y no será incluirá en la mempool.

6- El último: Delayed RBF, es una variante que permite que las transacciones se reemplacen incondicionalmente, pero solo después de que se haya extraído una cantidad determinada de bloques desde que el nodo vio por primera vez (first seen) las transacciones reemplazadas.

7- La nueva versión de Bitcoin Core, la 24.0 cambia dos detalles sobre RBF.
Dividiendo el primero.
a) Los usuarios pueden configurar su nodo para reenviar incluso transacciones en conflicto.
b) Pueden desactivar la regla de "primero visto"
a esto es lo que se le llama #FullRBF

8- El segundo detalle importante es que, en la versión 24.0 (ya liberada), se configura automáticamente la opción "-walletrbf" en TRUE, lo que significa que #RBF es la opción predeterminada/default (ya no es voluntario/opcional).

9- Ahora la pregunta de relevancia, ¿Por qué la nueva versión de Bitcoin Core la 24.0 ha generado debate?
Como lo dije al inicio, actualmente hay ciertas wallet y protocolos que se benefician especialmente de la primra opción mencionada: #ZeroConf (cero confirmaciones).

10- Veamos algunos ejemplos de quienes se benefician de las CERO-CONFIRMACIONES en #Bitcoin
Comencemos por una de las wallet más famosas, hablamos de @MuunWallet en el caso de Muun, se beneficia para poder efectuar los #submarineswaps que permiten que se pueda operar con LN.

@esneider fundador de Muun-Wallet, dijo que: #FullRBF donde las CERO confirmaciones ya no sería una opción; obligará a #desactivar los submarine swaps para Lightning en la wallet, afectando unos 100,000 usuarios que hacen uso de LN con Muun.

12- Por otro lado, dentro de los afectados, también están los cajeros #ATM que dispensan FIAT usando #Bitcoin como contraparte. Se imaginan esperando que un cajero les dispense el FIAT, luego de 10 minutos, horas? los ATM no esperan que las TX sean confirmadas, asumen el riesgo.

13- Otro protocolo afectado sería @bitrefill que hace uso de cupones/tarjetas de regalo, se beneficia del ZERO-CONF en #Bitcoin

14- Agrego más información antes de continuar con los puntos de debate surgidos de la versión 24.0 de Bitcoin Core. (RBF) es una #política de nodo que permite reemplazar una TX NO confirmada en la #mempool por otra ENTRADA que utilice el mismo UTXO, pero pagando más FEE.

15- Diferentes software/clientes de nodo pueden utilizar diferentes reglas RBF. La forma más utilizada de RBF en la actualidad es #BIP125 opt-in liberada en la versión de Bitcoin Core 0.12.0.

16- Originalmente, ¿Por qué nació la necesidad de implementar RBF? parte de la respuesta es: tener la posibilidad de darle prioridad a una TX para ser confirmada, en escenarios donde la #mempool esté saturada y que tu TX no sea atractiva en cuanto a FEES para los mineros.

17- Cabe mencionar que RBF era posible en la versión original de Bitcoin, pero Satoshi Nakamoto eventualmente deshabilitó la función, porque la forma en que la implementó originalmente, creó un vector para ataques de denegación de servicio (DOS) contra nodos (spam).

18- En un tweet anterior, hice mención q, actualmente es el usuario el q decide si quiere que su TX sea reemplazable, ahora, la decisión recaerá sobre el dueño del nodo, dependerá de él, el habilitar o deshabilitar la opción, si la TX cae en nodo habilitado, RBF aplicar x default

19- El inconveniente de hacer que esta opción esté disponible, es que, RBF-FULL podría no funcionar de manera consistente, si solo una pequeña parte de la red, incluidos los mineros, eligen habilitarlo. Recuerden: Mi nodo, mis reglas.

20- Bitcoin Core 24.0, ahora establece por defecto la opción de inicio #walletrbf y usa por defecto la opción #reemplazable (RBF) para los RPC #createrawtransaction y #createpsbt. Todas las TX creadas con la wallet de Bitcoin Core, estarán (habilitadas para RBF por default).

21- Bitcoin Core 24.0, establecerá un nuevo parámetro llamado #mempoolfullrbf que por default estará DESACTIVADO (FALSE). Al activarlo, la regla del "first seen" perdería efecto. Hacer relación con el twitt #19.

22- Retomando el tema del debate por los cambios implementados en Bitcoin Core 24.0. Dí avances en los twitt #12,13 y 14. Una de las cosas que hay que saber, es que, una TX marcada actualmente como RBF, representa un riesgo para los comercios, es posible aplicar un "doble gasto".

23- Entiéndase por un "doble gasto" del twitt anterior, algo como lo siguiente: hago una compra, pago on-chain y marco dicha TX como RBF, el comercio me entrega el producto, doy la vuelta y luego aplico un replace, posiblemente el comerciante nunca reciba los fondos.

24- A las criticas también se suma John Carvalho @BitcoinErrorLog según Carvalho algunos Core Dev de #BTC están tratando de "atacar" a #Bitcoin al obligar a una agenda para realizar todas las transacciones RBF de forma predeterminada.

25- Carvalho @BitcoinErrorLog también dijo: “Este ataque incluye mentiras en la lista de correo de Core Dev y cabildeos, cambios de código en el nodo Core e intentos de soborno a los mineros". Según John, no solo los Dev deben decidir sino se debe escuchar a los comerciantes.

26- Como lo mencioné antes, algunos de los que se oponen a la actualización, afirman que, para un comercio es menos riesgosa una TX marcada sin RBF, adicionalmente que, el análisis de riesgo para ciertas empresas/protocolos que se benefician del ZERO-CONF es más manejable.

27- Veamos comentarios q apoyan la actualización 24.0 y sus argumentos. "Confiar en transacciones 0-CONF no parece muy inteligente cuando la mayoría de las transacciones on-chain serán de gran valor en el futuro". "RBF sería buen incentivo para LN y menos riesgo psts ls L1".

28- Peter Todd @peterktodd Core Dev dijo: “Recientemente, los mineros me contactaron personalmente para preguntarme cómo pueden activar [RBF FULL]. Obviamente, #señalarles una opción de configuración es lo más sencillo para ellos", en referencia al parámetro #mempoolfullrbf

29- Hay mucho q decir, pero aportaré mi conclusión. ¿[Full-RBF] ofrece algún beneficio además de romper las prácticas comerciales [zero-conf]? no podrá calcular el balance de los a afavor y en contra, siempre promuevo el debate sano y con argumentos fuertes y con respaldo.

30- En #BTC siempre debe primar la seguridad por sobre los deseos o intereses personales, en BTC la palabra "honesto" tiene mucho significado, pero hay conflicto entre "seguir una regla pre-especificada, ya sea #racional o no, los que abogan por el sí, lo ven del lado racional.

31- Para mi, LN es una buena forma para sustituir el ZERO-CONF, también pienso que en #BTC es saludable escuchar a todas las partes, nunca puedes quedar bien con todos, no sé, si los casos de uso (ZERO-CONF), suman en peso, para volver atrás. Lo que no debe haber es imposición.