Tipos de script e formatos de endereço

Um endereço é uma codificação legível por humanos de um script de bloqueio. Seu formato informa ao analista qual tipo de script está em uso, o que ajuda a identificar o software da carteira e a época em que foi criado, além de determinar quais informações se tornarão públicas quando as moedas forem gastas. Conhecer bem os formatos e saber o que multisig e Taproot ocultam ou revelam é uma habilidade básica para quem trabalha com dados UTXO.

Do script ao endereço

Os endereços não aparecem na cadeia. O que a cadeia armazena é o scriptPubKey; exploradores e decodificadores o convertem em um endereço para exibição. Cada tipo de script padrão corresponde a uma codificação e a um prefixo reconhecível (os scripts são analisados em detalhes na aula Transações brutas de Bitcoin):

As testnets usam prefixos diferentes (m ou n para P2PKH, 2 para P2SH, tb1 para SegWit), então é fácil identificar um endereço de testnet perdido em um conjunto de dados. Alguns scripts mais antigos, como saídas pay-to-public-key da época inicial da mineração e multisig sem encapsulamento, não têm um endereço padrão; os exploradores exibem a chave pública ou um rótulo sintético, e os armazéns de dados podem deixar a coluna de endereço vazia. Uma consulta que filtra por address IS NOT NULL os descarta silenciosamente.

Base58Check

Os endereços legados usam Base58Check. O codificador recebe um byte de versão, acrescenta o payload de 20 bytes (um HASH160 de uma chave pública ou de um script), calcula uma soma de verificação e escreve o resultado usando um alfabeto de 58 caracteres que omite os caracteres que podem ser facilmente confundidos: 0, O, I e l.

byte de versão   00                -> P2PKH da mainnet, então a string começa com "1"
payload          HASH160 de 20 bytes de uma chave pública
soma de verificação  primeiros 4 bytes de SHA-256(SHA-256(version || payload))
codificado       Base58 dos 25 bytes -> 1Fx3…9qLm

Cada byte zero inicial se transforma em um 1 inicial, razão pela qual todo endereço P2PKH começa com esse caractere. Base58Check diferencia maiúsculas de minúsculas, e a soma de verificação de 4 bytes faz com que um endereço digitado incorretamente quase sempre seja rejeitado. Para os analistas, o byte de versão é a chave de classificação: 0x00 significa P2PKH, 0x05 significa P2SH, e qualquer outro valor indica outra rede ou outra moeda.

Bech32 e bech32m

Os endereços SegWit nativos usam bech32, definido no BIP-173. Uma string bech32 tem três partes: uma parte legível por humanos (bc para a mainnet, tb para a testnet), o separador 1 e uma parte de dados escrita usando um alfabeto de 32 caracteres que exclui 1, b, i e o. O primeiro caractere dos dados é a versão do witness (q é a versão 0, p é a versão 1), seguido pelo programa witness e por uma soma de verificação de 6 caracteres.

bc1q…7k3f            42 caracteres
hrp        bc        -> Bitcoin mainnet
separador  1
versão     q = 0     -> SegWit v0, então a soma de verificação deve ser bech32
programa   20 bytes  -> P2WPKH (um programa de 32 bytes seria P2WSH)
soma de verificação  últimos 6 caracteres

Bech32 usa apenas letras minúsculas (letras maiúsculas são permitidas para códigos QR, mas os decodificadores devem rejeitar combinações de maiúsculas e minúsculas), tem no máximo 90 caracteres, e sua soma de verificação garante a detecção de qualquer erro que afete até quatro caracteres. Há uma falha: quando uma string termina em p, inserir ou excluir caracteres q logo antes desse p pode manter válida a soma de verificação. Para a versão 0, os comprimentos estritos do programa (20 ou 32 bytes) tornam isso praticamente inofensivo. Versões posteriores permitem outros comprimentos, então o BIP-350 introduziu bech32m, idêntico, exceto pela constante usada na soma de verificação (0x2bc830a3 em vez de 1). Os endereços da versão 0 continuam usando bech32; as versões de 1 a 16, incluindo Taproot, usam bech32m. Um decodificador deve rejeitar um endereço da versão 1 com uma soma de verificação bech32 e um endereço da versão 0 com uma soma de verificação bech32m.

Pontos práticos para pipelines: não classifique apenas com base em "começa com bc1"; verifique o quarto caractere (q ou p) e o comprimento. Analisadores sintáticos escritos antes de 2021 podem rejeitar endereços bc1p válidos ou tratá-los como erros, e um pipeline que descarta linhas não analisáveis terá uma contagem menor da atividade Taproot sem nenhum aviso.

O que o formato revela sobre as carteiras

Os formatos de endereço acompanham a história das carteiras, portanto trazem informações sobre o software por trás delas:

• 1… (P2PKH): carteiras antigas, serviços que só usam endereços legados e algumas carteiras de exchange de longa data. Atividade P2PKH recente hoje costuma indicar software antigo ou personalizado.
• 3… (P2SH): ambíguo até que os fundos sejam gastos. Pode ser uma carteira multisig ou uma carteira de chave única usando SegWit encapsulado (P2WPKH encapsulado em P2SH), que era um padrão comum por volta de 2017–2019.
• bc1q… (SegWit v0): o tipo de endereço de recebimento padrão da maioria das carteiras convencionais nos últimos anos. P2WSH (62 caracteres) geralmente indica multisig ou outro script personalizado.
• bc1p… (Taproot): carteiras que adotaram Taproot após sua ativação no bloco 709.632, em novembro de 2021, além de ferramentas para inscrições e tokens que dependem dele.

