Bitcoin Inheritance Plan

Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. Las claves privadas son números secretos que permiten autorizar el gasto de bitcoin. Ana guarda cuidadosamente una copia de seguridad, pero no le dice a nadie que existe. Para su familia, el resultado puede ser parecido a no tenerla. Un punto de partida útil identifica las carteras y una persona de contacto para los siguientes pasos. Esa orientación no necesita incluir claves secretas. Debe explicar dónde comenzar a buscar lo necesario aunque Ana no pueda completar las instrucciones. Un documento legal puede determinar quién debe recibir los bienes; no aporta la firma digital que autoriza un pago. A la inversa, poder firmar tampoco demuestra un derecho sobre el patrimonio. La parte legal debe adaptarse a la jurisdicción y a las circunstancias concretas. [1] [8]

Una Seed Phrase es una copia de seguridad escrita en palabras que permite recuperar el material secreto de las claves. Si Ana usa una passphrase BIP39, un texto secreto adicional, también debe estar disponible. El PIN suele desbloquear el dispositivo; no sustituye una passphrase perdida. Otra passphrase puede abrir una cartera válida, pero vacía. Las configuraciones más complejas requieren además conocer sus claves, cuentas y condiciones. Un Output Descriptor lo describe en un formato que entiende el software, incluidos los datos para derivar direcciones. Es especialmente importante en Multisig, donde se necesitan varias firmas. Un descriptor público sin claves privadas permite observar, no gastar. Aun así, revela direcciones e historial; el formato general también puede contener claves privadas. Importa el contenido real de la exportación. [2] [3]

Ana puede separar las instrucciones, la copia y la contraseña de un archivo cifrado. Pero la protección no ayuda si su hija tiene que desbloquear primero el teléfono de Ana para entrar en la cuenta que contiene las instrucciones para desbloquear ese mismo teléfono. Recorre el proceso como alguien que desconoce tus costumbres. Necesita contactos y una alternativa si falta una persona o un lugar de almacenamiento. Más copias reducen el riesgo de pérdida, pero crean más puntos de posible filtración. Una copia de configuración pública y un secreto que permite pagar de inmediato necesitan un tratamiento diferente. [1]

En vez de preguntar solo «¿lo entiendes?», resulta más útil practicar juntos con una cartera de prueba independiente. Siguiendo las instrucciones, el sucesor previsto encuentra los materiales, recupera las direcciones esperadas y crea una transacción de prueba verificable sin depender de la memoria de Ana. Ver un saldo no basta: una cartera de solo lectura puede mostrar fondos sin poder firmar un pago. Si existe una condición temporal, hay que probar el rechazo antes del plazo y el uso después. Un bloque agrupa transacciones en un lote que se añade al historial compartido. Regtest, una red privada de pruebas con generación controlada de bloques, permite hacerlo. Se prueba el procedimiento, sin publicar la copia real ni mover la herencia efectiva. [1] [4] [9]

Multisig 2-of-3 significa que las firmas de dos cualesquiera de tres claves determinadas autorizan un pago. Si dos sucesores reciben sus claves hoy y no hay otra condición, pueden firmar hoy. El umbral no sabe que el pago debía esperar a la herencia. El problema inverso aparece si Ana conserva dos claves y una persona de apoyo la tercera: perder ambas claves de Ana deja al ayudante sin capacidad de firmar solo. Hay que revisar qué combinaciones siguen disponibles cuando falta una persona o un dispositivo. Dos copias de la misma clave no aportan dos firmas independientes. Junto con las claves debe conservarse la configuración de la cartera. [1] [2]

Un bloqueo temporal retrasa una forma concreta de gastar. Con «Ana ahora, o Boris después de 1000 bloques», espera la rama de Boris, no la de Ana. Aquí una rama es una vía permitida para autorizar un pago. CHECKSEQUENCEVERIFY, descrito en BIP 112, junto con BIP 68 permite basar la condición en la edad de un UTXO: una salida de transacción no gastada, un importe concreto con sus propias condiciones. La red no comprueba fallecimientos ni identifica al heredero legítimo. Cumplido el plazo, Boris puede usar su rama incluso si Ana sigue viva, siempre que cumpla las demás condiciones. El ejemplo cuenta bloques, no días del calendario; el tiempo real de generación varía. [4] [5]

Si el UTXO del ejemplo se confirma en el bloque H, la rama retrasada permite gastarlo como pronto en H+1000, si se cumplen las demás condiciones. Recibir otro pago o abrir la aplicación no reinicia la edad de la salida antigua. Para iniciar un nuevo plazo sobre ese valor hay que gastarlo en una nueva salida con la regla adecuada y confirmar la transacción. Liana utiliza ramas de recuperación y un refresh sweep, un envío de fondos propios a un nuevo conjunto de salidas. Hay que revisar todas las salidas relevantes, las comisiones y la disponibilidad de las claves habituales. Decir «usé la cartera hace poco» no demuestra qué salidas se renovaron realmente. [4] [5] [6] [10]

Cambiar de sucesor, perder una clave o modificar las reglas no se resuelve editando un nombre en las instrucciones. Las condiciones de los UTXO existentes siguen siendo las mismas. Un descriptor nuevo describe otra configuración, pero no traslada dinero a ella. Cambiar las condiciones registradas en la red exige preparar la nueva cartera, comprobar sus copias y transferir los fondos mediante una transacción válida. Después deben actualizarse instrucciones, contactos y direcciones de recepción. Las direcciones antiguas pueden seguir recibiendo pagos; no conviene desechar sin más su seguimiento ni los datos necesarios. El plan debe funcionar cuando haga falta, no solo el día en que se redactó. [7]