Bitcoin Core y otras implementaciones

Curiosidad

1. ¿Quién decide qué es un bloque cuando dos fragmentos de código están en desacuerdo?
2. ¿Por qué un pequeño error en la base de datos tiene el poder de dividir la cadena por la mitad?
3. ¿Qué sucede con la red si la implementación más popular deja de mantenerse?

Explorar

1. Bitcoin comenzó como un único cliente en C++ escrito por Satoshi Nakamoto. En 2011, la interfaz se reescribió utilizando bibliotecas Qt, y el software pasó a llamarse Bitcoin-Qt. Para 2014, la versión 0.9 ya no incluía ese sufijo y pasó a llamarse Bitcoin Core. Este cambio de nombre reflejó un cambio en su identidad: ya no era solo la herramienta de Satoshi, sino la implementación de referencia canónica para las reglas de la red.
2. El liderazgo del código pasó de Gavin Andresen, quien lo dirigió desde 2010 hasta que se retiró en 2014, a Wladimir van der Laan. Hoy en día, un pequeño grupo de mantenedores fusiona los cambios tras una rigurosa revisión por pares. El esquema de versionado pasó de 0.21 a 22.0 en 2021, lo que indica su madurez. Las versiones principales se lanzan aproximadamente dos veces al año, y cada una está sometida a pruebas exhaustivas antes de su distribución.
3. El consenso no se trata solo de la lógica; se trata de un comportamiento idéntico, byte por byte, en decenas de miles de nodos. En marzo de 2013, la versión 0.8 introdujo LevelDB como su motor de almacenamiento. Un bloque aceptado por el nuevo software fue rechazado por las versiones anteriores que utilizaban Berkeley DB debido a un error relacionado con los límites de bloqueo. La cadena se dividió hasta que los mineros realizaron una actualización inversa (downgrade), lo que demuestra que una diferencia oculta en el comportamiento, ni siquiera dentro del propio código del consenso, puede dividir la red.
4. Existen implementaciones alternativas para evitar que una única base de código se convierta en un punto de fallo o en objetivo de control. btcd está escrito en Go, bcoin en JavaScript y libbitcoin en C++. Bitcoin Knots, mantenido por Luke Dashjr, es un conjunto de parches sobre Core con configuraciones predeterminadas diferentes, notablemente un filtrado más estricto de las transacciones que transportan datos. Floresta utiliza la estructura de datos Utreexo para una verificación eficiente. Estos proyectos sirven como control sobre el proceso de desarrollo de Core.
5. El riesgo de volver a implementar el mecanismo de consenso es alto, ya que un error que permita la aceptación de bloques inválidos puede causar pérdidas financieras o divisiones en la cadena. Para mitigar esto, libbitcoinkernel tiene como objetivo aislar la lógica central de consenso en una biblioteca reutilizable. Esto permite que otros programas verifiquen transacciones sin tener que duplicar todo el código del nodo, lo que garantiza que las reglas permanezcan consistentes incluso cuando cambia la infraestructura circundante.
6. Ejecute 'bitcoin-cli getnetworkinfo' en un nodo para ver su propia versión, y 'getpeerinfo' para conocer el software que informa cada par (su cadena 'subver'). La red mantiene la interoperabilidad a pesar de utilizar diferentes stacks de software, pero el dominio de Bitcoin Core significa que, de facto, marca el ritmo para las actualizaciones del protocolo. Los nodos que no se actualizan siguen la cadena a través de soft forks, pero un nodo cuyo comportamiento en cuanto al consenso difiere puede separarse del resto.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• Bitcoin Core release notes for version 0.9.0 (2014)
• BIP50: March 2013 Chain Fork Post-Mortem
• Bitcoin Core release notes and documentation (bitcoincore.org)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 10