HD Wallet

Alice abre a tela de recebimento e a carteira mostra um endereço. Nele, ela recebe 10 000 satoshis, as pequenas unidades do bitcoin. Para o pagamento seguinte, o aplicativo oferece outro endereço, que recebe 20 000 satoshis. Se esses forem seus únicos recebimentos ainda não gastos, a carteira mostrará 30 000 satoshis no total. O endereço novo não criou uma conta separada, nem moveu automaticamente o dinheiro anterior. O aplicativo administra as chaves dos dois recebimentos. Uma HD Wallet torna isso prático. HD significa Hierarchical Deterministic: hierárquica porque as chaves formam uma estrutura com ramificações, e determinística porque a mesma seed e o mesmo caminho produzem as mesmas chaves, inclusive na recuperação. O caminho é uma sequência de números que indica qual ramo e qual chave o programa deve calcular. Normalmente Alice não precisa lidar com ele para receber, mas a recuperação deve usar os caminhos corretos. Um backup do segredo inicial pode, portanto, abranger também endereços futuros; ainda assim, é preciso guardar as configurações da carteira. Endereços novos ajudam a evitar a reutilização de endereços, mas não garantem anonimato por si só. [1] [12]

Uma chave pública estendida, normalmente chamada xpub, permite calcular as chaves públicas de parte dessa estrutura. Ela não contém as chaves privadas necessárias para assinar pagamentos. Por isso, um xpub sozinho não permite gastar; para criar endereços específicos, o aplicativo também precisa conhecer o formato deles. Uma carteira watch-only com o xpub adequado pode criar endereços e acompanhar pagamentos sem chaves de assinatura. Porém, um vazamento do xpub pode relacionar endereços passados e futuros do ramo, saldos e transações. Compartilhe apenas o ramo necessário. Nem mesmo um xpub correto impede que um computador comprometido mostre um endereço alheio. Confira o endereço de recebimento num dispositivo de assinatura confiável que conheça a carteira. [1] [12] [14]

Uma loja pode criar um endereço diferente para cada pedido. O site precisa conhecer esses endereços, mas não deveria ter as chaves para gastar a receita. BIP32 permite separar esse ramo de recebimento do restante da carteira. Pieter Wuille escreveu a proposta, atribuída em 11 de fevereiro de 2012. É um padrão de carteiras, não uma regra de consenso. As palavras de backup BIP39, os tipos de script e o procedimento completo de recuperação pertencem a outras camadas. [1] [11] [12]

BIP32 acrescenta à chave um chain code de 256 bits: 32 bytes para novas derivações. A forma privada contém um escalar k de secp256k1 e o chain code c; a pública usa K = point(k) e o mesmo c. A chave mestra vem de HMAC-SHA512, com a sequência exata “Bitcoin seed” como chave da função e a seed como dados. Os 32 bytes à esquerda são o candidato a chave privada; os 32 à direita são o chain code. Zero ou um valor pelo menos igual à ordem n da curva torna a chave mestra inválida. [1]

Derivar é calcular, não procurar numa lista armazenada. Há duas formas de derivação: normal e hardened. A normal permite calcular novas chaves públicas a partir da chave pública estendida do pai; uma etapa hardened exige a chave privada estendida do pai. CKDpriv calcula I = HMAC-SHA512(cpar, data), divide o resultado em IL e IR e soma parse256(IL) à chave privada do nó pai módulo n. IR passa a ser o novo chain code. A derivação normal usa serP(Kpar) || ser32(i); a hardened usa 0x00 || ser256(kpar) || ser32(i), com i ≥ 2^31. CKDpub cria apenas ramos públicos normais, somando point(parse256(IL)) a Kpar. Um número de ramo diferente muda as chaves seguintes. [1]

Um xpub pode derivar chaves públicas enquanto o caminho não atravessar uma etapa hardened. Há uma contrapartida: o xpub do pai junto com uma chave privada vazada de um filho normal permite calcular a chave privada do pai. Seus outros ramos também ficam em risco. Hardened bloqueia esse cálculo inverso, mas não protege contra roubo da seed, aleatoriedade fraca ou aprovação de uma transação maliciosa. [1]

Na mainnet, a codificação pública padrão começa com xpub e a privada com xprv; suas versões são 0x0488B21E e 0x0488ADE4. Antes de Base58Check, o registro tem 78 bytes: versão 4, profundidade 1, impressão digital do pai 4, número do filho 4, chain code 32 e dados da chave 33. O resultado tem 111 caracteres. A impressão curta ajuda a relacionar chaves, mas não prova identidade. Os prefixos ypub/zpub de SLIP132 às vezes indicam o tipo de script; mudar apenas o prefixo não altera chaves nem regras da carteira. [1] [9]

BIP43 reservou o primeiro nível hardened para a finalidade. BIP44 usa m / 44' / coin_type' / account' / change / address_index. Depois da conta vem o ramo 0 para recebimento ou 1 para troco, seguido do número do endereço. O apóstrofo ou h indica um índice aumentado em 2^31. A busca BIP44 aplica um gap limit de 20: para após 20 endereços de recebimento consecutivos sem uso. BIP48 descreve Multisig, BIP84 a finalidade 84' para SegWit nativo e BIP86 a 86' para Taproot de uma só chave. Essas convenções não estão na própria seed nem são impostas pelos nós. [2] [3] [4] [5] [6]

As chaves sozinhas não definem o script que protege as moedas. Um Output Descriptor pode registrar a origem das chaves, os caminhos, uma construção como wpkh(), o número de assinaturas exigido, outros participantes de Multisig e uma soma de verificação. Um descriptor multipath pode reunir os ramos de recebimento e troco. A seed de um participante não reconstrói os outros xpub nem as regras comuns. Guarde também um descriptor público verificado ou uma exportação da configuração e proteja sua privacidade. Se a exportação contiver chaves privadas, trate-a como segredo. [7] [8] [10] [13]

A seed permite derivar as chaves novamente, mas o aplicativo precisa conhecer seu formato, a BIP39 passphrase usada, a rede, o tipo de script, coin type, as contas, ambos os ramos e o alcance da busca. Multisig também exige a configuração compartilhada. Saldo zero não significa necessariamente moedas perdidas: o motivo pode ser outro caminho. Um teste seguro num dispositivo confiável deve encontrar os UTXO corretos, ou seja, as saídas de transações ainda não gastas, e verificar a assinatura. Nunca digite uma seed real ou palavras de backup numa ferramenta web ou num computador comum online. [3] [7] [10] [11]

BIP32 também trata resultados inválidos raros: parse256(IL) ≥ n, uma chave privada derivada igual a zero ou um ponto público no infinito. Nesses casos, tenta-se o índice seguinte. Na recuperação, é mais comum faltar o caminho, o ramo de troco ou suporte ao tipo de script. Antes da troca, confira a descoberta das moedas e uma pequena transferência de teste. Preserve o backup e a configuração originais até o novo procedimento funcionar. O xprv fornece as chaves necessárias para assinar, o xpub revela relações financeiras e o descriptor descreve como montar a carteira. [1] [7] [9] [10]