Bitcoin: A Work in Progress

Você pode usar Bitcoin sem conhecer seu código. Isso não significa que não exista mais nada a melhorar. Sjors Provoost, colaborador do Bitcoin Core, aproxima o leitor do trabalho que permite à rede evoluir. A primeira edição impressa saiu pela Purple Dunes em 2022. O livro trata de questões técnicas de sua época; uma revisão posterior dos arquivos-fonte não muda a data da publicação inicial. [1] [2]

Imagine que um amigo envia um endereço e você o cola na carteira. Para você, começa um pagamento. Para quem desenvolve o programa, também há a questão de detectar um erro de digitação e indicar sem ambiguidade o destino do pagamento. Esse exemplo que criamos oferece uma entrada no livro sem exigir programação. O conteúdo vai dos endereços à comunicação entre nós e às mudanças de regras. Os capítulos mais difíceis fazem mais sentido depois dessas bases. [2]

O endereço é uma representação a partir da qual a carteira monta as condições para gastar determinada quantia no futuro. Essas condições ficam em uma saída de transação, uma parte recém-criada do pagamento. Para gastá-la depois, é necessário comprovar que as condições foram atendidas, geralmente por meio de uma assinatura digital válida. Assim, a rede não precisa manter uma conta bancária em seu nome. O capítulo de Provoost diferencia o endereço trocado entre pessoas das regras verificadas pelos computadores. [3]

O endereço inclui uma soma de verificação que ajuda a carteira a detectar erros de cópia. Ela não identifica quem é o dono do endereço. Em nosso exemplo, você poderia colar por engano um endereço de outra pessoa, corretamente escrito, e passar pela verificação. Por isso, também é preciso conferir o destinatário pretendido. Se a carteira apontar um erro, obter novamente o endereço correto é mais seguro do que tentar adivinhar qual caractere corrigir. [3] [4]

Agora um detalhe técnico: Bech32 e Bech32m são formatos de codificação de endereços. O BIP 350 determina Bech32 para endereços nativos com witness versão 0 e Bech32m para as versões de 1 a 16. A versão witness é um número que diferencia as regras de validação desse tipo de saída. O formato mais novo resolve uma fragilidade da soma de verificação relacionada à inserção de caracteres. Isso não invalida todos os endereços antigos nem significa que devam ser convertidos manualmente. [4]

Um nó é um programa conectado à rede Bitcoin; um Full Node verifica por conta própria as regras de transações e blocos. Mas precisa receber novos dados de algum lugar. Em um Eclipse Attack, o invasor controla todas as conexões do nó e pode ocultar parte do que acontece na rede. O nó continua rejeitando blocos inválidos, mas tem informações incompletas. O livro destaca uma diferença importante: validar os dados recebidos não equivale a ter acesso a todos os dados necessários. [5]

O invasor não pode simplesmente impor um bloco qualquer ao nó isolado. Para apresentar uma confirmação válida de seu pagamento, precisa também de um bloco válido que cumpra Proof of Work, a prova computacional de trabalho exigida. Ao se reconectar, o nó pode descobrir outro ramo válido com mais trabalho acumulado. Ele muda para esse ramo; se o pagamento original não estiver ali, a confirmação anterior deixa de valer. A segurança, portanto, envolve validar regras e manter conexões resistentes a ataques. [5]

Comece por uma pergunta familiar, como a do endereço. Depois acompanhe o que a solução permite e onde estão seus limites. Este panorama usa os créditos da edição, o sumário oficial, trechos públicos selecionados sobre endereços e Eclipse Attack, além do BIP 350. Não é uma resenha do livro inteiro nem do podcast que lhe deu origem. Os números históricos da rede e o estágio de desenvolvimento daquela época devem ser distinguidos do software atual. [1] [2] [3] [4] [5]