Bitcoin Inheritance Plan establece cómo los sucesores autorizados descubren los fondos, obtienen el material necesario y los recuperan tras la muerte o incapacidad para actuar del propietario. Es más que un archivo con un seed: la autoridad legal, el conocimiento de la cartera y la capacidad técnica de firmar un pago son partes distintas de la misma tarea.
Ni el mejor respaldo ayuda a quien desconoce la cartera. El plan necesita un punto de partida localizable: qué carteras existen, quién coordina la recuperación y dónde comienza el acceso al material. Ese índice no tiene por qué contener claves secretas. Un documento legal determina personas autorizadas, pero no genera una firma ausente. A la inversa, poseer claves no demuestra técnicamente un derecho legal. El diseño debe contemplar la ausencia del administrador original y un sucesor que desconozca sus costumbres. [Bitcoin Design — Inheritance wallet backup]
Seed Phrase restaura claves, pero no necesariamente describe Multisig, ramas temporales o todas las cuentas. Output Descriptor describe scripts, claves y datos de derivación. Un descriptor público sin claves privadas permite observar, no firmar, pero revela información financiera; el formato general también admite claves privadas, por lo que importa el contenido exportado. Una cartera con BIP39 passphrase necesita además esa passphrase exacta. Ni el PIN del dispositivo ni otra cartera válida pero vacía sustituyen los datos ausentes. [Bitcoin Core — Output Descriptors] [Trezor — What is a passphrase?]
En Multisig 2-of-3, dos firmantes autorizados cualesquiera satisfacen el umbral. Si dos sucesores reciben hoy sus claves sin otra restricción, pueden firmar hoy. Si el propietario guarda dos claves y un ayudante la tercera, este no puede recuperar solo cuando desaparecen ambas claves del propietario. Evalúe las combinaciones realmente disponibles tras cada fallo, no solo el número de respaldos. Una copia de la misma clave no añade otra firma independiente; la configuración también debe seguir siendo recuperable. [Bitcoin Design — Inheritance wallet backup] [Bitcoin Core — Output Descriptors]
CHECKSEQUENCEVERIFY, según BIP 112 y junto con BIP 68, puede restringir una rama del script por la edad del output gastado. La política simplificada «A ahora, o B después de 1000 bloques» retrasa la firma de B, no la de A. No verifica muerte, capacidad legal ni heredero legítimo. Al vencer el plazo, B puede usar su rama aunque A siga vivo. Es un número relativo de bloques desde la confirmación de ese UTXO, no una fecha fija del calendario; el tiempo real de minado varía. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]
En ese modelo, un UTXO confirmado en el bloque H puede gastarse por la rama demorada como mínimo en H+1000, si cumple las demás condiciones. Recibir un pago nuevo o abrir la aplicación no reinicia su edad. Renovar el plazo exige gastar ese UTXO en un output nuevo con la política adecuada y esperar confirmación. Liana utiliza ramas de recuperación y un refresh sweep; el plan debe seguir todos los outputs relevantes, las comisiones y la disponibilidad de la firma habitual, no solo la última actividad de la cartera. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time] [Liana — Inheritance guide]
Las instrucciones, secretos de firma y eventual contraseña de descifrado pueden repartirse entre rutas de acceso, pero la secuencia debe ser viable. Una contraseña guardada solo en una cuenta cuya recuperación depende del teléfono del fallecido puede crear una dependencia circular. Los sucesores necesitan contactos responsables y un procedimiento alternativo ante almacenamiento o ayudantes inaccesibles. Más copias aumentan tanto la disponibilidad como los posibles puntos de filtración; los datos públicos de configuración implican un riesgo distinto de las claves que permiten gastar inmediatamente. [Bitcoin Design — Inheritance wallet backup]
Unas instrucciones legibles no equivalen a un procedimiento de recuperación probado. En una cartera de prueba separada, el sucesor previsto debe localizar el material sin depender de la memoria del propietario, reconstruir las direcciones esperadas, identificar la rama correcta y crear una transacción de prueba verificable. Una rama temporal debe probarse tanto antes del plazo, con rechazo, como después, por ejemplo en regtest. Ver el saldo demuestra menos que poder firmar. El ensayo no incluye divulgar seeds reales ni mover la herencia efectiva. [Bitcoin Design — Inheritance wallet backup] [BIP 112 — CHECKSEQUENCEVERIFY]
Cambiar de heredero, perder una clave o adoptar una política de firma nueva exige comprobar dónde están realmente bloqueados los fondos. Editar un nombre en las instrucciones o crear otro descriptor no modifica por sí mismo los UTXO antiguos; cambiar las condiciones on-chain requiere mover los fondos a la política nueva. Tras verificar los nuevos respaldos, se actualizan contactos, versiones de instrucciones y direcciones de recepción. Las direcciones antiguas aún pueden recibir pagos y no deben olvidarse sin más. El plan es un proceso mantenido, no un sobre cerrado una sola vez. [Bitcoin Design — Making changes]
Para obtener la imagen más completa, lee esta entrada junto con Dead Man’s Switch, Multisig, Timelock, Collaborative Custody, Seed Phrase, Frase de contraseña BIP39. También enlazan con esta entrada Shamir Secret Sharing, Bitcoin Vault, Dead Man’s Switch, Collaborative Custody.