Backup multisig de Bitcoin: o que guardar além de duas sementes

Financiamento: o CypherpunkGuide pode receber comissões de indicação por meio dos guias de compra vinculados. Este artigo não contém links diretos de compra com afiliação. Nenhum fornecedor de carteira patrocinou este trabalho.

O aplicativo que coordenava a carteira desapareceu. Um dos dispositivos de assinatura parou de funcionar. Restam dois backups de sementes — o material de origem das chaves privadas. À primeira vista, uma configuração de 2 de 3 deveria suportar exatamente essa perda.

Ela pode suportar. Mas “2 de 3” descreve quantas assinaturas são exigidas, não tudo o que a recuperação precisa. Além de recuperar as chaves, é necessário reconstruir a carteira na qual elas eram usadas.

O escopo aqui são carteiras Bitcoin P2WSH convencionais com sortedmulti: um script, ou regra de gasto, que exige um número mínimo de assinaturas de um conjunto definido de chaves públicas. Não avaliamos dispositivos físicos, esquemas de assinatura Taproot nem compatibilidade de recuperação entre produtos. Se você ainda está organizando a autocustódia básica, comece pelas verificações de recebimento, assinatura e recuperação.

Duas assinaturas não substituem a configuração completa

#

Duas chaves de assinatura podem satisfazer a regra de 2 de 3. Reconstruir os endereços exige a configuração completa: as três chaves públicas nos pontos de derivação correspondentes, o número mínimo de assinaturas e o tipo de script. Três chaves não significam necessariamente três pessoas.

Um descritor registra de forma estruturada os scripts que uma carteira deve reconhecer. Ele pode incluir chaves públicas estendidas, das quais se derivam conjuntos de chaves públicas, e os caminhos dessa derivação. O BIP380 explica por que guardar apenas as chaves privadas pode deixar dúvidas sobre o tipo de script e os caminhos usados. O BIP383 define as expressões multisig dos descritores, inclusive a ordenação das chaves públicas derivadas em sortedmulti.

Vale conferir três conjuntos de informações separadamente:

Um arquivo de carteira pode reunir várias dessas informações. Um descritor pode preservar boa parte da configuração. O que importa é o conteúdo real da exportação e se o programa de recuperação consegue interpretá-lo. O nome do arquivo ou sua soma de verificação não resolve essa dúvida.

A implementação da janela de backup do Sparrow menciona explicitamente as sementes necessárias e todas as chaves públicas estendidas. Também indica o arquivo da carteira ou o descritor como backups de configuração. Essa constatação vem da leitura do código; não é uma avaliação prática da interface atual nem da compatibilidade de importação em outro produto.

O que medimos no experimento isolado

#

Em 24 de setembro de 2026, nosso experimento no regtest do Core 31.1 — uma blockchain privada de testes — separou reconstrução de endereços, localização de uma saída específica, conclusão das assinaturas e aceitação pelo nó local. O intervalo medido foi de 13,3 segundos, sem as verificações iniciais de versão e hash nem o encerramento e a limpeza finais. Usamos dados fictícios públicos, sem fundos reais. A execução terminou com a rede de pares desativada e zero conexões.

Nos primeiros cinco casos, reconstruímos a configuração em carteiras somente de observação, novas e separadas. A saída procurada, isto é, o valor destinado a um endereço pela transação de teste, era de 0,01000000 BTC de regtest. As chaves A, B e C foram derivadas de entradas fictícias publicadas. Não digitamos sementes em dispositivos físicos.

Nas três últimas linhas, comparamos o endereço de recebimento de índice 1, que havia recebido o pagamento, e não encontramos saldo no intervalo importado. Isso nada demonstra sobre endereços fora desse intervalo. O caso sem a terceira chave também não esgota as formas de recuperação: trocar 2 de 3 por 2 de 2 testa uma reconstrução errada, não a possibilidade de usar outro backup ou um script histórico.

Depois, enviamos a transação A/B à blockchain privada de testes. A carteira com os dois ramos encontrou a saída de troco de 0,00599000 BTC de regtest. A carteira que acompanhava apenas recebimentos tinha encontrado o pagamento inicial, mas não encontrou esse troco. Comparamos uma saída específica; não afirmamos que o saldo total dessa carteira caiu a zero, pois o experimento também tinha saídas de mineração. Um descritor cuja soma de verificação foi danificada de propósito foi recusado. O descritor original passou nas verificações feitas imediatamente antes e depois.

O artigo inclui o programa do experimento, os resultados medidos, os testes de regressão de segurança e um inventário de recuperação em branco. Importamos o intervalo de endereços de 0 a 2, com o instante inicial da nova varredura definido como 0. Para assinar, usamos chaves privadas fictícias derivadas e os dados corretos do script e da saída anterior, fornecidos pela carteira de referência completa. Isso não demonstra um procedimento completo de restauração por semente, a recuperação de um dispositivo físico nem a compatibilidade entre produtos. O teste de aceitação local não transmite uma transação. Esta execução controlada tampouco estima taxas de sucesso de recuperações reais.

