Bitcoin Vault

Anna guarda parte das suas poupanças em bitcoin. Uma carteira é uma aplicação ou um dispositivo para receber e enviar bitcoin. Assinar significa aqui usar uma chave privada, um valor numérico secreto, para criar uma prova verificável de autorização do pagamento. Outras pessoas podem conferir a assinatura sem conhecer esse segredo. Numa carteira comum controlada por uma única chave, um ladrão que a obtenha pode assinar logo um pagamento para o seu próprio endereço. Bitcoin Vault procura mudar esse momento: a chave usada nos levantamentos habituais inicia um processo e Anna ganha uma oportunidade para salvar os fundos. Lembra um cofre com espera e um desvio de emergência. Mas a comparação só vale quando as condições de gasto da rede impõem realmente as restrições. Um temporizador na aplicação não basta. Uma Hardware Wallet, dispositivo que protege as chaves de assinatura, também não é automaticamente um vault; protege outra parte do processo. [1] [6]

Uma saída de transação regista um montante e as condições para o gastar depois. Bitcoin regista saídas de transações disponíveis para gastar, chamadas UTXO. Um bloco agrupa transações que são acrescentadas ao histórico partilhado. Num modelo simples, a transação inicial gasta a saída guardada e cria outra com uma condição de espera. Esse passo chama-se unvault. O pagamento final poderá seguir mais tarde, enquanto uma via de recuperação permite intervir antes. Se a saída intermédia for confirmada no bloco H com um atraso de 144 blocos, a via normal poderá ser usada, no mínimo, em H+144, cumpridas as restantes condições. Não são exatamente 24 horas: os blocos não chegam segundo um horário fixo. Também não se anula um pagamento concluído; a transação de recuperação tem de ser confirmada antes do gasto final. [1] [5] [7]

Anna deteta um levantamento que não pediu. Precisa de monitorização operacional da rede, de uma transação de recuperação válida e de meios para pagar a comissão. Um Mempool guarda transações não confirmadas; a aceitação aí não chega. O congestionamento ou o pinning, em que um atacante dificulta substituir ou confirmar uma transação, podem atrasar a resposta. Revault prevê CPFP: uma transação descendente acrescenta comissão para incentivar os mineiros a confirmar ambas em conjunto. Algumas recuperações usam ALL | ANYONECANPAY, um modo de assinatura que permite acrescentar entradas para financiar comissões, ou seja, referências a outros montantes ainda não gastos. São ferramentas de um modelo concreto, não uma garantia de confirmação atempada. As taxas históricas da especificação não são recomendações atuais. [1] [4]

Uma transferência protetora pode travar o ladrão e ainda assim deixar outro problema a Anna: a carteira de destino tem de continuar utilizável. Conhecer o endereço não chega. São necessárias as chaves exigidas, a descrição das condições e quaisquer transações preparadas. Poder iniciar a transferência de proteção é diferente de poder gastar a partir do destino. Um monitor pode receber a primeira permissão sem obter a segunda. Porém, uma via de recuperação demasiado acessível pode permitir bloquear repetidamente levantamentos legítimos. Um bom modelo considera, por isso, a recuperação do acesso e o abuso da própria proteção, além do roubo. [1] [4]

Alguns vaults usam as regras atuais e transações pré-assinadas. As assinaturas são criadas na configuração; depois, a segurança pode depender de apagar chaves de utilização única ou de coassinantes independentes que recusem outros percursos. A rede não consegue verificar que todas as cópias de uma chave foram realmente apagadas. Uma cópia escondida pode contornar a proteção. A cópia de segurança também pode exigir mais do que uma Seed Phrase, as palavras usadas para derivar as chaves da carteira. Estas podem não recriar uma assinatura em falta de uma chave de utilização única já apagada. As transações pré-assinadas e os dados associados podem ser indispensáveis à recuperação. [1] [4]

Revault mostra que perguntar quem tem uma chave é apenas o início. Stakeholders detêm a autoridade principal; managers gerem levantamentos correntes e cosigning servers coassinam-nos. O depósito exige N-of-N, isto é, todas as assinaturas dos stakeholders definidos: trata-se de Multisig, aprovação conjunta com várias chaves. A saída intermédia pode ser gasta pela via dos stakeholders ou, após X blocos, pela dos managers e servidores. Cancel devolve-a às condições originais do depósito; uma transferência de emergência vai para Emergency Deep Vault. Os stakeholders também dispõem de uma via direta, bypass. Quem obtenha todas as suas chaves não precisa de esperar. Esta divisão descreve uma especificação, não todos os vaults. [4]

Um BIP documenta uma proposta ou norma Bitcoin; o número não implica ativação. Na verificação de 17 de outubro de 2026, BIP 345 está Closed e indica BIP 443 em Proposed-Replacement. Combinava OP_VAULT e OP_VAULT_RECOVER com OP_CHECKTEMPLATEVERIFY, instruções que restringem percursos de levantamento. BIP 443 propõe o mais geral OP_CHECKCONTRACTVERIFY, ou OP_CCV, e continua Draft; o mecanismo de ativação não está definido. BIP 119, relativo a OP_CHECKTEMPLATEVERIFY, também está Draft. Integram a discussão sobre Covenants, restrições ao uso futuro de uma saída. Código publicado ou uma demonstração não provam que mainnet, a rede principal de Bitcoin, imponha essa proteção. [1] [2] [3]

Antes de confiar poupanças a um vault, Anna deve compreender o levantamento normal, a recuperação e cada via bypass. Os ensaios pertencem a um ambiente de teste separado: levantamento normal, tentativa antes do fim do prazo, unvault inesperado, falha do monitor e falta de fundos para comissões. Uma assinatura válida, a aceitação no mempool e a confirmação num bloco são coisas distintas. Uma demonstração bem-sucedida não testa os restantes percursos. Para quem começa, o essencial é que um vault dá tempo para reagir, mas também cria tarefas que alguém deve cumprir com fiabilidade. Este texto não é uma instrução para colocar dinheiro real num script experimental. [1] [4]