Dead Man’s Switch

Um modelo pode oferecer ao proprietário uma ramificação imediata e a outras chaves uma ramificação disponível após uma espera. A mesma condição pode ocorrer em uma hospitalização, perda de dispositivo ou manutenção esquecida. O acesso técnico não comprova a situação pessoal nem identifica o herdeiro legítimo. Antes de projetar, defina o evento exato que o sistema realmente observa. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

deadmansswitch.net envia e-mails preparados após confirmações não recebidas. Essa camada difere do Bitcoin Script. No seu próprio projeto, avalie separadamente disponibilidade da conta, entrega ao destinatário e divulgação antecipada. Uma mensagem pode indicar onde está um backup, mas não prova que as condições de gasto foram cumpridas. Alterar o temporizador não recupera uma seed enviada; um vazamento exige também resolver o controle das moedas. [Dead Man’s Switch — Service mechanism]

BIP 65 e OP_CHECKLOCKTIMEVERIFY verificam um limite absoluto de altura ou tempo. BIP 112 e OP_CHECKSEQUENCEVERIFY, com BIP 68, podem impor a idade de um UTXO específico. Bloqueios relativos baseados em tempo usam unidades de 512 segundos e median-time-past, não o relógio do celular; BIP 113 descreve a mediana dos horários dos 11 blocos anteriores. Um prazo em blocos não deve ser tratado como uma data exata no calendário. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time] [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [BIP 113 — Median time-past]

Se um UTXO confirmado em H tem uma ramificação de recuperação após 1000 blocos, ela poderá ser utilizada no mínimo em H+1000, cumpridas as demais condições. Entrar no aplicativo ou receber fundos em outra saída não reinicia sua idade. Renovar o prazo relativo exige gastar essa saída e confirmar outra com a política pretendida. Acompanhe cada UTXO separadamente: uma renovação parcial pode deixar moedas antigas próximas do limite. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]

Em um modelo com a ramificação principal sempre disponível, o fim da espera não elimina sua autoridade. Uma ramificação de recuperação utilizável é acrescentada; alguém ainda precisa assinar e transmitir a transação. Se ambas são válidas, uma transação confirmada decide o gasto do mesmo UTXO, não as etiquetas “proprietário” ou “herdeiro” do aplicativo. O projeto deve tratar de renovações tardias e gastos concorrentes. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

nLockTime sozinho adia uma transação específica; não prova que uma chave autorizada não possa assinar outro pagamento. Um plano pré-assinado deve definir entradas, saídas, poderes de assinatura e financiamento das taxas. Gastar sua entrada em outra transação confirmada torna a pré-assinatura original inutilizável. Atualizar o documento não basta ao mudar o plano: confira os UTXOs reais e se os destinatários possuem o novo material. [BIP 65 — OP_CHECKLOCKTIMEVERIFY]

Esses mecanismos implicam reservar margem antes do próximo prazo, manter alertas funcionais e fundos para taxas. Renovações mais frequentes custam taxas de transação; esperas maiores prolongam a indisponibilidade da recuperação. Quem recupera precisa das chaves certas, da descrição da política, como um descriptor, e de uma ferramenta utilizável. Um backup bloqueado pela conta ou pelo dispositivo do proprietário indisponível cria uma dependência circular. [Liana — Wallet architecture] [Liana — Signet testing guide]

Liana oferece um guia para Signet. Um ambiente de teste separado permite verificar uma tentativa prematura, a maturação da ramificação de recuperação e a renovação de uma saída específica. Acrescente alertas não entregues, perda da chave principal e restauração a partir do material salvo. Verifique o que chaves e UTXOs antigos ainda permitem após mudar o destinatário. Diferencie assinatura, aceitação no mempool e confirmação: o sucesso de um cenário não prova que o plano inteiro esteja livre de falhas. [Liana — Signet testing guide] [BIP 112 — CHECKSEQUENCEVERIFY]