Bitcoin Whitepaper

Um whitepaper apresenta um problema e propõe uma solução. O do Bitcoin começa com uma pergunta quotidiana: quando envio dinheiro pela Internet, tem de existir sempre um banco ou outro gestor entre nós? Satoshi enviou a proposta a uma lista de correio sobre criptografia em 31 de outubro de 2008 e incluiu uma ligação para o texto. Não prometia um preço do bitcoin nem uma rentabilidade. Explicava como receber pagamentos sem entregar a uma única empresa as decisões sobre o seu histórico. Esse problema liga todo o documento. [2] [1]

Imagine um remetente a assinar dois pagamentos diferentes que gastam o mesmo dinheiro. Um destinatário vê o primeiro; outro vê o segundo. Ambos podem verificar uma assinatura digital válida, ou seja, uma prova de autorização, mas os dois não podem receber. Copiar dados na Internet é fácil; uma assinatura, por si só, não resolve isso. A secção 2 distingue portanto a autorização para gastar da questão de qual pagamento pertence ao histórico comum. O Bitcoin acrescenta às assinaturas um registo público que permite reconhecer fundos já gastos. [1]

As secções 3–5 agrupam pagamentos em blocos. Cada novo bloco aponta para o anterior através de um hash, uma curta impressão digital dos dados. Alterar um registo antigo mudaria essa impressão e quebraria as ligações. Proof of Work acrescenta cálculo dispendioso: produzir um bloco aceitável exige muitas tentativas, mas verificar o resultado é fácil. Entre ramos concorrentes conta o trabalho acumulado num histórico que respeita as regras, não o número de contas ou endereços IP criados. O texto chama-lhe a cadeia mais longa. Mesmo muito trabalho não torna válida uma transação inválida. A cadeia também ordena acontecimentos, sem fornecer a hora exata de cada pagamento. [1] [3]

Computadores e eletricidade têm custos. A secção 6 acrescenta um incentivo económico: o criador de um bloco aceite pode receber moedas recém-emitidas e taxas dos pagamentos incluídos. A taxa é a diferença entre o valor consumido pela transação e o das novas saídas. Não são moedas adicionais criadas do nada. O texto considera um futuro em que só as taxas financiam a recompensa. Mas importa saber onde termina a proposta: o whitepaper não indica o limite exato de 21 milhões nem a redução para metade a cada 210.000 blocos. Essas regras exigem outras referências sobre Bitcoin. [1] [3]

Nem todos querem descarregar e verificar todas as transações. A secção 8 propõe SPV, a verificação simplificada de pagamentos. O cliente obtém cabeçalhos com os dados essenciais dos blocos e uma prova de Merkle: uma ligação de hashes que demonstra a inclusão de uma transação num bloco. É a diferença entre confirmar que um registo consta de um livro e verificar a correção do livro inteiro. A inclusão não verifica por si só todas as regras nem todo o histórico de gastos. O whitepaper reconhece a limitação: o cliente simplificado é mais vulnerável a certos ataques do que um Full Node que verifica as transações por si. [1]

Na banca, grande parte do registo de pagamentos não é pública. O Bitcoin precisa de um histórico partilhado e deve proteger a privacidade de outra forma. A secção 10 explica a separação entre pagamentos e identidades dos detentores de chaves e recomenda novos pares de chaves para outras transações. Também reconhece uma fragilidade: os pagamentos podem ser associados. Identificar uma pessoa num registo pode revelar outros pagamentos seus. Um endereço novo não é portanto um disfarce mágico. Limita algumas ligações, mas não apaga sozinho a informação pública nem aquilo que a contraparte sabe. [1]

A secção 11 pergunta qual a probabilidade de um atacante alcançar a cadeia criada pelos participantes honestos. Imagine uma corrida: um lado tem vantagem, mas ambos continuam a trabalhar. No modelo descrito, quanto menor a parcela de poder computacional do atacante e maior a vantagem, menor a hipótese de recuperação. O cálculo usa pressupostos e uma aproximação de Poisson, simplificação matemática para estimar quantos acontecimentos ocorrem num período. Não prevê todos os ataques reais. Um número retirado da tabela não é, por isso, uma quantidade segura de confirmações para qualquer pagamento. [1]

O documento explica o projeto original. A rede e o software evoluíram; o SegWit, por exemplo, descrito na proposta BIP 141, não aparece. Um BIP documenta uma proposta de melhoria, não uma decisão que se transforma automaticamente numa regra da rede ao ser publicada. Para compreender questões atuais, é preciso distinguir proposta, programa, regras comuns realmente aplicadas e decisões locais de um nó sobre retransmissão. Um nó pode não retransmitir uma transação e mais tarde aceitá-la num bloco válido. Estas situações não são contraditórias. [4] [3]

Comece pelo resumo e pela questão de impedir gastos duplos sem gestor. Depois siga o contributo das assinaturas, do histórico comum e do trabalho necessário para criar blocos. Se a matemática o travar, não precisa de entender imediatamente cada fórmula: primeiro perceba que ataque o cálculo modela e em que pressupostos assenta. Pode regressar aos detalhes mais tarde. O e-mail original documenta quando Satoshi apresentou a proposta; o PDF contém a argumentação. Uma frase isolada não prova que uma carteira ou um serviço concreto tenha de ser seguro. [2] [1]

O essencial não é memorizar os títulos das secções, mas perceber por que nenhuma peça basta sozinha: a assinatura comprova autorização, o histórico público ajuda a detetar gastos duplos e Proof of Work dificulta reescrever a ordem. As peças tinham antecedentes que Satoshi cita nas referências. O contributo está na sua ligação. O whitepaper continua a ser uma boa introdução ao raciocínio do Bitcoin quando lido como uma proposta fundamentada com pressupostos concretos. Não é uma tabela de preços, um guia de investimento nem a especificação completa de todas as regras e ferramentas hoje associadas ao nome Bitcoin. [1]