@DarthRoison 20 February 2020

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

**Traducción del** **artículo en inglés** **publicado por** **ZakMcRofl** https://read.cash/@ZakMcRofl/fork-bitcoin-abc-now-a-developers-analysis-2c476e00 *****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%** . https://www.bitcoinabc.org/2020-02-15-miner-fund/ https://github.com/Bitcoin-ABC/bitcoin-abc/commit/b46180893ed61fdc13fa5f95a5a7292c003e1a57#diff-64cbe1ad5465e13bc59ee8bb6f3de2e7R114 https://www.reddit.com/r/btc/comments/f4mkge/as_it_stands_now_bitcoincom_will_not_go_through/fhrvtl4/ *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í**) https://read.cash/@jonald_fyookball/latest-thoughts-on-infrastructure-mining-plan-681269b7#comment-64634b6f BCHD (su desarrollador principal Chris Pacia **esperaba que la propuesta requiriera el 95% del consenso según BIP-9, no el 66%** ) https://www.reddit.com/r/btc/comments/f4mkge/as_it_stands_now_bitcoincom_will_not_go_through/fhrvtl4/ 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í** . https://github.com/Bitcoin-ABC/bitcoin-abc/commit/b46180893ed61fdc13fa5f95a5a7292c003e1a57#diff-5c20e210ed453866a3bf7cca3c5e792eR20 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 https://read.cash/@ZakMcRofl/fork-bitcoin-abc-now-a-developers-analysis-2c476e00#misleading-parameter-name 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 https://read.cash/@ZakMcRofl/fork-bitcoin-abc-now-a-developers-analysis-2c476e00#hiding-the-parameter 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 https://read.cash/@ZakMcRofl/fork-bitcoin-abc-now-a-developers-analysis-2c476e00#omission-of-the-parameter-from-documentation 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"** . https://github.com/Bitcoin-ABC/bitcoin-abc/commit/a64244c3a72749351ddb9f0b825fb9fb18c028aa#diff-3da6427abdeef1f0d6761fe5374f8a90 https://github.com/Bitcoin-ABC/bitcoin-abc/commit/db8ac1be82e340c499c520aca3ad34cbf1edd2da#diff-9e9f66b5b2833c022b0408b81a17cfd9R191 *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 https://read.cash/@ZakMcRofl/fork-bitcoin-abc-now-a-developers-analysis-2c476e00#automatic-consensus 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í** . https://github.com/Bitcoin-ABC/bitcoin-abc/commit/b46180893ed61fdc13fa5f95a5a7292c003e1a57#diff-64cbe1ad5465e13bc59ee8bb6f3de2e7R151 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 https://read.cash/@ZakMcRofl/fork-bitcoin-abc-now-a-developers-analysis-2c476e00#conclusion 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.