Quando uma saída 3… é gasta, o script de resgate aparece na entrada e resolve a ambiguidade: um script de resgate composto por 0014 mais 20 bytes é P2WPKH encapsulado; 0020 mais 32 bytes é P2WSH encapsulado; e um script que termina em ae (OP_CHECKMULTISIG) é multisig clássico.

Os tipos de script também podem se misturar nas transações. Se todas as entradas forem P2WPKH e as duas saídas forem uma P2WPKH e uma P2SH, é mais provável que a saída correspondente ao tipo das entradas seja o troco. O tipo de endereço é uma entre várias impressões digitais de carteira, juntamente com a versão da transação, o tempo de bloqueio e os valores de sequência, além da codificação da assinatura; a aula Heurísticas de detecção de troco explica como combiná-las e quanta confiança atribuir a elas.

Multisig e sua marca

O multisig clássico usa OP_CHECKMULTISIG dentro de um script de resgate P2SH ou de um script witness P2WSH. A política permanece oculta enquanto os fundos não são gastos (apenas um hash está na cadeia), mas se torna totalmente pública no primeiro gasto. Uma entrada P2WSH multisig 2 de 3 decodificada se parece com isto:

witness[0]  (vazio)            -- elemento fictício exigido por OP_CHECKMULTISIG
witness[1]  3044…01            -- primeira assinatura (DER, byte sighash 01)
witness[2]  3045…01            -- segunda assinatura
witness[3]  5221…21…21…53ae    -- OP_2 <key1> <key2> <key3> OP_3 OP_CHECKMULTISIG

No script witness, 52 é OP_2 (duas assinaturas necessárias), cada 21 insere uma chave pública compactada de 33 bytes, 53 é OP_3 (três chaves) e ae é OP_CHECKMULTISIG. Um gasto revela o limiar, as três chaves públicas e quais duas chaves assinaram.

Essa marca é uma evidência rica. Custodiantes costumam usar políticas distintas (2 de 3, 3 de 5) para armazenamento a frio, e a mesma chave pública aparecendo em vários scripts multisig vincula esses endereços a um único detentor de chave com muito mais confiabilidade do que heurísticas comportamentais. Muitas carteiras ordenam as chaves lexicograficamente (BIP-67), o que, por si só, é uma pequena impressão digital.

Taproot e privacidade

Taproot combina três componentes. BIP-340 define assinaturas Schnorr na mesma curva secp256k1: assinaturas fixas de 64 bytes e chaves públicas "x-only" de 32 bytes. BIP-341 define a saída: OP_1 seguido por uma chave Q de 32 bytes, onde Q = P + t·G, P é uma chave interna e o ajuste t se compromete com P e com a raiz de Merkle de uma árvore opcional de scripts alternativos. BIP-342 define as regras de script dentro dessa árvore, substituindo OP_CHECKMULTISIG por OP_CHECKSIGADD.

Uma saída Taproot pode ser gasta de duas maneiras, que revelam quantidades muito diferentes de informação:

No caminho de chave, uma carteira de chave única, um grupo n de n que usa agregação de chaves (MuSig2) e um esquema de assinatura de limiar produzem a mesma coisa: uma assinatura para uma chave. O caminho de script revela apenas a folha efetivamente usada; os ramos não utilizados permanecem ocultos, embora o comprimento do caminho de Merkle revele algo sobre o tamanho da árvore, o que o próprio BIP-341 observa que pode ajudar no agrupamento de carteiras.

Para os analistas, Taproot elimina a marca multisig descrita acima sempre que o caminho de chave é usado, tornando invisíveis as políticas de custódia. Ele não oculta os valores, o grafo de transações nem o momento das transações, e, embora sua adoção ainda seja modesta, o próprio formato bc1p é uma característica distintiva. Gastos pelo caminho de script também podem conter inscrições: desde 2023, witnesses grandes com um "envelope" OP_FALSE OP_IF … OP_ENDIF têm sido usados para incorporar imagens e dados de tokens, um padrão que vale a pena filtrar em análises de pagamentos.

Foco no exame: associar prefixos e comprimentos a tipos de script (1, 3, bc1q com 42 e 62 caracteres, bc1p com 62); estrutura de Base58Check (byte de versão, soma de verificação de 4 bytes com SHA-256 duplo, versão 0x00 versus 0x05); estrutura de bech32 (hrp, separador 1, caractere da versão witness, soma de verificação de 6 caracteres) e a mudança do BIP-350 para bech32m para a versão witness 1 e superiores; por que "começa com bc1" não é uma classificação; como um gasto de uma saída P2SH a resolve como SegWit encapsulado ou multisig; o que um gasto multisig clássico revela; gastos Taproot pelo caminho de chave versus pelo caminho de script, Q = P + t·G e o bloco de controle de 33 + 32m; o que Taproot oculta e o que não oculta.