Jeff Garzik es un desarrollador conocido por la cuenta jgarzik. Trabajó en software de Bitcoin y en BIP, documentos que describen cambios o procedimientos concretos. Sus aportaciones muestran cómo evoluciona Bitcoin: alguien puede escribir código y proponer una regla, pero no ordenar a toda la red que la acepte.
En GitHub, Jeff Garzik utiliza el nombre jgarzik. Su trabajo se puede explorar en repositorios concretos, espacios públicos que guardan código y su historial. Es más útil que atribuir a una persona el papel impreciso de «dirigir Bitcoin». De un programa interesa saber qué hace y qué versión estamos viendo; de una propuesta, qué pretendía cambiar. Un perfil de desarrollador no decide por sí solo qué versión del software ejecutan los demás. [1]
El README de cpuminer, el archivo que presenta el proyecto, lo describe como un programa de minería de Bitcoin mediante CPU, el procesador del ordenador. El funcionamiento multihilo permite repartir el trabajo de cálculo entre varios hilos que se ejecutan de forma concurrente. pooler/cpuminer, para Litecoin y Bitcoin, declara expresamente que procede de ese programa. Tomar código existente y desarrollarlo por separado se llama hacer un fork del proyecto. Esto no divide por sí solo la red Bitcoin; tampoco significa que las funciones añadidas después ya existieran en el original de Garzik. [2] [3]
Picocoin ofrece otro ejemplo. Incluye libccoin, una biblioteca escrita en C cuyas funciones pueden utilizarse para construir aplicaciones de Bitcoin. Sin embargo, su README marca la billetera HD y el nodo brd asociados como WIP, es decir, trabajo en curso. Una billetera HD deriva una familia de claves de un origen común; el nodo está pensado para comunicarse con la red Bitcoin. El repositorio fue archivado el 15 de febrero de 2024. Sirve para estudiar la historia, pero disponer del código no demuestra que sea un producto terminado, mantenido y seguro para guardar ahorros. [4]
Imaginemos un nodo que quiere averiguar qué transacciones sin confirmar conoce otro nodo conectado. El BIP 35 de Garzik aborda esa tarea: el mensaje mempool pide una lista, la respuesta inv contiene los identificadores de las transacciones, sus hashes, y getdata permite solicitar después los datos completos. El mempool es una «sala de espera» local antes de la confirmación, no una lista única para todo el mundo. El comando getrawmempool documentado por Bitcoin Core también devuelve el contenido de un nodo concreto; encontrar una transacción allí no significa que esté confirmada en un bloque. [5] [8]
El tamaño de los bloques afecta al espacio para transacciones y a los recursos necesarios para transmitirlas y verificarlas. En BIP 100, Garzik, Tom Harding y Dagur Valberg Johannsson propusieron ajustar el límite mediante votos que los mineros registrarían en los bloques. Se recalcularía cada 2016 bloques, con un requisito del 75% de apoyo en los bloques y cambios de magnitud limitada. No era una votación por número de personas. El registro marca la propuesta como Closed, cerrada; su descripción no demuestra que toda la red Bitcoin adoptara ese mecanismo. [6]
Pensemos en un nodo que sigue comprobando el límite original de 1 MB. Si recibe un bloque mayor, lo rechaza aunque el minero que lo produjo apoye un límite más alto. BIP 100 advierte precisamente de esa separación. Un voto escrito en un bloque es un dato que un programa nuevo puede interpretar, no una orden que reescribe uno antiguo. Permitir bloques que las reglas anteriores rechazan constituye un Hard Fork. Este significado de fork es distinto de crear un proyecto derivado en GitHub. [6]
El BIP 102 de Garzik proponía otra vía: elevar el límite una sola vez, a 2 MB. La activación requeriría tanto una condición temporal como apoyo señalado en el 95% de los últimos 1000 bloques. Cumplir ambas condiciones no modificaría por sí solo los programas validadores antiguos, que seguirían rechazando bloques mayores. Esta propuesta también está marcada Closed. Documenta un cambio propuesto; no es una guía de las reglas de tamaño de bloque que Bitcoin utiliza hoy. [7]
En cada BIP conviene leer el contenido y el estado. BIP 35 figura como Deployed, desplegado, en la capa Peer Services, dedicada a los servicios y la comunicación entre nodos. BIP 100 y BIP 102 aparecen como Closed en Consensus (hard fork), porque tratan sobre qué bloques se consideran válidos. Un mismo autor puede trabajar en ambas áreas y obtener resultados distintos. Introducir con éxito un mensaje de red no significa que también se hayan implantado todos sus cambios de reglas. [5] [6] [7]
Para obtener la imagen más completa, lee esta entrada junto con Cynthia Lummis, Mike Hearn, Guerra del tamaño de bloque. También enlazan con esta entrada Mike Hearn.