Dead Man’s Switch

Model obnovy může dát vlastníkovi okamžitou větev a jiným klíčům větev dostupnou až po čekání. Stejná podmínka však může nastat při hospitalizaci, ztrátě zařízení nebo zanedbané údržbě. Z toho plyne, že technické zpřístupnění nelze pokládat za ověření životní situace ani oprávněného dědice. Před návrhem určete, jakou přesnou událost systém skutečně pozoruje. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

Služba deadmansswitch.net po zmeškaných potvrzeních odesílá připravené e-maily. To ukazuje jinou vrstvu než bitcoinový Script. Pro vlastní návrh samostatně posuďte dostupnost účtu, doručení adresátovi a možnost předčasného zpřístupnění dat. Zpráva může sdělit polohu zálohy, ale nedokazuje splnění podmínek utracení. Odeslaný seed nelze vzít zpět pouhou změnou časovače; při úniku je nutné řešit i kontrolu nad mincemi. [Dead Man’s Switch — Service mechanism]

BIP 65 a OP_CHECKLOCKTIMEVERIFY kontrolují absolutní hranici výšky nebo času. BIP 112 a OP_CHECKSEQUENCEVERIFY spolu s BIP 68 mohou vynutit stáří konkrétního UTXO. Časová varianta relativního zámku používá jednotky 512 sekund a median-time-past, nikoli hodiny telefonu; BIP 113 popisuje medián časů předchozích 11 bloků. Blokovou lhůtu nelze vydávat za přesný kalendářní termín. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time] [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [BIP 113 — Median time-past]

Má-li UTXO potvrzené v H obnovovací větev po 1000 blocích, může být tato větev použitelná nejdříve v H+1000 při splnění dalších podmínek. Přihlášení do aplikace ani nový příjem na jiný výstup jeho stáří neresetuje. Obnovení relativní lhůty vyžaduje utratit tento výstup a potvrdit nový se zamýšlenou politikou. Evidujte každý UTXO zvlášť; částečné přetočení peněženky může ponechat staré mince blízko hranice. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]

V modelu s trvale dostupnou primární větví její oprávnění vypršením čekání nezaniká. Přibude použitelná obnovovací větev; podpis a odeslání transakce musí stále někdo zajistit. Pokud jsou platné obě větve, o utracení téhož UTXO rozhoduje potvrzená transakce, nikoli označení „vlastník“ či „dědic“ v aplikaci. Návrh proto musí řešit i opožděnou obnovu a soupeřící utracení. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

Samotné nLockTime odkládá konkrétní transakci; nedokazuje, že oprávněný klíč nemůže podepsat jinou platbu. Předem podepsaný plán musí určit přesné vstupy, výstupy, podpisová oprávnění a způsob úhrady poplatku. Utracení jeho vstupu jinou potvrzenou transakcí původní předpodpis znepoužitelní. Po změně plánu proto nestačí upravit dokument: zkontrolujte skutečná UTXO a dostupnost nových podkladů pro příjemce. [BIP 65 — OP_CHECKLOCKTIMEVERIFY]

Z těchto mechanismů plyne potřeba rezervy před nejbližší lhůtou, funkčních upozornění a připravených poplatků. Častější obnovování stojí transakční poplatky; delší čekání prodlužuje nedostupnost obnovovací větve. Obnovující osoba potřebuje správné klíče i popis politiky, například descriptor, a použitelný nástroj. Záloha uzamčená účtem nebo zařízením nedostupného vlastníka vytváří kruhovou závislost. [Liana — Wallet architecture] [Liana — Signet testing guide]

Liana nabízí postup pro Signet; oddělená testovací sestava umožní prověřit předčasný pokus, dozrání obnovovací větve a přetočení konkrétního výstupu. Doplňte vlastní scénáře nedoručeného upozornění, ztráty primárního klíče a obnovy z uložených podkladů. Ověřte, co po změně příjemce stále dovolují staré klíče a staré UTXO. Rozlišujte vytvoření podpisu, přijetí do mempoolu a potvrzení; úspěch jednoho scénáře není důkaz bezchybnosti celého plánu. [Liana — Signet testing guide] [BIP 112 — CHECKSEQUENCEVERIFY]