Dead Man’s Switch

復旧モデルでは、所有者にはすぐ使える分岐、他の鍵には待機後に使える分岐を与えられます。同じ条件は、入院、機器の紛失、保守の失念でも成立します。技術的なアクセス権は、その人の状況や正当な相続人を証明しません。設計前に、システムが実際に観測する出来事を明確にします。 [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

deadmansswitch.net は定期確認が途絶えると用意されたメールを送信します。これは Bitcoin Script とは異なる層です。独自の設計では、アカウントの可用性、宛先への配信、早すぎる情報開示を個別に評価します。メッセージでバックアップの場所を示せても、支出条件の成立は証明できません。送信済みの seed はタイマー変更で取り戻せず、漏えい時にはコインの管理権も対処する必要があります。 [Dead Man’s Switch — Service mechanism]

BIP 65 と OP_CHECKLOCKTIMEVERIFY は絶対的な高さまたは時間の境界を確認します。BIP 112 と OP_CHECKSEQUENCEVERIFY は BIP 68 と組み合わせて、特定の UTXO の経過期間を強制できます。時間ベースの相対ロックは 512 秒単位と median-time-past を用い、携帯電話の時計は使いません。BIP 113 は直前の 11 ブロックの時刻の中央値を説明しています。ブロック数の期限を正確な暦上の日時と扱うことはできません。 [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time] [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [BIP 113 — Median time-past]

H で承認された UTXO に 1000 ブロック後の復旧分岐があるなら、他の条件も満たす場合に最も早く H+1000 で使用可能になります。アプリへのログインや別の出力への入金では経過期間はリセットされません。相対期限の更新には、その出力を支出し、意図したポリシーの新しい出力を承認させる必要があります。UTXO ごとに追跡し、部分更新で古いコインが期限間近に残らないか確認します。 [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]

主分岐が常に利用できるモデルでは、待機期間が終わってもその権限は消えません。利用可能な復旧分岐が加わり、署名と送信は依然として誰かが行う必要があります。両分岐が有効なら、同じ UTXO の支出を決めるのは承認された取引であり、アプリの「所有者」「相続人」という表示ではありません。期限を過ぎた更新や競合する支出も設計に含めます。 [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

nLockTime 単体は特定の取引を遅らせるだけで、権限を持つ鍵が別の支払いに署名できないことは証明しません。事前署名の計画では、入力、出力、署名権限、手数料の資金を明確にします。別の承認済み取引がその入力を使うと、元の事前署名は使えなくなります。計画変更では文書の更新だけでなく、実際の UTXO と受取人が新しい資料を持つことを確認します。 [BIP 65 — OP_CHECKLOCKTIMEVERIFY]

これらの仕組みから、最も近い期限までの余裕、動作する通知、手数料資金が必要だと分かります。頻繁な更新には取引手数料がかかり、長い待機期間は復旧分岐を使えない期間を延ばします。復旧する人には正しい鍵、descriptor などのポリシー情報、使えるツールが必要です。不在の所有者のアカウントや機器でしか開けないバックアップは循環依存を作ります。 [Liana — Wallet architecture] [Liana — Signet testing guide]

Liana は Signet 用の手順を公開しています。独立した試験環境では、早すぎる試行、復旧分岐の満期、特定出力の更新を確認できます。通知未達、主鍵の紛失、保存資料からの復旧も独自のシナリオに加えます。受取人を変えた後も古い鍵と UTXO が何を許すか確認します。署名生成、mempool 受理、承認を区別し、一つの成功を計画全体に欠陥がない証拠とはしません。 [Liana — Signet testing guide] [BIP 112 — CHECKSEQUENCEVERIFY]