Ha pasado un año desde la última implementación de un hard fork a Bitcoin y ha pasado ya el tiempo luego de que Bitcoin se separara y un grupo prefiera Bitcoin Cash. Ahora nuevamente hay otra separación, a causa de nuevos desacuerdos, ocasionando un nuevo escenario pero esta vez con la causante de que habrá una guerra, las hash wars.

Antecedentes

El día es 1 de agosto del año 2017. Ese día, Bitcoin, la moneda que había sido lanzada el 3 de enero del año 2009, sufre un hard fork en su programa, y en consecuencia de esto, nace una nueva alternativa al Bitcoin: el Bitcoin Cash. Haciendo un poco de historia, en aquellos días el problema a solucionar era la red misma, con muchas transacciones que vienen y van, la comunidad de desarrolladores proponen soluciones diferentes que terminan con la división que hoy conocemos: por un lado Bitcoin y por el otro lado Bitcoin Cash, proyecto encabezado por Roger Ver, quien afirma que Bitcoin Cash es el verdadero Bitcoin.

Detrás de Bitcoin Cash

Si bien es cierto que Bitcoin Cash ha demostrado comportarse como una moneda con un valor mucho más bajo al bitcoin, ha logrado conseguir apoyo de la comunidad: como bien lo señalamos Roger Ver mediante el espacio bitcoin.com y el CEO de Bitmain, Jihan Wu quien ha permanecido en cancha de BCH luego del split. Así mismo Bitprim, BTC.com, Kraken, BitPay y BitGo han mostrado el apoyo a este proyecto y personalidades del mundo cripto como Vitalik Buterin, fundador de Ethereum y Rick Falkvinge, fundador del Partido Pirata.

El día 15 de noviembre del 2018 vuelve a proponerse un hard fork que llevará -esta vez- a dividir el proyecto de Bitcoin Cash en dos: por un lado BitcoinABC (BCH) y por el otro lado Bitcoin Satoshi Vision (BTC-SV)

Cambios propuestos por BCH

La comunidad que apoya a BCH se ha dividido en dos propuestas respecto al futuro de la moneda. Tenemos por un lado a Amaury Séchet (a) Deadal Nix, quien dirige los protocolos de mejora de Bitcoin ABC y cuya comunidad propone cambios varios pero los que debemos resaltar son:

CTOR (Canonical Transaction Ordering[Orden de Transacciones Canonicas]), el cual -de acuerdo a lo establecido por el equipo de ABC– trae beneficios varios para una futura escala como por ejemplo la eliminación de estados intermedios durante la validación de bloques, corriendo la validación paralelamente a la misma y mejorando el desempeño o las mejoras de comunicación y transmisión de datos entre los nodos. La otra mejora es OP_CHECKDATASIG (DSV), un nuevo script cuya funcionalidad es abrir la posibilidad de que BCH pueda ser utilizado como una especie de smart contract.

Cambios propuestos por Bitcoin SV

La comunidad que apoya a BTC-SV está liderada por Craig Wright el Satoshi falso o Faketoshi, quien ha intentado hacerse pasar por Satoshi Nakamoto una y otra vez mediante el uso de informaciones falsas. Su propuesta denominada “Satoshi’s Vision” o la visión de Satoshi, tiene por objeto regresar al año 2009, especificamente, regresar al protocolo original 0.1.0 y esto lo quire hacer mediante cambios relativos a Bitcoin ABC. Rechazan la implementación del CTOR pues alegan que hay un gran riesgo detrás. El segundo cambio que harán es pasar de tener el límite de bloque de 32 MB (tamaño actual de Bitcoin ABC) a 128 MB.

Pero esto no queda aquí, Craig toma también un camino político -de alguna forma- prometiendo en el largo plazo, la eliminación de los límites de los tamaños de bloque, y recuperar monedas perdidas o fuera de circulación.

Todos apoyan a Bitcoin ABC ¿no?

Casi. Es cierto que Craig no tiene un apoyo de personalidades ni empresas de gran porte -la mayoría apostaron por Roger y Deadal- y si bien su apoyo más próximo es CoinGeek, su fuerza reside en los pools de minería. Varios pools han demostrado un abierto apoyo a abrazar el proyecto BTC-SV mientras queda un importante grupo de neutrales quienes esperan ver hacia donde sopla el viento para realizar los cambios.

¿El problema?

