Endereços e codificações: Base58Check, Bech32, Bech32m

Curiosidade

1. Por que uma única alteração em um endereço quase sempre o torna inválido, mas alguns erros de digitação conseguem passar despercebidos?
2. Como uma sequência de letras e números pode funcionar como um mapa para um script de bloqueio específico sem armazenar esse script na cadeia?
3. O que o Bech32 pode garantir sobre erros de digitação que o Base58Check só consegue tornar improváveis?

Explorar

1. Um endereço não é um objeto armazenado no conjunto UTXO; é uma codificação amigável para humanos de um script de saída. A cadeia armazena apenas bytes, mas o software os traduz em strings para que os humanos possam lê-los e digitá-los. Essa camada de tradução deve evitar erros de transcrição, pois um endereço digitado incorretamente, mas que ainda parece válido, pode enviar fundos para o lugar errado. O design original de Satoshi, Base58Check, resolveu esse problema usando um alfabeto de 58 caracteres que omite os caracteres visualmente ambíguos ‘0’, ‘O’, ‘I’ e ‘l’.
2. O Base58Check codifica um byte de versão, o payload (como um hash de 20 bytes) e uma soma de verificação de quatro bytes. A soma de verificação é obtida a partir dos primeiros quatro bytes do hash duplo SHA-256 dos dados anteriores. Os endereços legados Pay-to-Public-Key-Hash (P2PKH) utilizam o byte de versão 0x00, resultando em strings que começam com ‘1’. O Pay-to-Script-Hash (P2SH) usa o byte de versão 0x05, gerando strings que começam com ‘3’. Essa estrutura permite que as carteiras verifiquem a integridade antes de aceitar um endereço.
3. Segregated Witness (SegWit), ativado em agosto de 2017 no bloco 481.824, introduziu saídas nativas de “witness” que exigiam uma nova codificação. O Base58Check não era adequado para as estruturas de dados mais longas e os padrões de erro específicos do SegWit. Pieter Wuille e Greg Maxwell propuseram o Bech32 no BIP-173 (2017). Ele utiliza um conjunto de caracteres restrito com 32 caracteres – dígitos e letras minúsculas, excluindo ‘1’, ‘b’, ‘i’ e ‘o’, sendo que ‘1’ é reservado como separador. O uso de apenas letras minúsculas evita ambiguidades e se adapta aos códigos QR.
4. Os endereços Bech32 começam com a parte legível por humanos “bc” e o separador “1”, seguidos de dados e um checksum de seis caracteres. Esse checksum é baseado em códigos Bose-Chaudhuri-Hocquenghem (BCH), que são significativamente mais robustos do que o checksum derivado de SHA-256 usado no Base58Check. O código BCH garante a detecção de qualquer erro que afete até quatro caracteres e, muitas vezes, consegue identificar a posição dos erros de digitação. Os endereços nativos SegWit v0 (P2WPKH e P2WSH) utilizam esse formato, começando com “bc1q”.
5. Os desenvolvedores identificaram posteriormente uma vulnerabilidade no polinômio original Bech32: a inserção ou exclusão de sequências específicas de caracteres poderia resultar em um endereço válido, mas diferente. Para corrigir isso sem comprometer os endereços v0 existentes, o BIP-350 (2020) introduziu o Bech32m. Ele altera uma constante no cálculo do checksum para que inserções e exclusões desse tipo sejam detectadas. Os endereços Taproot (versão SegWit 1), ativados em novembro de 2021, utilizam o Bech32m e começam com ‘bc1p’.
6. Os endereços da Testnet utilizam o prefixo ‘tb1’ em vez de ‘bc1’. A parte de dados codifica o programa witness: um hash de uma chave pública ou script para a versão 0 do SegWit, ou uma chave pública ajustada de 32 bytes para o Taproot. Quando o software escaneia um código QR ou aceita entrada manual, ele executa a função polymod do BCH para verificar a integridade. Abra um explorador de blocos e localize um endereço de cada tipo: um P2PKH legado que começa com ‘1’, um SegWit v0 que começa com ‘bc1q’ e um endereço Taproot que começa com ‘bc1p’. Anote seus comprimentos e prefixos.

Fatos-chave

Exercício nove, seis, três, um

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

• P. Wuille, G. Maxwell, 'SegWit address format' (BIP-173, 2017)
• P. Wuille, 'Bech32m format for v1+ witness addresses' (BIP-350, 2020)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 4
• Bitcoin Wiki, 'Technical background of version 1 Bitcoin addresses'