Gavin Andresen

O software não se mantém sozinho quando o criador de um projeto se afasta. Alguém precisa coordenar correções, testes e novas versões. Gavin Andresen assumiu essa responsabilidade depois de Satoshi nos primeiros anos do Bitcoin. O perfil do MIT para um encontro em 17 de novembro de 2015 descreve esse histórico e já aponta Wladimir van der Laan como mantenedor principal. É uma função no desenvolvimento, não a propriedade da rede. Uma biografia antiga também não comprova acesso atual ao repositório, o local compartilhado onde fica o código-fonte. [1]

Um iniciante pode entender dinheiro digital, mas sem moedas é difícil testar o recebimento e o envio. Andresen enfrentou essa barreira com o Bitcoin Faucet. Anunciado em 11 de junho de 2010, o serviço começou com 1.100 BTC e oferecia cinco moedas para experimentar. O visitante não precisava esperar para minerá-las nem encontrar um vendedor. O faucet distribuía recursos existentes; não criava novos bitcoins nem uma recompensa de bloco. O objetivo era facilitar a primeira experiência, não mudar as regras de emissão do dinheiro. [2]

Em uma resposta de 11 de junho de 2010, Andresen esclareceu o limite: cinco moedas por endereço IP, não por dia. Um endereço IP identifica uma conexão em uma rede de computadores; não é um endereço de carteira bitcoin nem uma lista confiável de pessoas. Proteger o serviço, portanto, não equivalia a verificar identidades. Um CAPTCHA, tarefa que ajuda a distinguir uma pessoa de um programa automático, era considerado como possível medida adicional. É importante separar esse funcionamento inicial de mudanças posteriores, sem reconstruir a história a partir dos serviços atuais. [2]

Outra contribuição tratou de um problema prático diferente. O destinatário pode exigir várias assinaturas antes de permitir gastar o dinheiro. O remetente deve lidar com toda essa regra em cada pagamento? BIP 16, de 2012, descreve Pay to Script Hash: o pagamento aponta para um hash, uma impressão digital curta do script que contém as condições. Um BIP é uma proposta numerada de melhoria do Bitcoin. O próprio script, chamado aqui de redeemScript, é apresentado por quem gasta os fundos. As condições continuam valendo; mudam o momento e a responsabilidade de apresentá-las. [3]

Imagine um caixa que só pode ser aberto com a aprovação de várias pessoas. Mostrar suas regras não libera o dinheiro. Da mesma forma, BIP 16 de 2012 exige verificar o hash do redeemScript apresentado e depois executar suas condições. Conhecer o script não substitui as assinaturas necessárias. Também existe um limite técnico de 520 bytes para esse script; byte é uma medida do tamanho dos dados. O principal para o iniciante é distinguir duas verificações: apresentar a regra correta e ter aquilo que ela exige. [3]

Em 2015, Andresen apresentou BIP 101 para aumentar gradualmente o tamanho máximo do bloco. O documento descreve um Hard Fork: uma mudança em que regras antigas rejeitariam alguns blocos permitidos pelas novas. O registro classifica a proposta como Closed, ou encerrada. Já BIP 16 aparece como Deployed, implantado. Assim, um número de BIP ou um autor conhecido não comprova ativação. Ao ler uma proposta, é preciso verificar também se suas regras chegaram a ser usadas. [4] [3]

Por que aumentar blocos gerou debate? Um bloco maior pode conter mais transações, mas seus dados precisam ser transmitidos, recebidos e verificados. BIP 101 de 2015 discute, por isso, custos de transmissão e o risco de favorecer grandes operadores. Quem tem uma conexão lenta pode enfrentar condições diferentes de uma grande mineradora. A expectativa do autor sobre o progresso tecnológico é um argumento a favor da proposta, não um resultado medido para todo cenário futuro. A questão é equilibrar capacidade e possibilidade de verificar a rede de maneira independente. [4]

Bitcoin.org explica que desenvolvedores não podem impor mudanças nas regras: as pessoas escolhem o software que executam. Para funcionarem juntos, os participantes precisam manter regras compatíveis. Andresen podia escrever propostas, preparar código e convencer os demais, mas não alterar unilateralmente o Bitcoin para todos. Seu trabalho deve ser avaliado contribuição por contribuição: o que um serviço permitia, o que o código fazia e o que a rede adotou. Realizações anteriores não tornam automaticamente correta toda afirmação posterior. [5]