Dead Man’s Switch

Model może dawać właścicielowi gałąź natychmiastową, a innym kluczom gałąź dostępną po oczekiwaniu. Ten sam warunek może wystąpić przy hospitalizacji, utracie urządzenia lub zaniedbaniu obsługi. Dostęp techniczny nie potwierdza więc sytuacji życiowej ani uprawnionego spadkobiercy. Przed projektowaniem określ dokładne zdarzenie, które system rzeczywiście obserwuje. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

deadmansswitch.net wysyła przygotowane e-maile po pominiętych potwierdzeniach. To inna warstwa niż Bitcoin Script. We własnym projekcie osobno oceń dostępność konta, doręczenie odbiorcy i przedwczesne ujawnienie danych. Wiadomość może wskazywać miejsce kopii, ale nie dowodzi spełnienia warunków wydania. Wysłanego seeda nie cofnie zmiana zegara; wyciek wymaga również rozwiązania kwestii kontroli nad monetami. [Dead Man’s Switch — Service mechanism]

BIP 65 i OP_CHECKLOCKTIMEVERIFY sprawdzają bezwzględny próg wysokości lub czasu. BIP 112 i OP_CHECKSEQUENCEVERIFY wraz z BIP 68 mogą wymuszać wiek konkretnego UTXO. Czasowe blokady względne stosują jednostki 512 sekund oraz median-time-past, nie zegar telefonu; BIP 113 opisuje medianę znaczników czasu poprzednich 11 bloków. Okresu w blokach nie należy przedstawiać jako dokładnego terminu kalendarzowego. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time] [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [BIP 113 — Median time-past]

Jeśli UTXO potwierdzone w H ma gałąź odzyskiwania po 1000 blokach, może ona być dostępna najwcześniej w H+1000 po spełnieniu pozostałych warunków. Logowanie do aplikacji ani nowy wpływ na inne wyjście nie zeruje jego wieku. Odnowienie względnego okresu wymaga wydania tego wyjścia i potwierdzenia nowego z zamierzoną polityką. Śledź każde UTXO osobno: częściowe odnowienie portfela może pozostawić stare monety blisko progu. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]

W modelu ze stale dostępną gałęzią główną jej uprawnienia nie wygasają wraz z oczekiwaniem. Dochodzi użyteczna gałąź odzyskiwania; ktoś nadal musi zapewnić podpisanie i rozgłoszenie transakcji. Jeśli obie gałęzie są ważne, o wydaniu tego samego UTXO decyduje potwierdzona transakcja, a nie etykieta „właściciel” lub „spadkobierca” w aplikacji. Projekt musi uwzględniać spóźnione odnowienie oraz konkurencyjne wydania. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

Samo nLockTime opóźnia konkretną transakcję; nie dowodzi, że uprawniony klucz nie może podpisać innej płatności. Wcześniej podpisany plan musi określać wejścia, wyjścia, uprawnienia podpisujących i finansowanie opłat. Wydanie jego wejścia inną potwierdzoną transakcją czyni pierwotny podpis bezużytecznym. Przy zmianie planu dokument nie wystarczy: sprawdź rzeczywiste UTXO i dostępność nowych materiałów dla odbiorców. [BIP 65 — OP_CHECKLOCKTIMEVERIFY]

Z tych mechanizmów wynika potrzeba zapasu przed najbliższym terminem, działających powiadomień i środków na opłaty. Częstsze odnowienia kosztują opłaty transakcyjne; dłuższe oczekiwanie wydłuża niedostępność odzyskiwania. Osoba odzyskująca potrzebuje właściwych kluczy, opisu polityki, na przykład descriptora, i użytecznego narzędzia. Kopia zamknięta za kontem lub urządzeniem niedostępnego właściciela tworzy zależność kołową. [Liana — Wallet architecture] [Liana — Signet testing guide]

Liana udostępnia instrukcję dla Signet. Oddzielny zestaw testowy pozwala sprawdzić przedwczesną próbę, dojrzenie gałęzi odzyskiwania i odnowienie konkretnego wyjścia. Dodaj niedostarczone powiadomienia, utratę klucza głównego i odtworzenie z zapisanych materiałów. Sprawdź, co stare klucze oraz UTXO nadal umożliwiają po zmianie odbiorcy. Rozróżniaj podpisanie, przyjęcie do mempoolu i potwierdzenie: jeden udany scenariusz nie dowodzi bezbłędności całego planu. [Liana — Signet testing guide] [BIP 112 — CHECKSEQUENCEVERIFY]