Segwit2x y el curioso caso de la Replay Protection

En noviembre, los signatarios restantes del acuerdo de Nueva York planean implementar el hard fork del Segwit2X para duplicar el límite de tamaño del bloque de Bitcoin, permitiendo hasta 8 MB de espacio de bloque. 

Dado que no todo el mundo apoya este hard fork, esto bien podría “dividir” la red Bitcoin en dos cadenas de bloques y en monedas incompatibles, como son Bitcoin y Bitcoin Cash.

El hard fork de este acuerdo es controversial y no solo porque carezca de consenso, sino también debido al diseño de las elecciones realizadas por el equipo de desarrollo detrás del BTC1.

Quizás lo más importante es que este equipo de desarrollo liderado por el CEO de Bloq, Jeff Garzik, se ha negado a implementar la Replay Protection como una medida que implementó Bitcoin Cash. En parte por esta razón, al menos un signatario como Wayniloans, ha rechazado en aceptar el acuerdo.

Entonces, ¿Qué es Replay Protection y por qué debería BTC1 implementarlo… y también por qué no debería?



¿Qué es Replay Protection y qué son los ataques de repetición?

Bitcoin podría ver otra “división” en noviembre. Podría decirse que es más preciso considerar a los nodos y a los mineros “divididos” como una criptomoneda completamente nueva con una nueva cadena de bloques y una nueva token y no una verdadera división del Bitcoin en si mismo.

Este artículo se enfocará en la cadena de bloques y en la moneda que sigan el protocolo actual de Bitcoin denominado Bitcoin heredado. La cadena de bloques y la moneda que sigue el hard fork del acuerdo de Nueva York se conoce como SegWit2X.

Si ocurre esta división, las dos cadenas de bloques serán idénticas. Todas las transacciones pasadas y saldos se copiarán desde la cadena de bloques Legacy Bitcoin a la cadena de bloques SegWit2X. Todos los propietarios de BTC poseerán una cantidad correspondiente de B2X.

Sin Replay Protection, las nuevas transacciones serán igualmente válidas en ambas cadenas. Esto significa que estas transacciones se podrán copiar o “repetir” de una cadena a otra para que ocurran en ambas. Esto es lo que se denomina “ataque de repetición”.

Entonces, digamos que Ana tiene BTC en el momento de la división, lo que significa que también tendrá B2X después de la división. Luego, después de la división, ella quiere enviar BTC a Bill, por lo tanto, crea una transacción que gasta bitcoins desde una de sus direcciones Legacy Bitcoin a una de las direcciones Legacy Bitcoin de Bill.

A continuación, transmite esta transacción a través de la red Legacy Bitcoin para que un minero Legacy Bitcoin la tome y la incluya en un bloque Legacy Bitcoin. El pago se confirma, todo correcto.

Segwit2x

Pero esta misma transacción es perfectamente válida en la cadena de bloques SegWit2X. Cualquiera, incluido Bill, puede tomar la transacción Legacy Bitcoin de Ana y también transmitirla a través de la red SegWit2X para que un minero la incluya en un bloque SegWit2X. (Esto incluso puede suceder por accidente con mucha facilidad).

Si este pago también se confirma, Ana habrá enviado a Bill sin querer, no solo bitcoins, sino también una cantidad similar de B2X, y por supuesto, todo esto al revés también es verdad.

Si Ana envía B2X a Bill, ella podría enviarle accidentalmente también bitcoins. Por lo tanto, la falta de Replay Protection es un problema para los usuarios de ambas cadenas. Nadie quiere enviar accidentalmente dinero, ni siquiera dinero gratis.

Técnicamente, hay formas de “dividir” las monedas en ambas cadenas para garantizar que solo puedan gastarse en una sola cadena. Esto por ejemplo, requeriría que las monedas recién extraídas se mezclen en una transacción.

Los bloqueos de tiempo también pueden ofrecer soluciones, pero esto requiere un esfuerzo y no es sencillo, especialmente para los usuarios promedio, sin mencionar que en primer lugar muchos usuarios promedio ni siquiera saben lo que está sucediendo.

Para evitar este tipo de molestias, al menos un lado de la división podría agregar una regla de protocolo para garantizar que las nuevas transacciones sean válidas en una cadena pero no en la otra. Esto es lo que se denomina Replay Protection.

¿Por qué debería BTC1 implementar Replay Protection? ¿Y por qué no Bitcoin Core?

En caso de una división, al menos un lado debería implementar Replay Protection, pero muchos desarrolladores de Bitcoin Core y otros creen que solo hay una opción viable. Es la parte divisoria, en este caso, BTC1 la que debería hacerlo.

Hay varios argumentos para esto:

