Prefacio.

Desde que BCH se bifurcó amigablemente de BTC la emisión de bloques no ha sido del todo buena, desde el inicial algoritmo (EDA "Emergency Dificulty Algorithm"), hasta el que lo reemplazó (DAA "Dficulty Adjustement Algorithm"). Por ello en la comunidad BCH todos hemos estado de acuerdo en corregir este "problema".

En el terreno del software de cliente de nodo de BCH hay una pelea entre ABC (liderada por Amaury Sechet) y otras implementaciones: BU y BCHN (reciente bifurcación del código de ABC). El resto de implementaciones o bien no aspiran de momento a ser utilizadas como cliente de minería (BCHD) y/o no tienen suficiente representación (Verde,Knuth, Flowee, ...).

Recientemente Jonathan Toomim publicó una propuesta a la comunidad de BCH muy bien fundamentada sobre el trabajo previo de Mark Lunderberg bajo el nombre de ASERTi-3d con algunos pequeños flecos pendientes de fijar como el modo de activación.

En una reunión posterior de desarrolladores disponible en youtube donde estaban todos presentes todo parecía ir como la seda y que había un acuerdo para implementar la propuesta de jtoomim en el Hard Fork del próximo 15 de Noviembre, sobre todo teniendo en cuenta la acuciante fecha límite de congelado de funcionalidad del 15 de Agosto.

Ayer Amaury nos sorprendió a muchos con la publicación de su nueva propuesta bautizada como Grasberg DAA.

Revuelo.

Consecuencia del último movimiento de Amaury diferentes actores del ecosistema han aparecido criticando la situación. Amaury esta actuando bajo el síndrome del NIH ("Not Invented Here"). Amaury va a forzar un split que nadie quiere y destruirá mucho valor. Todas estas críticas no son nuevas, ya las hemos oido en ocasiones anteriores y para los que estamos a favor de ABC/Amaury no tienen fundamento mientras que para los que están en su contra simplemente refuerzan sus sospechas anteriores.

En la reunión de desarrolladores, ABC manifestó su inquietud por el hecho de que no había habido ninguna contribución de la propuesta de jtoomim a la base de código de ABC, a lo que jtoomim contestó que el mismo en unos días se encargaría de hacerlo.

ABC utiliza un entorno llamado Phabricator que no es del gusto de todos los desarrolladores, por ejemplo BCHN usa el entorno que proporciona gist.

Jtoomim es un desarrollador independiente, no pertenece a ninguno de los equipos de desarrollo de clientes de nodo. Su criterio le llevó a concluir su propuesta (aportando código a una base de código) colaborando con el equipo de BCHN, suponiendo que ya que el código de BCHN y el de ABC a día de hoy son idénticos en muchos puntos su aportación a ABC sería un simple cortar y pegar. Pero no ha sido así.

Reconozco que en mi opinión si jtoomim hubiese optado por aportar y colaborar con ABC desde el principio no estaríamos en esta situación, ya que o bien ABC hubiese dado por buenas todas las propuestas de jtoomim o ambos hubiesen llegado a un acuerdo en los puntos donde apareciesen conflictos. Que no parezca que quiero criticar las preferencias y decisiones que haya tomado jtoomim, sino al contrario, agradecerle mucho su gran aportación y continuo compromiso con BCH.

ABC/Amaury dice que no recibió el código y el resto de acciones implicadas en su base de código, JToomim dice que está publicado y disponible para todo el que lo quiera revisar. Amaury opta por una nueva propuesta con cambios en la implementación.

Resultado: tenemos dos propuestas encima de la mesa y aparece la pregunta del título: ¿Dos propuestas es mejor que una?

Respuesta.

La primera impresión es que tener donde elegir es bueno. Nada que objetar a este razonamiento. Ahora bien, el problema no es elegir entre dos propuestas por sus meritos propios, sino que las implicaciones en un entorno enrarecido como es el actual si que es un problema.

Cada bando va a argumentar a favor de su propuesta y no necesariamente va a imperar el juego limpio y la colaboración.

Los bandos están claros, ABC/Amaury y todos los que estén a su favor frente al bando de todos los que estén en su contra. Parece muy dificil mantenerse neutral.

Lo único que facilitaría una postura de consenso sería las ventajas y bondades de una propuesta frente a la otra.

Comparación entre propuestas.

A pesar del caracter mucho más técnico, este punto lo considero muy relevante y he optado por incluirlo.

Ambas propuestas comparten el ideario desarrollado por Mark Lunderberg en su articulo.

Dos diferencias tienen que ver con la implementación elegida en cada propuesta.

• La propuesta de jtoomim aplica el algoritmo ASERT sobre el "target" de dificultad y la propuesta de Amaury aplica el mismo algoritmo sobre el trabajo realizado en los bloques minados.

• El algoritmo ASERT necesita computar una función exponencial y para que no haya diferencias en los resultados necesita hacerlo con una implementación basada en instrucciones con números enteros versus la mas precisa pero menos estándar de "coma flotante". La implementación de esta computación con enteros es diferente en cada propuesta.

Hay una tercera diferencia en la propuesta de Amaury que es un "fix" al desenfreno de emisión de monedas cometido en el pasado. Hasta ahora esto no había podido realizarse pero es precisamente la elección de ASERT la que lo posibilita. La propuesta de JToomim no recoje esta iniciativa y durante la reunión de desarrolladores solo Amaury la respaldaba.

Mis reflexiones.

Si una comparación entre las virtudes de ambas propuestas fuese posible en un entorno de juego limpio estaríamos en una muy buena situación que nos permitiría elegir la mejor opción. Desgraciadamente la situación dista mucho y veremos otro episodio de confrontación. Por suerte cualquiera de las dos opciones presenta tanta ventajas respecto a la situación actual que si gana cualquiera de ellas sin más todos saldremos ganando.

El próximo lunes 27 de Julio se celebrará la segunda reunión de desarrolladores monográfica sobre el algoritmo de ajuste de dificultad en BCH y se presenta muy pero que muy interesante, con muchas incógnitas sobre quienes asistirán a ella y que decisiones se van a tomar o no ante la proximidad del cierre establecido del 15 de Agosto.