Intermediário Aula 3 4 min de leitura

Como um endereço é construído, byte a byte

Chave pública, dois hashes, um byte de versão e um checksum. O endereço é o fim de uma receita curta que qualquer pessoa refaz e confere.

Um endereço de bitcoin parece código de sistema: uma sequência sem sentido que o aplicativo cospe e você copia com medo de errar. É o oposto disso. O endereço é o fim de uma receita curta, pública e conferível, e cada passo dela existe por um motivo que cabe numa frase.

O ponto de partida é a chave pública da aula anterior. Ela vai inteira para dentro da SHA-256, e o resultado dessa primeira passagem entra numa segunda função de hash, a RIPEMD-160 — publicada em 1996 por Hans Dobbertin e dois colegas do laboratório COSIC, em Leuven, na Bélgica. Ela devolve 160 bits, ou vinte bytes. O resultado dessa dupla tem nome: hash160.

Duas funções de famílias diferentes, em sequência, resolvem duas coisas ao mesmo tempo. Encurtam o endereço, porque vinte bytes ocupam bem menos que a chave pública. E deixam a chave pública escondida: o que você publica quando pede um pagamento não é ela, é o resumo dela. A chave só aparece no dia em que você gasta aquelas moedas.

A etiqueta aponta para o caixote sem carregar nada do que ele tem dentro.

Ao hash160 se acrescenta um byte na frente, o byte de versão. Zero para os endereços comuns, cinco para os que começam com 3. É esse byte que faz todo endereço de um tipo começar sempre pelo mesmo caractere — não é decoração, é o prefixo dizendo à carteira que receita ela deve aplicar do outro lado.

Depois vem o checksum. Pega-se versão mais hash160, aplica-se SHA-256 duas vezes, e os quatro primeiros bytes do resultado são colados no fim. São vinte e cinco bytes ao todo: um de versão, vinte de hash e quatro de conferência.

O último passo é a escrita. O número de vinte e cinco bytes é convertido para a base 58, um alfabeto que Satoshi montou tirando quatro letras do conjunto de sessenta e dois: o zero, o O maiúsculo, o i maiúsculo e o L minúsculo. O motivo está escrito no código-fonte original, em comentário: são exatamente os caracteres que se confundem quando alguém lê da tela ou copia à mão.

E é aí que o checksum trabalha. Trocando um caractere de um endereço, os quatro bytes do fim deixam de bater com o que a conta produz, e a carteira recusa antes de montar qualquer transação. A chance de um endereço digitado errado passar mesmo assim é de cerca de uma em quatro bilhões.

O erro é recusado antes de o dinheiro sair, não depois.

Os endereços que começam com bc1 seguem outra escrita, o bech32, proposta em 2017 pelo desenvolvedor belga Pieter Wuille. São todos em minúsculas, o que os faz caber em códigos QR bem menores, e o checksum deles é de uma família mais forte: além de detectar o erro, ele consegue apontar em que posição o erro está. Uma carteira moderna não diz apenas que o endereço está errado — ela sublinha o caractere.

O endereço novo não recusa apenas: ele mostra onde está o erro.

Vale ser exato sobre o que essa proteção toda não faz. O checksum confere a integridade do endereço, nunca a intenção de quem o escreveu. Um endereço de outra pessoa é um endereço perfeitamente válido, e o dinheiro enviado para ele chega, com todas as contas batendo. Existe malware que fica esperando um endereço aparecer na área de transferência para trocá-lo por outro no instante em que você cola. Contra isso o checksum não pode nada: só conferir os primeiros e os últimos caracteres com os olhos, como a trilha iniciante recomendou.

Repare no que essa receita não tem. Não tem cadastro, não tem servidor, não tem passo em que alguém precise dar permissão. São três funções de hash, um byte de versão e uma conversão de base — e qualquer pessoa com a chave pública nas mãos chega ao mesmo endereço que a sua carteira chegou, do mesmo jeito, sem perguntar nada a ninguém.

O endereço diz para onde o dinheiro vai. Falta a outra metade: a prova de que quem está mandando tem o direito de mandar, dada sem mostrar a chave a ninguém. Na próxima aula, as assinaturas digitais.