En primer lugar, tiene más sentido que BTC1 implemente Replay Protection porque requiere el menor esfuerzo. De todos modos, BTC1 es un nuevo cliente que ya está implementando nuevas reglas de protocolo y que todavía no se ha implementado ampliamente. Sería relativamente fácil para BTC1 incluir Replay Protection.

Mientras tanto, Bitcoin Core no sería suficiente para implementar Replay Protection por sí mismo. Si bien es dominante, e incluso algunos la consideran como la implementación de referencia que define el protocolo, Bitcoin Core no es la única implementación de Bitcoin en la red.

Bitcoin Knots, Bcoin, Libbitcoin y otros clientes alternativos tendrían que implementar también Replay Protection. (Sin tener ni siquiera en cuenta a los clientes de nodos no completos)

Aún más importante, la realidad de la situación actual es que todos los nodos de Bitcoin desplegados no tienen implementada la Replay Protection, y lógicamente no pueden, incluso algunos de estos nodos anteriores al acuerdo de Nueva York.

Por lo tanto, incluso si Bitcoin Core y otras implementaciones aplicaran la Replay Protection a las nuevas versiones de su software, no sería suficiente. Todos los usuarios deben actualizar a esta nueva versión aproximadamente en dos meses: un período de tiempo muy corto para una actualización de toda la red.

Si solo algunos de los nodos de la red se actualizan a estas nuevas versiones, Bitcoin podría dividirse en tres: Legacy Bitcoin, SegWit2X y “Replay Protected Bitcoin”. No hace falta decir que esta división de tres vías probablemente empeoraría el problema, no la mejoraría.

Por último, hay un poco de argumento filosófico. Cualquier persona que quiera adoptar nuevas reglas del protocolo, según el argumento, tiene la responsabilidad de dividirse de la manera más segura posible. Esta responsabilidad no debe recaer en aquellos que quieran seguir utilizando el protocolo existente: deben seguir utilizando el protocolo tal como está.

Muchos desarrolladores, incluido el fundador de RSK, Sergio Lerner, que redactó la propuesta de SegWit2Mb en la que se basa SegWit2X, han argumentado que BTC1 debería implementar Replay Protection. De hecho, muchos desarrolladores piensan que cualquier hard fork, incluso uno que aparente ser completamente indiscutible, debería implementarlo.

Pero hasta ahora, el equipo de desarrollo de BTC1 solo consideraría opcional la Replay Protection (de aquí en adelante RP).

¿Qué hay de malo con la Replay Protection opcional?

La implementación de la RP opcional, tal como lo propuso el antiguo desarrollador de Bitcoin, Gavin Andresen, actualmente se encuentra en análisis de proyección para BTC1.

En resumen, este tipo de RP opcional, haría que ciertas transacciones generadas del Legacy Bitcoin (“OP_RETURN”) sean inválidas en la cadena del SegWit2X. Cualquiera que quisiera dividir sus monedas podrían gastar sus bitcoins con dicha transacción.

Estas transacciones deben confirmarse en la cadena de bloques Legacy Bitcoin pero no en la cadena de SegWit2X. Esto efectivamente divide las monedas en diferentes direcciones “salidas” en ambas cadenas.

Dicha RP opcional es probablemente mejor que nada absolutamente, pero todavía no es una solución definitiva.

replay protection

Un problema es que la cadena de bloques del Legacy Bitcoin debería incluir todas estas transacciones OP_RETURN. Esto probablemente daría como resultado más transacciones en la red y requeriría datos adicionales para cada transacción.

Todos estos datos deben ser transmitidos, verificados y al menos temporalmente almacenados por todos los nodos del Legacy Bitcoin. Esto presenta una carga para la red del Legacy Bitcoin.

Pero lo que es más importante, probablemente todavía no sea muy fácil utilizar esta opción. Puede ser suficiente para usuarios profesionales (exchanges, proveedores de monederos y otros proveedores de servicios) y para usuarios individuales expertos en tecnología.

Pero también estos tipos de usuarios generalmente son los que podrían dividir sus monedas incluso sin RP. Los usuarios promedio si son conscientes de lo que sucede, probablemente les resulte mucho más difícil utilizar RP opcional.

Por lo tanto, la RP opcional, ofrece ayuda a quienes menos lo necesitan y hace poco para quienes más lo necesitan.

¿El acuerdo de Nueva York puede descartar la Replay Protection?

Si bien no está claro lo que se discute a puertas cerradas, el acuerdo de Nueva York parece ser un mínimo acuerdo publicado el 23 de mayo de 2017, y realmente solo consta de dos puntos concretos:

  • Activar segwit a un límite del 80%, señalizando en bit 4
  • Activar un hard fork de 2 MB dentro de los 6 meses

