Dead Man’s Switch

Un modelo puede dar al propietario una rama inmediata y a otras claves una rama disponible después de una espera. La misma condición puede aparecer por hospitalización, pérdida del dispositivo o mantenimiento desatendido. El acceso técnico no acredita la situación personal ni identifica al heredero legítimo. Antes de diseñarlo, precise qué evento observa realmente el sistema. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

deadmansswitch.net envía correos preparados cuando faltan confirmaciones periódicas. Es una capa distinta de Bitcoin Script. En su propio diseño, evalúe por separado la disponibilidad de la cuenta, la entrega y la revelación anticipada. Un mensaje puede indicar dónde está una copia, pero no demuestra que se cumplan las condiciones de gasto. Cambiar el temporizador no recupera una seed ya enviada; una filtración obliga también a resolver el control de las monedas. [Dead Man’s Switch — Service mechanism]

BIP 65 y OP_CHECKLOCKTIMEVERIFY comprueban un umbral absoluto de altura o tiempo. BIP 112 y OP_CHECKSEQUENCEVERIFY, junto con BIP 68, pueden exigir una edad concreta de un UTXO. Los bloqueos relativos temporales usan unidades de 512 segundos y median-time-past, no el reloj del teléfono; BIP 113 describe la mediana de las marcas temporales de los 11 bloques anteriores. Un plazo en bloques no es una fecha exacta del calendario. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time] [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [BIP 113 — Median time-past]

Si un UTXO confirmado en H tiene una rama de recuperación tras 1000 bloques, podrá usarse como pronto en H+1000, cumpliendo las demás condiciones. Iniciar sesión o recibir fondos en otra salida no reinicia su edad. Renovar el plazo relativo exige gastar esa salida y confirmar otra con la política prevista. Lleve el control de cada UTXO: una renovación parcial puede dejar monedas antiguas cerca del umbral. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]

En un modelo cuya rama principal siempre está disponible, el vencimiento no elimina su autorización. Se añade una rama de recuperación utilizable; alguien todavía debe firmar y transmitir la transacción. Si ambas ramas son válidas, una transacción confirmada decide el gasto del mismo UTXO, no las etiquetas «propietario» o «heredero» de la aplicación. El diseño debe contemplar renovaciones tardías y gastos competidores. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

nLockTime por sí solo retrasa una transacción concreta; no demuestra que una clave autorizada no pueda firmar otro pago. Un plan prefirmado debe precisar entradas, salidas, facultades de firma y financiación de comisiones. Si otra transacción confirmada gasta su entrada, la prefirma original queda inutilizable. Modificar el documento no basta al actualizar el plan: compruebe los UTXO reales y que los destinatarios disponen del nuevo material. [BIP 65 — OP_CHECKLOCKTIMEVERIFY]

Estos mecanismos implican reservar margen antes del próximo vencimiento, mantener avisos funcionales y disponer de fondos para comisiones. Renovar más a menudo cuesta comisiones; esperar más prolonga la indisponibilidad de la recuperación. Quien recupere necesita las claves correctas, una descripción de la política, como un descriptor, y una herramienta utilizable. Una copia bloqueada por la cuenta o el dispositivo del propietario inaccesible crea una dependencia circular. [Liana — Wallet architecture] [Liana — Signet testing guide]

Liana ofrece una guía para Signet. Un entorno de prueba separado permite verificar intentos prematuros, la habilitación de la rama de recuperación y la renovación de una salida concreta. Añada avisos no entregados, pérdida de la clave principal y restauración desde el material guardado. Compruebe qué permiten todavía las claves y los UTXO antiguos al cambiar al destinatario. Distinga firma, aceptación en mempool y confirmación: un caso exitoso no demuestra que todo el plan esté libre de fallos. [Liana — Signet testing guide] [BIP 112 — CHECKSEQUENCEVERIFY]