Bitcoin Inheritance Plan define como sucessores autorizados descobrem os fundos, obtêm o material necessário e realizam a recuperação após a morte ou incapacidade de agir do proprietário. É mais que um arquivo contendo um seed: autoridade jurídica, conhecimento da carteira e capacidade técnica de assinar um pagamento são partes distintas da mesma tarefa.
Nem o melhor backup ajuda quem desconhece a carteira. O plano precisa de um ponto de partida localizável: quais carteiras existem, quem coordena a recuperação e onde começa o acesso aos materiais. Esse índice não precisa conter chaves secretas. Um documento jurídico trata das pessoas autorizadas, mas não cria uma assinatura ausente. Inversamente, possuir chaves não comprova tecnicamente um direito legal. O projeto deve prever a indisponibilidade do administrador original e um sucessor que desconheça seus hábitos. [Bitcoin Design — Inheritance wallet backup]
Seed Phrase restaura chaves, mas pode não descrever Multisig, caminhos temporizados ou todas as contas. Output Descriptor descreve scripts, chaves e dados de derivação. Um descriptor público sem chaves privadas permite monitorar, não assinar, mas expõe informações financeiras. O formato geral também admite chaves privadas; importa o conteúdo exportado. Uma carteira com BIP39 passphrase exige ainda aquela passphrase exata. Nem o PIN do dispositivo nem outra carteira válida porém vazia substituem os dados ausentes. [Bitcoin Core — Output Descriptors] [Trezor — What is a passphrase?]
Em Multisig 2-of-3, quaisquer dois signatários autorizados satisfazem o limiar. Se dois sucessores recebem suas chaves hoje sem outra restrição, podem assinar hoje. Se o proprietário guarda duas chaves e um auxiliar a terceira, o auxiliar não recupera sozinho quando as duas chaves do proprietário desaparecem. Avalie as combinações efetivamente disponíveis após cada falha, não apenas o número de backups. Uma cópia da mesma chave não acrescenta outra assinatura independente; a configuração também precisa permanecer recuperável. [Bitcoin Design — Inheritance wallet backup] [Bitcoin Core — Output Descriptors]
CHECKSEQUENCEVERIFY, segundo BIP 112 e em conjunto com BIP 68, pode restringir um caminho do script pela idade da saída gasta. A política simplificada “A agora, ou B após 1000 blocos” adia a assinatura de B, não a de A. Ela não verifica morte, capacidade jurídica ou herdeiro legítimo. Quando o prazo termina, B pode usar seu caminho mesmo com A vivo. É uma contagem relativa de blocos desde a confirmação daquele UTXO, não uma data fixa de calendário; o tempo real de mineração varia. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]
Nesse modelo, um UTXO confirmado no bloco H pode ser gasto pelo caminho atrasado no mínimo em H+1000, desde que as outras condições sejam satisfeitas. Receber um novo pagamento ou abrir o aplicativo não zera sua idade. Renovar o prazo exige gastar aquele UTXO em uma nova saída com a política adequada e aguardar confirmação. Liana usa caminhos de recuperação e um refresh sweep; o plano precisa acompanhar todas as saídas relevantes, taxas e disponibilidade da assinatura normal, não só a última atividade da carteira. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time] [Liana — Inheritance guide]
Instruções, segredos de assinatura e eventual senha de descriptografia podem ser distribuídos por diferentes caminhos de acesso, mas a sequência deve ser viável. Uma senha guardada apenas numa conta cuja recuperação depende do telefone do falecido pode criar dependência circular. Os sucessores precisam de contatos responsáveis e de um procedimento alternativo para armazenamento ou auxiliares indisponíveis. Mais cópias aumentam tanto a disponibilidade quanto os possíveis locais de vazamento. Dados públicos de configuração apresentam risco diferente de chaves que permitem gasto imediato. [Bitcoin Design — Inheritance wallet backup]
Instruções legíveis não equivalem a um procedimento de recuperação testado. Em uma carteira de teste separada, o sucessor previsto deve localizar materiais sem depender da memória do proprietário, reconstruir endereços esperados, reconhecer o caminho correto e criar uma transação de teste verificável. Um caminho temporal exige testar a rejeição antes do prazo e o uso depois, por exemplo em regtest. Exibir saldo prova menos que poder assinar. Esse ensaio não inclui divulgar seeds reais nem movimentar a herança efetiva. [Bitcoin Design — Inheritance wallet backup] [BIP 112 — CHECKSEQUENCEVERIFY]
Trocar o herdeiro, perder uma chave ou adotar nova política de assinatura exige verificar onde os fundos estão realmente bloqueados. Editar um nome nas instruções ou criar outro descriptor não altera, por si só, os UTXOs antigos. Mudar condições on-chain exige transferir os fundos para a nova política. Depois de verificar os novos backups, atualizam-se contatos, versões das instruções e endereços de recebimento. Endereços antigos ainda podem receber pagamentos e não devem ser simplesmente esquecidos. O plano é um processo mantido, não um envelope lacrado uma única vez. [Bitcoin Design — Making changes]
Para ter uma visão mais completa, leia este verbete junto com Dead Man’s Switch, Multisig, Timelock, Collaborative Custody, Seed Phrase, BIP39 passphrase. Também há referências a este verbete em Shamir Secret Sharing, Bitcoin Vault, Dead Man’s Switch, Collaborative Custody.