Ya he comentado en anteriores articulos la batalla en la que estamos inmersos en Bitcoin Cash con dos bandos a los que voy a denominar BCH IFP y BCH no-IFP . La batalla de potencia de calculo de minería ("Hash War") se dirimirá el 15 de Noviembre de 2020 .
Con muchísima probabilidad todos los mineros que minen bloques en la rama BCH IFP lo harán usando el software de cliente de nodo de Bitcoin ABC, mientras que los que lo hagan en la rama BCH no-IFP lo harán usando el software de cliente de nodo BCHN; aunque para esta última rama hay mas opciones voy a simplificar el problema en aras a facilitar la comprensión de mi planteamiento.
Además de una batalla entre grupos de desarrolladores hay una batalla mediática en las redes sociales muy importante, plagada de trucos para desprestigiar al contrario. Quiero fijarme especialmente en el comentario de los partidarios de BCHN que dicen que su nodo seguirá siempre la cadena con mayor potencia de cálculo acumulada. Esta aseveración tiene, como casi todo en la vida, ventajas e inconvenientes.
La ventaja es la buena prensa que le proporciona, ya que a ojos de los que solo ven la punta del iceberg este "buenismo" les hace ganar adeptos para su causa.
El inconveniente es el riesgo que corren los mineros BCH no-IFP de que los bloques que encuentren sean finalmente desechados debido a posibles reorganizaciones si la rama BCH IFP acumula finalmente mas trabajo durante un periodo aproximado de 100 minutos.
Las reorganizaciones son imposibles, a día de hoy el bando no-IFP tiene señalizado un respaldo mayor de Hash Power, ¿o no?
Si acudimos a la única fuente actual de que van a hacer los mineros a partir del día D (15 de Noviembre de 2020), todo parece indicar que de momento así es:
Este valor evoluciona continuamente, en el momento de escribir el artículo se señaliza un 53,2 % a favor de BCHN (BCH no-IFP). No hay ninguna señalización a favor de ABC.
Entonces, parece muy claro que la mayoría del HP de los mineros está a favor del bando BCH no-IFP. Sin embargo el diablo aparece en los detalles que no se distinguen a simple vista.
La señalización a favor de BCHN en un bloque hasta el día D no tiene ningun coste/inconveniente.
Minar con BCHN a partir del día D (y la hora H que será las 12:00 AM UTC) si que tiene un coste en forma de riesgo de que el bloque que encuentres sea finalmente desechado.
Puede haber mineros que actualmente señalizen una cosa y finalmente hagan otra distinta intentando engañar a sus competidores (Sybil attack). La falta de "Sybil protection" es el talón de aquiles de este y otros sistemas de señalización como mecanismos para alcanzar un consenso, como puede ser el BMP ("Bitcoin Mining Parliament"). La situación es mucho peor si cabe si tenemos en cuenta que BCH es una minoría, poco más de un 2,2% actualmente, de las recompensas a sus mineros dentro de la tarta que se reparten todos los mineros capaces de minar el mismo algoritmo.
El sistema de incentivos que hay con las cartas boca arriba (el IFP es un "Soft Fork" y una vez conocidas que intenciones va a tener cada minero), permite una gamificación que favorece a los mineros que sigan la rama BCH IFP frente a los mineros que siguen la rama BCH no-IFP.
¿Como se puede disminuir ese riesgo?
Yo vislumbro tres alternativas:
Forzar manualmente la separación mediante la coordinacion de todos los nodos y la ejecucción del comando InvalidateBlock "000....xxx".
Forzar algorítimicamente la separación a priori mediante la implementación de "replay protection".
Forzar la separación a posteriori.
La primera de las soluciones tiene la ventaja de que puede manejarse como un as en la manga, es decir, solo utilizarla si fuese necesaria. Por contra aparece el problema de una coordinación de todos los nodos mediante la ejecucción de un comando que se tiene que introducir manualmente en todos y cada uno de los nodos y en el espacio menor de tiempo. Esta opción también podría acarrear un desgaste de imagen porque se vería el incumplimiento del "buenismo" de partida, aunque yo creo que este desgaste pasaría desapercibido para la mayoría de observadores.
La segunda de las soluciones tiene inconvenientes técnicos, implementar replay protection supone actualizar todos y cada uno de los programas que explicitamente quieran seguir dicha cadena de bloques, pero a cambio desaparece por completo el riesgo de rechazo de sus bloques para los mineros. Además, y este es el factor que yo considero mas importante, utilizarán de nuevo la maquinaría de la opinión pública superficial para que vean a este bando como el que tomó la medida que mas favorecía el interes de todo, cuando la realidad es otra bien distinta, disminuir el riesgo de salir derrotados a partir del día D hora H, y como consecuencia que no exista una cadena de bloques BCH no-IFP.
La tercera opción tiene el inconveniente de que de cara al ecosistema lo hará desde una posición de "perdedor" de la batalla dirimida, aunque será una opción perfectamente válida.
Por estas razones yo considero que el bando BCH no-IFP podrá anunciar en breve la implementación de un mecanismo de "Replay Protection", de nuevo bajo el caparazón de ser los buenos de la película.
En efecto muchas cosas pueden pasar hasta que llegue el día de la actualización.
De hecho, soy de los que asumen que así será (es sano suponerlo; nada es tan fácil y hay que estar preparados). Pero hay algunas posibilidades adicionales que me gustaría mencionar:
Primero, las señalizaciones que promueven reemplazar ABC por BCHN no determinan el resultado del 15N, cierto. Pero para mí el fenómeno no tiene ese objetivo. Tiene una función coordinadora o informativa sobre el futuro, y su auge representa una potencial perdida de estatus de ABC como software de referencia "de facto". Eso puede persuadir a plataformas que operan infraestructura crítica como exchanges, etc, a prepararse para soportar BCH sin IFP, es decir, en el presente suponen un aumento de la confianza (incentivos) para correr software No-ABC.
Segundo, Bitcoin ABC ha renunciado o no ha sabido ser diplomático; por el contrario, ha sido agresivo con otros proyectos y potenciales inversores, y eso le ha hecho quedar cada vez más solo y les supone un desgaste. La división es una probabilidad, pero el CISMA ya es una realidad. Si la separación ocurre, los demás "pierden a ABC", pero ABC pierde casi todo lo demás.
Tercero, si la información disponible resulta ser falsa (señalizaciones, etc) y parte de los mineros "cambia de opinión", hay varias posibilidades de acción. Por ejemplo, una guerra de hash si las fuerzas de BCHN son mayores o equivalentes; o que ambas partes acepten una ruptura y alguna quede con el ticker (que es un gran activo, no hay que negarlo); e incluso que los nodos y mineros IFP se mantengan temporalmente en la misma cadena de ABC pero que programen luego la migración definitiva a un BCH sin IFP que se alinee con los principios de descentralización, innovación o permisionada y ausencia de equipo de desarrollo "oficial", quedándose ABC con algo parecido a la blockchain de Bitcoin SV (BSV).
Cuarto, si la información disponible resulta ser mayormente verdadera (es decir, si ningún pool "cambia radicalmente de opinión"), ya los nodos ABC están programados para bifurcarse de la cadena que no les pague el IFP de 8% aunque esta sea mayoritaria. No seguirán participando en la otra cadena salvo que lancen una actualización aceptando su derrota y renunciando al IFP.
Finalmente, si las señalizaciones resultan ser falsas, una de las cosas que pueden pasar antes de que llegue la actualización es que se filtre esa información, en contra de los intereses e imagen del pool que está señalizando falsamente, si son verdaderas, no hay nada que filtrar.