El problema es que hay discrepancias técnicas debido a los caminos que tomaron. El hecho de haber dividido a Bitcoin ABC en dos (ABC y SV) hace que los mineros ejecuten bloques inválidos para el otro (es decir, ABC invalida a SV y viceversa), haciendo que los poseedores de BCH tengan en este momento dos monedas y pueden minar dos monedas.

Pero Nelson, ¡mejor para el minero!

Sí…no hubiese sido un problema si hubiera sido una separación sin obstaculos, mediante algo denominado replay protection, el cual los usuarios no iban a ser afectados. Pero acá empieza el problema. ¿Te acordas que más arriba leiste que Craig anuló algunas cosas para volver al protocolo 0.1.0? Bueno, una de las cosas que también rechazó -para ser justos, ambos bandos rechazaron- fue esta protección.

¿Dijiste replay protection..?

Sí. Cuando haces un fork hay dos cosas que debemos tener en cuenta: transaction replay y replay protection.

Transaction replay -en un contexto de forks- es cuando una transacción es válido en ambas partes del fork. Cuando realizas una transacción se transmite a la red en ambas partes de la cadena del fork, ambos forks confirman y validan la transacción. Esto es peligroso -de cierta manera- pues al enviar una transacción a una cadena, en realidad estás enviando -sin intenciones- en el otro fork también siempre y cuando haya alguien que tome tu transacción y lo repita (transmita) en la otra red.

Luego está replay protection, que es cuando alguien hace algo y la transacción de un lado son válidas y del otro son inválidas, previniendo el problema anterior. Esto va desde simplemente invalidar una transacción o dirección hasta cambiar el esquema de firmas o cambiar el formato de transacción. Esto hace que repetir transacciones o clonarlos sea prácticamente imposible.

¿Y eso que tiene que ver?

Craig ya dijo lo siguiente:

En un conocido programa dirigido por Tony Vais, adelantó lo siguiente respecto al fork:

Ahora sumemos una cosa más:

Si tienes algún tiempo en el mundo de las criptomonedas, ya estás empezando a asustarte y si no entiendes, lo que está diciendo FakeToshi es que hará lo que sea para que sus cadenas sobrevivan, incluso si eso significa un ataque del 51% en contra de BCH. Estos ataques fueron objetos de especulación durante el primer fork de Bitcoin, cuando BCH nació y ahora volvemos a hablar de ello.

¿Ataques?

Sí. De esos que pueden destruir cosas, anteriormente citamos el peligro de haber eliminado el replay protection, el cual es una amenaza directa pues el user puede perder monedas de ambas partes, dado que las transacciones serán válidas en ambas cadena. Tambien pueden hacer bloques vacíos y para quien tenga la mayoría de los hashs, esto será fácil de ejecutar, es decir crear bloques sin contenido nulo o alguno. Pero para minero que quiere trabajar enserio, el costo es altisimo. Recordemos que, para que esto pase, estás perdiendo tu recompensa de 12.5 BCH. O en cualquier caso, el minero hace algunas transacción spam -varias- para que tenga el efecto similar a los bloques vacíos. Y si crees que no pasa, al momento de escribir esto, esta pasando:

¿Atacará?

Especulamos mucho pero solo los desarrolladores decidirán cual será el camino a tomar. Ojo que tampoco BCH es un gatito indefenso, la guerra consistirá en tener más hash power y teniendo a Jihan Wu de tu lado, lo lógico será usarlo a tu favor. La jugada que nadie quiere hacer es volver a hacer otro hard fork con cambios en los algoritmos del proof-of-work y así evitarse de raíz los problemas actuales pero dado la escalada de insultos, no se descarta nada:

¿Que hacer?

Bueno, no es que no puedas hacer nada, es que no puedes actualmente hacer nada más quemirar. Si tu billetera tiene tus llaves privadas, entonces seguí usandolo tranquilamente PERO si no tenes, entonces empiza a mover en billeteras seguras. Lo más seguro es obviamente no mover tus monedas hasta que estén bien definidos los lados y otros, dado que ni siquiera los exchanges están seguros. Lo mejor en casos como estos es no hacer nada.

¿Puede pasar lo peor? Leíste que sí y que no te quepa ninguna duda de que puede así como no puede. Yo creo que lo más probable es que ambas monedas sobrevivan con sus propios tickers y todo.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.