Bitcoin Development Philosophy

Uma proposta não precisa conter um erro de programação para enfraquecer o sistema. Pode facilitar o uso entregando parte da verificação a um serviço externo. O livro ajuda a identificar o que ganhamos nessa troca e em quem passamos a confiar. Os autores conectam explicações a debates históricos e contribuições de desenvolvedores experientes. Assim, o leitor aprende a avaliar os motivos de uma proposta, em vez de escolher um lado por causa de um nome conhecido. [2]

É preciso entender Proof of Work, o trabalho demonstrado na mineração, a formação dos blocos e o caminho de uma transação desde a transmissão até sua inclusão na cadeia. Depois vêm 9 capítulos principais: descentralização, Trustlessness, privacidade, oferta limitada, atualizações, Adversarial thinking, desenvolvimento aberto, escalabilidade e resposta a incidentes. Não é um primeiro guia de compra de bitcoin. Parte das bases para perguntar por que determinadas regras e práticas importam. [2] [1]

Trustlessness não significa nunca mais confiar em ninguém. Como explica Pieter Wuille, citado no capítulo, trata-se da capacidade do protocolo de funcionar sem um intermediário de confiança. Um Full Node, um nó que realiza validação completa, verifica por conta própria se um bloco recebido cria moedas não autorizadas ou gasta duas vezes a mesma quantia. Sem verificação própria, você entrega essa tarefa a outra pessoa. O nó, porém, ainda funciona sobre software e hardware concretos, que podem ter falhas. [3]

Imagine um pagamento registrado em um bloco depois substituído por outro ramo válido da cadeia. Essa mudança de histórico se chama reorganização e pode alterar o estado do pagamento. Com apoio em David Harding, o capítulo separa a verificação das regras da proteção contra esse risco. Mais confirmações indicam que novos blocos foram acrescentados após aquele bloco, tornando sua substituição geralmente mais difícil. Não prometem que seu nó impedirá toda reescrita do histórico. [3]

Antes de verificar pagamentos, surge outra pergunta: o programa baixado corresponde ao código-fonte publicado? Uma compilação reproduzível permite que pessoas diferentes produzam o mesmo arquivo a partir dos mesmos elementos. A comparação ajuda a conferir o programa distribuído. Mas o capítulo também retoma Carl Dong: a origem das ferramentas usadas para construí-lo importa. Arquivos iguais não provam que o código, o compilador ou o computador estejam livres de falhas. [3]

Adversarial thinking é examinar uma proposta pela perspectiva de um adversário. A pergunta não é só se funciona com participantes honestos, mas o que um atacante poderia ganhar explorando-a. O capítulo recorre a Andrew Poelstra e Jameson Lopp para discutir pressupostos de segurança. Exemplos incluem isolar um nó da rede honesta e atrapalhar deliberadamente a colaboração aberta. O funcionamento observado até agora não é, sozinho, uma prova formal da segurança do sistema inteiro. [4]

O axioma de resistência de Eric Voskuil, citado no texto, parte do pressuposto de que um sistema pode resistir ao controle estatal. Axioma significa aqui um ponto de partida para o raciocínio, não o resultado de um teste que demonstre a invulnerabilidade do Bitcoin. A diferença também importa ao leitor comum: buscar uma solução resistente faz sentido, mas não significa que toda solução criada resistirá a tudo. O livro incentiva a localizar esses pressupostos e reduzir pontos cegos. [4]

Para cada afirmação, pergunte o que foi verificado, o que continua pressuposto e qual conveniência o usuário ganha com a mudança. Os autores indicam artigos e palestras; guardam cópias dos artigos, com sua origem, em uma coleção separada no repositório. Este panorama parte da introdução completa e dos textos integrais de Trustlessness e Adversarial thinking. Os demais capítulos são descritos pelo sumário. Não é uma resenha do livro inteiro e de todos os seus links, nem uma auditoria de segurança realizada. [2] [3] [4]