Porque la rama de Bitcoin Cash no-IFP podría necesitar incluir "Replay Protection" antes del dia D.

8 215
Avatar for fmarcosh
3 years ago

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:

Fuente: https://cash.coin.dance/blocks/summary

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.

6
$ 5.45
$ 3.60 from @Marco
$ 0.50 from @Cain
$ 0.50 from @Fidel
+ 3
Avatar for fmarcosh
3 years ago

Comments

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.

$ 0.00
3 years ago

Todo lo que planteas tiene que ver con otra realidad diferente al supuesto de partida del artículo. Nadie podemos leer la mente de los demas ni averiguar el futuro, supongo que ahí estaremos de acuerdo. Tu crees en la señalización como mecanismo de coordinación/gobernanza y yo no.

$ 0.00
3 years ago

Más como disuasión y alineación. Coordinación, sí, pero no del todo gobernanza.

Las acciones propias de la gobernanza toca ejecutarlas el 15 de noviembre.

Todo lo que planteas tiene que ver con otra realidad diferente al supuesto de partida del artículo. Nadie podemos leer la mente de los demás ni averiguar el futuro

Imagino que el supuesto de partida es que ABC conserva la mayoría del POW.

Yo digo que no se puede saber, pero que no hay indicios de que sí, y sí hay de que no.

Creo que eso lo sabremos solamente una vez llegue el momento.

$ 0.00
3 years ago

Puede haber mineros que actualmente señalizen una cosa y finalmente hagan otra distinta intentando engañar a sus competidores (Sybil attack).

Eso no es el "sybil attack".

Bitcoin soluciona el sybil attack con PoW. BMP usa este principio.

$ 0.00
3 years ago

Tienes razón, no es un "sybil attack". Pero la objeción es la misma aunque el termino no sea "sybil attack", es decir, puede haber mineros que actualmente señalizen una cosa y finalmente hagan otra distinta intentando engañar a sus competidores y/o obteniendo ventajas.

$ 0.00
3 years ago

No hay precedentes de señalizaciones engañosas, como lo que sugieres.

La reputación es parte fundamental de la actividad empresarial de los mineros.

Los mineros ofrecen un servicio, algunos pueden actuar como ratas, pero esperamos que la mayoria, en su conjunto, no lo hará.

No hay palabra con más peso que la de un minero, en Bitcoinland.

El problema es que hablan poco. Y apenas saben llegar a acuerdos hoy. Espero que eso cambie.

$ 0.00
3 years ago

Very good article. May I post my english translation of it?

$ 0.00
3 years ago

Yes, of course. Thank you. Obrigado. Gracias.

$ 0.10
3 years ago