Con el primer punto completado a través de BIP91, el único punto restante es un hard fork a 2 MB antes del 23 de noviembre. (Esto supone que este hard fork no se completó con la creación de Bitcoin Cash, que cuenta con el respaldo de varios signatarios del acuerdo de Nueva York)

En particular, muchos detalles no cierran, por ejemplo, el acuerdo ni siquiera establece que los signatarios deban ejecutar específicamente el software del BTC1: cualquier implementación de software que aplique un hard fork a 2 MB podría funcionar.

Esto podría incluso incluir una implementación de software que aplique RP, y por supuesto, nada del acuerdo impide que BTC1 implemente RP, ya que algunos signatarios incluso pudieron haberlo esperado.

¿Por qué BTC1 no implementará la Replay Protection?

En realidad, hay varias razones por las que BTC1, tanto las declaradas como las especuladas, pueden no querer agregar RP.

La primera razón es que la RP requeriría monederos de verificación de pagos simplificados (SPV) y algunos otros clientes ligeros para actualizarse a fin de enviar y recibir transacciones en SegWit2X.

Por lo tanto la RP, en palabras del desarrollador de BTC1, Jeff Garzik, “interrumpirá” los monederos SPV porque no serían compatibles con SegWit2X hasta que se actualicen.

Si SegWit2X fuera a implementar la RP (y si los monederos SPV no se actualizan), estos monederos todavía podrían enviar y recibir transacciones en Legacy Bitcoin perfectamente bien. Además de eso, no gastarían accidentalmente B2X cuando no sean de su intención.

Mientras tanto, si la cadena de SegWit2X no implementa la RP (y si los monederos SPV no se actualizan), los usuarios no podrán asegurarse de si su monedero estará recibiendo o enviando transacciones BTC o transacciones B2X o ambas. También no podrán asegurarse de si el saldo en su monedero es un saldo de BTC o un saldo de B2X o ambos.

En este caso, si el poder de hash se moviera de una cadena de bloques a otra con el tiempo, estos monederos podrían cambiar incluso los balances de BTC a B2X o al revés sin que los usuarios lo sepan. (Este problema podría resolverse en cierta medida, a través de otra solución, pero esto todavía no se ha implementado en ninguno de los dos)

De hecho, no implementar la RP en SegWit2X podría decirse que “interrumpir” los monederos SPV sería mucho peor.

El único escenario plausible en el que implementar RP, no debería interrumpir los monederos SPV y mucho peor si no se habla del Legacy BitcoinDe hecho, el acuerdo de Nueva York tiene la intención específica de “actualizar” Bitcoin, en lugar de dividirse en una nueva moneda como lo hizo Bitcoin Cash.Legacy Bitcoin

En base a la señalización de los mineros y a las declaraciones con intenciones de varias grandes empresas de Bitcoin, algunos signatarios del acuerdo afirman que Legacy Bitcoin no podrá sobrevivir en absoluto.

Por lo tanto, implementar RP es una admisión de que SegWit2X se separará de Legacy Bitcoin en algo nuevo y no se considerará la versión actualizada de Bitcoin, pero la suposición de que Legacy Bitcoin no pueda sobrevivir es muy grande.

En realidad, la señalización de los mineros no tendrá sentido mientras Bitcoin Core, la implementación dominante de Bitcoin, no adoptara el hard fork.

También hay una lista importante de empresas que no han declarado respaldar el hard fork, incluidos dos grupos de top 10 de minería. Del mismo modo, no está claro si muchos usuarios (individuales) admitirán SegWit2X.

La implementación de protección contra borrado (otra medida de seguridad) también sugiere que incluso los desarrolladores de BTC1 no están tan seguros de que solo habrá una cadena de bloques.

Quizás todavía lo que es más importante, es que no está claro que la RP no afecte nada de esto. Si los mineros, desarrolladores, empresas y usuarios consideran a SegWit2X como una actualización de Bitcoin, probablemente lo hagan con o sin RP.

Es por eso que también se ha sugerido que BTC1 está rechazando la RP con el propósito específico de ser lo más disruptiva posible. Si la cadena del Legacy Bitcoin se vuelve inutilizable, SegWit2X podría tener la mejor posibilidad de ser reconocido como “Bitcoin”.

Si tienes cualquier inquietud relacionada con este artículo acerca de la Replay Protection y su implementación al Segwit2x, participa con tu comentario. Si te ha gustado, vota para mejorar la experiencia de usuario y si quieres contribuir a promoverlo, comparte en tus redes sociales. ¡Muchas Gracias!

¿TE HA RESULTADO INTERESANTE ESTE ARTÍCULO? ¡VOTA PARA MEJORARLO!
[Votos: 1 Promedio: 4]
Si has llegado hasta aquí y te ha gustado, puedes compartirlo ¡Gracias!Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedIn
loading...

¡Dale comenta, tu opinión es importante!