Jeff Garzik é um programador conhecido pela conta jgarzik. Trabalhou em software Bitcoin e em BIP, documentos que descrevem alterações ou procedimentos concretos. O seu contributo mostra como o Bitcoin evolui: um autor pode escrever código e propor uma regra, mas não ordenar a toda a rede que a aceite.
No GitHub, Jeff Garzik usa o nome jgarzik. O seu trabalho pode ser consultado em repositórios específicos, espaços públicos que guardam código e o histórico das suas alterações. Isso é mais útil do que atribuir a uma pessoa a função vaga de «dirigir o Bitcoin». Num programa, interessa perceber o que faz e qual é a versão; numa proposta, o que pretendia mudar. Um perfil de programador não decide, por si só, que versão do software as outras pessoas executam. [1]
O README, ficheiro de apresentação do cpuminer de Garzik, descreve-o como um programa de mineração de Bitcoin através da CPU, o processador do computador. O funcionamento com várias threads permite repartir os cálculos entre linhas de execução simultâneas. O projeto pooler/cpuminer, para Litecoin e Bitcoin, identifica expressamente essa origem. Aproveitar código existente e desenvolvê-lo separadamente chama-se criar um fork do projeto. Isso não divide, por si só, a rede Bitcoin, e as funcionalidades acrescentadas depois podem não ter existido no original de Garzik. [2] [3]
Picocoin é outro exemplo. Inclui libccoin, uma biblioteca na linguagem C cujas funções os programadores podem usar para construir aplicações Bitcoin. Contudo, o README marca a carteira HD e o nó brd associados como WIP, ou seja, trabalho em curso. Uma carteira HD deriva uma família de chaves de uma base comum; o nó destina-se a comunicar com a rede Bitcoin. O repositório foi arquivado em 15 de fevereiro de 2024. É uma fonte histórica útil, mas a disponibilidade do código não prova que seja um produto acabado, mantido e seguro para guardar poupanças. [4]
Imagine um nó que quer saber que transações não confirmadas conhece outro nó ao qual está ligado. O BIP 35 de Garzik trata dessa tarefa: a mensagem mempool pede uma lista, a resposta inv contém os identificadores das transações, os seus hashes, e getdata permite depois pedir os dados completos. O mempool é uma «sala de espera» local antes da confirmação, não uma lista única para o mundo inteiro. O comando getrawmempool documentado pelo Bitcoin Core também devolve o conteúdo de um nó específico. Encontrar aí uma transação não significa que esteja confirmada num bloco. [5] [8]
O tamanho dos blocos afeta o espaço para transações e os recursos necessários para as transmitir e verificar. No BIP 100, Garzik, Tom Harding e Dagur Valberg Johannsson propuseram ajustar o limite através de votos registados pelos mineradores nos blocos. O cálculo seria feito a cada 2016 blocos, exigindo 75% de apoio nos blocos e limitando a dimensão de cada alteração. Não era, portanto, uma votação por número de pessoas. O registo marca a proposta como Closed, encerrada; a descrição não prova que toda a rede Bitcoin tenha adotado o mecanismo. [6]
Considere um nó comum que continua a verificar o limite inicial de 1 MB. Se receber um bloco maior, rejeita-o, mesmo que o minerador que o produziu apoie um limite superior. O BIP 100 avisa precisamente dessa separação. Um voto num bloco é um dado que o novo software pode interpretar, não uma ordem que reescreve um programa antigo. Uma alteração que permite blocos rejeitados pelas regras anteriores é um Hard Fork. Este sentido de fork difere da simples criação de um projeto derivado no GitHub. [6]
O BIP 102 de Garzik propunha outro caminho: aumentar o limite uma única vez para 2 MB. A ativação exigiria simultaneamente uma condição temporal e apoio sinalizado em 95% dos últimos 1000 blocos. Cumprir essas condições não adaptaria, por si só, os programas validadores antigos, que continuariam a rejeitar blocos maiores. Esta proposta também tem o estado Closed. Documenta uma mudança proposta; não explica as regras de tamanho de bloco que o Bitcoin aplica hoje. [7]
Em cada BIP, é importante ler o conteúdo e o estado. O BIP 35 aparece como Deployed, implementado, na camada Peer Services, dedicada a serviços e comunicação entre nós. Os BIP 100 e BIP 102 são Closed na camada Consensus (hard fork), porque tratam dos blocos que os nós reconhecem como válidos. O mesmo autor pode trabalhar nas duas áreas com resultados diferentes. A introdução bem-sucedida de uma mensagem de rede não significa que todas as suas propostas de mudança das regras tenham sido implementadas. [5] [6] [7]
Para ter uma visão mais completa, leia este verbete junto com Cynthia Lummis, Mike Hearn, Guerra do tamanho dos blocos. Também há referências a este verbete em Mike Hearn.