Os requisitos e o comando para repetir o experimento estão nas notas do laboratório. Nunca use essas chaves fictícias, divulgadas publicamente, para guardar fundos reais.

Localizar fundos e poder gastá-los são verificações diferentes

#

Uma carteira restaurada pode reconhecer uma saída sem conseguir gastá-la. Também pode deixar de exibir um saldo esperado porque as condições de busca estão incompletas.

É comum que endereços de recebimento e de troco usem ramos de derivação distintos. Se a descrição restaurada não incluir os scripts do troco, um pagamento pode enviar o valor restante para fora do conjunto de endereços que a carteira reconhece. O indicador de classificação internal não equivale, por si só, a incluir ou excluir um ramo.

A implementação e a ajuda de importação de descritores do Core distinguem instante de importação, intervalo de endereços e classificação interna. A sincronização e a disponibilidade de blocos históricos também podem afetar a busca. Um zero na tela pede investigação; sozinho, não prova que as moedas desapareceram.

Pelo mesmo motivo, uma mensagem de importação bem-sucedida ou um campo chamado solvable não basta. A prova relevante de assinatura é uma transação completa que satisfaça o script. Um regtest local mostra o comportamento naquele ambiente controlado. Não é uma confirmação na rede principal nem um teste de compatibilidade de dispositivos.

A configuração pública também pode expor sua privacidade

#

Um descritor contendo apenas informações públicas não assina sozinho. Ainda assim, pode revelar os endereços derivados das chaves e dos caminhos que registra. Quem recebe esses dados pode associar saldos e transações dentro desse conjunto de endereços.

“Chave pública” não é uma recomendação para publicar a configuração da carteira. Restrinja quem pode acessá-la e diferencie essa configuração de um descritor privado, que pode conter chaves privadas. Também há uma razão para não prometer que divulgar chaves públicas é sempre inofensivo para os fundos: o BIP32 descreve como a combinação de uma chave pública estendida pai com uma chave privada filha de derivação não endurecida pode revelar a chave privada pai.

Esse vazamento combinado é diferente de divulgar apenas um descritor público. Nenhuma das duas situações justifica postar dados da carteira num fórum de recuperação para pedir um diagnóstico. Nosso guia de privacidade do Bitcoin na blockchain aborda o problema mais amplo de associar transações.

Confira o plano sem reunir segredos em outra lista

#

Um inventário útil registra se o material necessário existe e foi conferido. Ele não deve virar mais uma coleção de segredos compartilhada sem cuidado.

Nosso modelo pergunta sobre o número mínimo de assinaturas, o backup de configuração, a cobertura de recebimentos e troco, o formato de importação aceito e as verificações separadas de localização e assinatura. Não há campos para palavras de recuperação, senhas adicionais (passphrases), chaves públicas ou descritores reais. Registre o estado da verificação, não os valores.

Siga o procedimento documentado pelo fornecedor da sua carteira ou do dispositivo de assinatura. Não insira sementes reais em sites, chats ou neste programa experimental. As chaves fictícias reproduzíveis publicamente são impróprias para fundos reais. Um teste de restauração de backup criptografado pode comprovar que os arquivos guardados são recuperáveis; não comprova que seu conteúdo basta para gastar os fundos de uma carteira Bitcoin específica.

Multisig acrescenta informações a preservar, pessoas ou dispositivos a coordenar e verificações a fazer. Se essas responsabilidades não forem administráveis, comprar mais dispositivos de assinatura não melhora automaticamente o plano de recuperação. O objetivo deste artigo é ajudar a examinar essa complexidade, não recomendar novas compras.

Pontos essenciais

#

Dúvidas sobre recuperação

#

Perder o descritor torna a recuperação impossível?

#

Não necessariamente. Outro backup compatível pode conter a configuração. Um script conhecido também pode preservar parte da informação: ao gastar uma saída P2WSH, por exemplo, a transação revela seu script de testemunha, conforme o BIP141. Isso não revela automaticamente todas as chaves públicas estendidas nem reconstrói todos os endereços da carteira. A recuperação depende do material que restou.

Uma soma de verificação válida prova que a configuração é a correta?

#

Não. A soma de verificação ajuda a detectar erros de transcrição no descritor. Outra pessoa pode criar um descritor diferente com sua própria soma de verificação válida. Compare a configuração com um backup confiável e com a carteira que você pretende recuperar. Sintaxe válida não comprova autenticidade.

Fontes e cópias arquivadas

#

As explicações acima se baseiam nestas fontes primárias. As cópias arquivadas permitem consultar posteriormente o material citado.