Extended Public Key (xpub)

A Ana guarda as chaves da sua carteira Bitcoin num dispositivo físico e quer confirmar no telemóvel se um cliente lhe pagou. Transfere para o telemóvel a configuração pública da conta escolhida, que inclui o xpub, mas nenhuma chave privada. O telemóvel passa a funcionar como Watch-only Wallet: acompanha os endereços correspondentes, prepara um novo endereço e pode construir uma transação ainda por assinar. Para enviar dinheiro continua a ser necessária a assinatura do dispositivo que guarda as chaves secretas. Da mesma forma, uma loja online pode criar um endereço diferente para cada encomenda sem guardar no servidor chaves que permitam gastar. Esta separação limita os danos de uma intrusão, mas não resolve tudo: um invasor pode mostrar ao cliente o seu próprio endereço para um novo pagamento. [1] [5]

Dás um endereço Bitcoin a quem te vai pagar. Um xpub permite ver muito mais. Quem conhece o xpub de uma conta e as regras dos seus endereços pode derivar os endereços de receção e de troco, relacionando o respetivo histórico e os saldos. Isto abrange o ramo que consegue derivar, não automaticamente todas as contas da carteira. Se entregares o xpub a um serviço de contabilidade ou a um explorador de blocos externo, esse serviço pode guardar uma cópia e acompanhar pagamentos futuros. Desativar a ligação na aplicação não apaga a cópia já entregue. Para um pagamento isolado costuma bastar um endereço; só dá acesso mais amplo quando houver uma razão concreta. [1] [5]

Uma carteira BIP32 cria uma árvore de chaves a partir de uma origem comum. Aqui, «ramo» significa um conjunto de chaves derivadas, não uma parte da rede ou da cadeia de blocos. A partir de um xpub só é possível descer através de passos non-hardened. O outro tipo, Hardened Derivation, exige dados privados e cria uma fronteira que o xpub sozinho não atravessa. A organização habitual do BIP44 coloca essa fronteira antes de cada conta. Exportar o xpub de uma conta não revela, por si só, as outras. A profundidade da exportação também importa: o xpub apenas do ramo de receção dá uma visão mais limitada do que o de uma conta inteira, que normalmente inclui também o troco. [1] [6]

As mesmas chaves públicas podem produzir endereços Bitcoin diferentes conforme as regras usadas. Uma saída de transação regista um montante e as condições para o gastar mais tarde. A aplicação precisa, por isso, de saber o tipo de saída utilizado, por exemplo Native SegWit ou Taproot, e o ramo e os índices a derivar. Os prefixos ypub e zpub definidos no SLIP-0132 podem dar uma indicação do tipo de endereço, mas não descrevem toda a carteira. Um Output Descriptor é mais preciso: é um texto que descreve as chaves e as regras de criação dos endereços e das condições para gastar. Pode incluir a origem da chave, o caminho de derivação e uma soma de verificação que deteta erros de escrita. Esta verifica o texto, não a honestidade de quem o enviou. Nem todo o descriptor é público: pode conter uma chave privada, algo que tens de distinguir antes de o partilhar. [2] [3] [4]

Começa por verificar a rede, a conta escolhida, o tipo de endereço e o caminho de derivação: as instruções que localizam a chave na árvore. Compara vários endereços de receção com a carteira original. Numa carteira física, usa o ecrã de confiança do dispositivo seguindo o procedimento do fabricante. Ter o mesmo nome de conta não basta. Um saldo zero depois da importação pode significar outra conta, outro tipo de endereço ou um intervalo de índices demasiado pequeno, não necessariamente dinheiro perdido. Não introduzas as palavras de recuperação num site qualquer para tentar resolver isso. Se só queres consultar, procura uma exportação da configuração pública, não a Seed Phrase nem um xprv, que é uma chave privada estendida. [4] [5]

O xpub sozinho não é uma chave de assinatura. Mas existe uma ligação importante no BIP32: um xpub do nível superior, chamado parent xpub na documentação, juntamente com a chave privada de um descendente non-hardened, permite calcular a chave privada desse nível superior. Se o descendente estiver mais abaixo, todos os passos até esse nível têm de ser non-hardened, e o caminho correspondente tem de ser conhecido para o cálculo. Não se trata de roubar conhecendo apenas um endereço. O perigo está na combinação de informação pública exposta com uma chave secreta comprometida do mesmo ramo. Assim, o invasor pode obter outras chaves abaixo desse nível. As fronteiras hardened separam contas, mas não protegem uma chave privada que já foi revelada. [1]

Uma carteira Multisig pode exigir, por exemplo, duas assinaturas de três chaves. Mas saber recuperar duas chaves não é toda a história. Para reconstruir as condições corretas de gasto, precisas também dos dados públicos das restantes chaves envolvidas, da sua organização, do número de assinaturas exigido e das regras de derivação. Por isso, juntamente com as cópias secretas, guarda-se a configuração da carteira, como um descriptor público com todos os xpub necessários. Não permite gastar por si só, mas pode ser essencial para recuperar a carteira. O master fingerprint, identificador de oito caracteres hexadecimais da chave de origem, ajuda a associar a configuração. Não é uma identidade garantidamente única: chaves diferentes podem ter o mesmo fingerprint. [4] [5]

A chave pública permite verificar assinaturas feitas com a chave privada correspondente. O BIP32 acrescenta-lhe um chain code, um valor de 32 bytes usado para derivar outras chaves. O par constitui a chave pública estendida. O formato usado para a transportar inclui ainda a versão e a posição na árvore: profundidade, fingerprint do nível imediatamente superior e índice do descendente. Isso não equivale ao caminho completo desde a primeira chave da carteira. Um xpub não é, portanto, um endereço individual, uma palavra-passe de conta ou uma lista de transações. A carteira de consulta procura essas transações na cadeia para os endereços correspondentes. [1]

A função CKDpub do BIP32 recebe a chave pública do nível superior, o seu chain code e o índice do descendente. Usa HMAC-SHA512, um cálculo criptográfico com essas entradas, para preparar os dados da nova chave pública e do novo chain code. Os índices deriváveis publicamente vão de 0 a 2³¹−1. Os índices hardened começam em 2³¹ e costumam ser indicados nos caminhos por um apóstrofo ou pela letra h; para estes, CKDpub com apenas o xpub não basta. Repetir os passos permitidos produz descendentes, não irmãos ou antepassados da chave exportada. Se ocorrer um dos raros resultados inválidos descritos no BIP32, a implementação avança para o índice seguinte. Não precisas de fazer estas contas à mão; o essencial é transferir corretamente a configuração. [1]

Antes da codificação em texto, o registo BIP32 ocupa 78 bytes: versão 4, profundidade 1, fingerprint do nível superior 4, índice do descendente 4, chain code 32 e dados da chave 33. Base58Check acrescenta uma soma de verificação e converte o registo numa sequência de 111 caracteres. A versão pública para a rede principal começa por xpub; a de teste, por tpub. As versões privadas correspondentes começam por xprv e tprv. Tpub não significa Taproot. O prefixo resulta dos bytes de versão e não descreve todas as regras dos endereços. Ao importar, o software tem de verificar também a validade da chave pública, não apenas as primeiras letras ou o comprimento. [1] [3]