Bifurca a «Bitcoin ABC» ahora: Análisis de un desarrollador

Traducción del artículo en inglés publicado por ZakMcRofl

Descargo de responsabilidad: este artículo pide una modificación no oficial del software de Bitcoin ABC, creando una "bifurcación" del cliente. Si todo marcha bien, esto no implicaría una división de red, lo cual deberíamos evitar a toda costa.

Hoy, Bitcoin ABC lanzó su versión 0.21, la cual incluye soporte para el Plan de Financiamiento de Infraestructura tal y como lo concibe Amaury Séchet. Esto obliga a los mineros a ceder el 5% de todas las recompensas y tarifas a proyectos seleccionados personalmente por Amaury (incluyendo el suyo propio) o a un "Fondo general" desconocido (presumiblemente una compañía basada en Hong Kong).

Se han escrito muchos artículos sobre por qué esto es una mala idea. Hoy quiero resaltar la forma engañosa en la que esto se implementó. Si bien Amaury afirma que solo estaba implementando los deseos de un minero desconocido, existen varias preocupaciones sobre la forma elegida para su implementación:

Sin límite de tiempo

Nada en la implementación establece un límite de tiempo al período de financiación para el IFP. El mismo es ilimitado hasta que Amaury decida lanzar una nueva versión que lo desactive y, por lo tanto, deje de aplicarse.

Un desarrollador honesto codificaría un final automático para el IFP, aunque fuese para aclarar la intención de eliminación en la próxima versión.

Umbral BIP-9 modificado

El artículo publicado por ABC , presumiblemente acordado con BCHD,  enumera el estándar BIP-9 como el método para tomar la decisión. BIP-9 es un método de consenso que especifica un umbral en torno al 95% para evitar una división de la cadena en caso de tratarse de algo contencioso. Sin embargo, en la implementación se ha implementado un umbral inferior (66%). Es obvio cuán engañoso es esto. Incluso Chris Pacia, el desarrollador principal de BCHD, un proyecto que aparece en la lista blanca, presumiblemente involucrado en la planificación, se sorprendió al saber que la implementación solo requiere un acuerdo del 66% en lugar del 95% .

Un desarrollador honesto se apegaría a la especificación de una propuesta bien pensada para averiguar si hay suficiente acuerdo para una propuesta para evitar una división de la cadena.

Lista blanca codificada

ABC ha decidido unilateralmente que direcciones de destino pueden beneficiarse:

• La suya (¿alguien sabe qué individuos tienen el control final sobre esta y cómo se dividirán los fondos entre los desarrolladores de ABC?)

• Electron Cash (a pesar de que su desarrollador principal, Jonald Fyookball, retiró su apoyo al IFP y solicitó su eliminación de la lista blanca aquí)

• BCHD (su desarrollador principal Chris Pacia esperaba que la propuesta requiriera el 95% del consenso según BIP-9, no el 66% )

• Un "Fondo General" - una entidad desconocida, no monitoreada ni transparente, presumiblemente una compañía de Hong Kong con una estructura de accionistas, gestión, reglas e intenciones desconocidas.

El código fuente correspondiente está aquí .

Cabe destacar que otros valiosos proyectos de código abierto como Bitcoin Unlimited, Bitcoin Verde, la wallet de Bitcoin.com, y muchos otros, han sido omitidos de esta lista. No hay forma de incluirlos a menos que Amaury lo decida.

Un desarrollador no malicioso no codificaría su propia dirección de billetera de esta manera. Un desarrollador honesto buscaría primero el consenso en la lista y luego lo implementaría de manera que otras implementaciones puedan acceder fácilmente y actualizarlo para incluir nuevos proyectos. Un desarrollador no malicioso no agregaría ninguna entrada a esta lista que no sea revisada por la comunidad (Fondo General).

Nombre de parámetro engañoso

Introdujeron un nuevo parámetro llamado "enableminerfund". Este nombre es muy engañoso porque este parámetro no es necesario para habilitar el fondo minero. De omitirse, el fondo aún se activa, y los bloques que no paguen se ignoran después de que la activación mediante la variante de BIP-9. Es necesario interactuar con bitcoind usando "-enableminerfund 0" para poder aceptar bloques sin impuesto (después de la activación mediante la variante de BIP-9).

Parámetro oculto

A diferencia de la mayoría de los otros parámetros, el parámetro se agregó como un parámetro oculto. Es decir, no aparecerá si interactua con bitcoind usando el comando "--help" y no hay forma de encontrarlo si no inspecciona el código fuente.

Un desarrollador honesto no elegiría ocultar una característica tan contenciosa.

Omisión del parámetro en la documentación

El nuevo parámetro "enableminerfund" no se incluyó en la actualización de la documentación . Esto podría ser un descuido, pero es más probable que sea intencional porque las actualizaciones anteriores incluyeron nuevos parámetros en las páginas del manual, ver, por ejemplo, la adición de "-enablebip61" .

Un desarrollador honesto reconocería la controversia en torno a esta característica, agregaría el parámetro a la documentación y destacaría claramente su importancia en las notas de la versión.

Consenso automático

Incluso si revisa el código fuente, encuentra el parámetro y lo configura correctamente, su nodo de minería ABC aún NO votará en contra del IFP. El consenso con el IFP está codificado, como puede ver aquí .

NO hay forma de configurar ABC para votar en contra del IFP a menos que cambie el código fuente y compile una versión bifurcada. Si suficientes mineros ejecutan una versión no modificada de Bitcoin ABC 0.21, el consenso mediante la variante de BIP-9 (66% de los bloques con cualquier distribución durante 14 días) se garantizará mucho antes de la actualización de mayo.

Un desarrollador honesto daría al usuario una forma de participar de esta decisión.

Conclusión

En conclusión, la forma en que esto se implementó constituye un ataque malicioso y deshonesto contra Bitcoin Cash. Si queremos detener el IFP, tenemos que:

• Hacer una bifurcación de código de Bitcoin ABC para crear una versión que ponga la decisión con respecto a IFP en manos del usuario.

• Desarrollar una forma fácil para que los mineros puedan actualizar de la versión corrupta a la versión limpia del proyecto.

• Publicar esos parches y concientizar sobre su necesariedad.

Una bifurcación más agresiva incluiría un voto codificado contra del IFP y la eliminación del código malicioso. Sin embargo, me temo que esto podría generar críticas similares al enfoque de Amaury y conllevar el riesgo de que la versión bifurcada no siga la cadena "correcta" en caso de que el ataque tenga éxito. Un último recurso sería un hard fork, pero todos deberíamos esforzarnos por evitarlo.

Ediciones

12-feb-2020: Se corrigió la presunción incorrecta sobre la participación de los desarrolladores de BCHD en la planificación de esta implementación.