154 / 736DMS

Dead Man’s Switch

Qué ocurre si el propietario deja de responder

Anna quiere que su familia pueda recuperar sus bitcoins si ella ya no puede ayudar. Dead Man’s Switch puede entregar instrucciones o abrir otra vía hacia los fondos tras un periodo de inactividad. También debe contemplar que Anna simplemente haya perdido el móvil o esté hospitalizada.

Dead Man’s Switch permite un paso predefinido después de una confirmación omitida o un plazo determinado. Puede enviar un mensaje o habilitar otra vía para gastar bitcoins. No sabe si el propietario ha fallecido, y el acceso técnico no acredita derechos sucesorios.

Anna quiere preparar un plan familiar: mientras pueda, gestionará sus bitcoins; si deja de estar disponible durante mucho tiempo, deben existir otras opciones. Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. Firmar significa aquí usar una clave privada, un valor numérico secreto, para crear una prueba verificable de autorización del pago. Los demás pueden comprobar la firma sin conocer ese secreto. Una salida de transacción registra una cantidad y las condiciones para gastarla después. Dead Man’s Switch observa una señal concreta, como una confirmación omitida o la antigüedad de una salida. No puede saber por qué el propietario ha dejado de responder. Una hospitalización, un teléfono averiado o el mantenimiento olvidado pueden cumplir la misma condición. Primero hay que definir qué observa realmente el sistema y qué podrá suceder después. Incluso un mecanismo que funciona correctamente no establece quién es el heredero legítimo. Es una pieza del plan, no un sustituto de todas las decisiones que lo rodean. [1] [5] [8] [9]

El servicio deadmansswitch.net ilustra la modalidad de mensajes: se preparan correos, se eligen destinatarios y se confirma periódicamente la presencia. Tras omitir las confirmaciones, el servicio envía los mensajes. Esto difiere de Bitcoin Script, las reglas que la red comprueba al gastar fondos. Un correo puede indicar dónde buscar documentos sin proporcionar las firmas necesarias. Hay que contemplar mensajes no entregados, cuentas perdidas y revelaciones prematuras. Una Seed Phrase, las palabras para derivar las claves de la cartera, no es una nota cualquiera: si se filtra, cambiar el temporizador no borra lo que otro sabe. También debe resolverse el traslado de fondos expuestos a claves nuevas. [7]

Otra modalidad forma parte de las condiciones de gasto de la cartera. Liana, por ejemplo, distingue una vía principal disponible inmediatamente y otra de recuperación que se abre tras esperar. En ese modelo, los permisos originales de Anna no caducan al terminar el plazo. Se añade una opción; alguien aún debe crear, firmar y difundir una transacción válida. Si ambos titulares tienen vías utilizables, pueden competir por el mismo UTXO, una salida concreta todavía no gastada. Decide el gasto confirmado en la cadena, no la etiqueta propietario o heredero en la aplicación. Un mantenimiento omitido puede dar acceso a otra persona mientras Anna sigue viva. [1] [5]

La preparación práctica empieza con margen antes del vencimiento más cercano. Anna necesita recordatorios fiables, tiempo de reserva y fondos para comisiones. Renovar con mayor frecuencia cuesta comisiones; esperar más retrasa el acceso por la vía de recuperación. La familia necesita las claves correctas, una descripción comprensible de la cartera y software adecuado. Un Output Descriptor es una descripción legible por máquinas de claves y condiciones para localizar y gastar salidas; esa configuración no sustituye las firmas exigidas. Los documentos no deben quedar atrapados en una cuenta que solo se desbloquea con el teléfono inaccesible de Anna. Esa copia existe, pero no ayuda cuando hace falta. [5] [6]

Con una restricción temporal relativa, cada UTXO tiene su propia espera. Un bloque agrupa transacciones en un lote que se añade al historial compartido. Si una salida se confirmó en el bloque H y otra vía exige 1000 bloques, podrá utilizarse como pronto en H+1000, cumpliendo las demás condiciones. Iniciar sesión o recibir otro pago no reinicia su antigüedad. Anna debe gastar esa salida concreta y lograr que se confirme una nueva con las condiciones previstas. Renovar solo parte de la cartera puede dejar salidas antiguas próximas al límite. Abrir hoy la cartera no equivale a renovar el calendario de todas las monedas. [1] [2] [9] [10]

Un Timelock limita cuándo puede utilizarse una vía de gasto. BIP 65 y OP_CHECKLOCKTIMEVERIFY imponen un límite absoluto, por ejemplo una altura de bloque. BIP 112 y OP_CHECKSEQUENCEVERIFY, junto con BIP 68, pueden exigir cierta antigüedad a un UTXO. La variante relativa basada en tiempo usa unidades de 512 segundos y median-time-past, un tiempo calculado a partir de bloques. BIP 113 describe la mediana de las marcas temporales de los 11 bloques anteriores: el valor central una vez ordenadas. No es la hora del móvil ni una promesa de un instante exacto del calendario. Los documentos especifican las reglas; lo esencial para el lector es saber qué reloj usa su plan. [1] [2] [3] [4]

Otro plan puede entregar a la familia una transacción ya firmada con demora. Su campo nLockTime limita cuándo puede confirmarse esa transacción; por sí solo no impide que el titular de la clave firme otra. El plan prefirmado señala UTXO concretos, destinos previstos y una forma de pagar la comisión. Si otra transacción confirmada gasta antes una entrada, la transacción prefirmada deja de servir. Editar un documento no actualiza los fondos ni los datos que conserva la familia. Un cambio exige comprobar salidas reales, permisos de firma y que los destinatarios recibieron información nueva y utilizable. [3]

Liana publica instrucciones para Signet, una red de prueba separada cuyas monedas no tienen valor real. Permite ensayar intentos prematuros, la apertura de una vía de recuperación y la renovación de un UTXO. Para el plan propio también conviene contemplar avisos no entregados, pérdida de la clave principal y recuperación desde los documentos realmente guardados de una cartera de prueba. Al cambiar un destinatario, hay que comprobar qué siguen permitiendo las claves y salidas antiguas. Una firma válida, la aceptación en el mempool de transacciones pendientes y la confirmación en un bloque son pasos distintos. Un ensayo exitoso no demuestra que el plan soporte todos los fallos. [6] [1]

Para obtener la imagen más completa, lee esta entrada junto con Bitcoin Inheritance Plan, Timelock, Bitcoin Vault, Miniscript, Output Descriptor, Seed Phrase. También enlazan con esta entrada Bitcoin Inheritance Plan.

DOC · 001BIP 112 — CHECKSEQUENCEVERIFYEspecificación DOC · 002BIP 68 — Relative lock-timeEspecificación DOC · 003BIP 65 — OP_CHECKLOCKTIMEVERIFYEspecificación DOC · 004BIP 113 — Median time-pastEspecificación DOC · 005Liana — Wallet architectureFuente primaria DOC · 006Liana — Signet testing guideDocumentación DOC · 007Dead Man’s Switch — Service mechanismFuente primaria DOC · 008Bitcoin Developer Guide — WalletsDocumentación DOC · 009Bitcoin Developer Guide — Block ChainDocumentación DOC · 010Liana — ChangelogDocumentación
Revisado: Fuentes primero · No es asesoramiento financiero