Decent Newsroom
Sign In

⏳ El techo de los 455 días: por qué tu plan de herencia

By Techflows August 20, 2026

⏳ El techo de los 455 días: por qué tu plan de herencia probablemente no existe

Aviso & DYOR

  • Este post es educativo. No es asesoría financiera, legal ni fiscal.
  • La herencia de bitcoin toca leyes locales. Lo que aquí funciona técnicamente puede tener consecuencias distintas según tu país. Consulta a un profesional antes de firmar nada.
  • Todo lo que se describe puede causar pérdida total de fondos si se ejecuta mal. Prueba cada paso con montos ridículos.
  • Tú eres responsable de tus llaves y de la gente que va a quedarse con el problema.

TL;DR: La autocustodia convierte la herencia en un problema de ingeniería, no de notaría: un notario no puede transferir lo que no puede firmar, y un testamento no puede contener la llave sin publicarla. La parte criptográfica ya está resuelta (multisig, timelocks, miniscript). Lo que casi nadie sabe es que hay un techo duro de ~455 días en los timelocks relativos, así que “que mi hijo herede si paso dos años sin tocar la wallet” no se puede implementar tal cual. Y lo que de verdad se lleva los fondos no es ninguna de las dos cosas: es que el heredero no supo que existía, no lo encontró, o no supo ejecutarlo.

1. Los tres fracasos

Todo diseño de herencia navega entre dos fallos opuestos. El tercero es el que de verdad ocurre.

Fracaso Qué pasa Frecuencia real
A · Nadie puede Mueres y las llaves mueren contigo. Los fondos existen, visibles para siempre, y nadie los mueve Alta
B · Alguien puede antes de tiempo El heredero, o quien lo coaccione, accede mientras estás vivo Baja pero catastrófica
C · Todo funcionaba, y aun así se perdió La política era correcta. El heredero no sabía que existía, o no encontró el respaldo, o no supo ejecutarlo, o el timelock caducó y nadie lo refrescó La mayoría de los casos

Blindarte contra A te empuja hacia B, y al revés. Ese es el eje del problema. Pero el que se lleva los fondos casi siempre es C, que no es criptográfico: es documental y humano.

2. Las tres capas

Capa Qué resuelve Estado del arte
Criptográfica Que exista un camino de gasto para el heredero Resuelta. Miniscript, timelocks, multisig
Operativa Que ese camino siga vivo dentro de 5, 10 o 20 años Frágil: exige mantenimiento periódico
Humana y legal Que alguien sepa, encuentre, entienda y ejecute Donde se pierde el dinero

Toda la energía pública se gasta en la capa 1, que es la única que ya funciona.

La capa 1 no la repito aquí porque ya la escribí entera, política por política, en mi serie Secure Policies in Bitcoin (en inglés): MiniScript en términos simples, Liana (I) y Liana (II). Este post es la capa 2 y la capa 3, que son las que se llevan el dinero.

3. Por qué el testamento no es el mecanismo

Un testamento sirve para declarar que el activo existe y quién lo hereda. No sirve para entregar la llave. Tres razones:

  1. Se vuelve público. Al entrar a sucesión, pasa a formar parte de un expediente que consultan herederos, abogados, peritos y en muchos casos cualquiera. Una semilla escrita ahí es una semilla publicada. Vale igual para un xpub o un descriptor: revelan saldo e historial completos.
  2. Llega tarde. Una sucesión tarda meses o años. Tu heredero necesita acceso antes de eso, sobre todo si hay algo que se degrada (sección 8).
  3. No lo lee nadie a tiempo. El testamento se abre después del fallecimiento. Si tu plan necesita que alguien haga algo antes (refrescar un timelock, avisar a un cofirmante), el testamento no es el canal.

Lo que sí va en el testamento: que existen activos en Bitcoin y quién los hereda; quién es el albacea técnico (la persona que sabe ejecutar, que puede no ser el heredero); y dónde está la carta de instrucciones, no la carta misma.

Lo que nunca va: semillas, passphrases, PINs, xpub, descriptores, ubicaciones exactas de los respaldos.

La separación correcta es: el testamento dice qué existe y de quién es. La carta de instrucciones dice cómo se hace. Los respaldos sellados tienen los secretos. Tres documentos, en tres lugares, con tres niveles de confidencialidad.

4. El reloj: los dos timelocks, y el techo que casi nadie menciona

Aquí está la parte técnica que decide el diseño. Los dos primitivos se parecen y no sirven para lo mismo.

older() · relativo (CSV, BIP-68) after() · absoluto (CLTV)
El reloj cuenta desde Que ese UTXO se confirmó Una altura o fecha fija del calendario
Se reinicia Sí, al mover la moneda No. Llega el día y llegó
Sirve para Prueba de vida. Gastar = “sigo aquí” Una fecha pactada
Mantenimiento Refrescar cada UTXO antes de que venza Rehacer la política cuando se acerca la fecha
Techo 65.535 bloques ≈ 455 días Ninguno

Para herencia quieres el relativo, casi siempre. Es un interruptor de hombre muerto nativo: mientras muevas monedas, la ruta del heredero nunca se abre; el día que dejas de moverlas, se abre sola.

El techo de 455 días

Este límite es de consenso y no se negocia:

Un timelock relativo admite como máximo 65.535 bloques, o sea ~455 días (unos 15 meses). En unidades de tiempo el tope es aún menor: 65.535 × 512 segundos ≈ 388 días.

Consecuencia directa, y es la que sorprende: “que mi hijo herede si paso dos años sin tocar la wallet” no se puede implementar con un timelock relativo puro. No es una limitación de tu wallet, es del protocolo.

Las tres salidas:

Salida Cómo Costo
Plazo dentro del techo 6 o 12 meses, refrescando Lo más simple. Recomendado
Timelock absoluto after(altura_futura) a la fecha que quieras No hay prueba de vida: hay que rehacer la política periódicamente, moviendo todo a un descriptor nuevo
Servicio asistido El proveedor administra el plazo fuera de la cadena Reintroduce un tercero (sección 6.5)

Tabla de conversión

A 144 bloques por día.

Plazo Bloques ¿Cabe en relativo?
1 mes 4.320 sí
3 meses 12.960 sí
6 meses 26.280 sí
9 meses 39.420 sí
12 meses 52.560 sí
15 meses 65.520 al filo del techo
18 meses 78.840 no
2 años 105.120 no

5. La cinta de correr del refresh

Lo que nadie te cuenta hasta que lo operas:

  • El reloj es por UTXO, no por wallet. Cada moneda que recibes arranca su propio contador.
  • Refrescar es gastarte a ti mismo. Una transacción real, con comisión real.
  • Muchos UTXOs es mucho trabajo. Consolidar reduce el mantenimiento, pero consolidar es malo para la privacidad: fusiona monedas y las une públicamente para siempre.
  • Un plazo corto obliga a refrescar seguido. Uno largo deja la ruta del heredero abierta más tiempo del necesario si algo sale mal.
  • Con comisiones altas, refrescar duele. Y el día que no refrescas por ahorrarte la comisión, la ruta se abre.

La tensión de diseño, en una línea: el plazo corto te cuesta mantenimiento; el plazo largo le cuesta tiempo a tu heredero. Entre seis y doce meses es donde casi todo el mundo aterriza.

6. Los modelos, comparados

6.1 Sobre sellado con la semilla

A favor: cero complejidad. El heredero no necesita saber nada técnico más que “estas palabras se meten aquí”.
En contra: es un solo punto de fallo total. Quien abre el sobre se lleva todo, hoy, sin esperar a que mueras. Un fuego, una inundación o una mudanza lo borran.

Sirve para montos pequeños. Para lo demás es apostar a la honestidad y a la suerte de una sola persona.

6.2 Shamir (SLIP-39)

La semilla se parte matemáticamente en n fragmentos de los que hacen falta m para reconstruirla.

A favor: reparte el riesgo sin multisig. Ningún fragmento solo sirve de nada. El heredero opera una wallet normal después de reconstruir.
En contra: el punto de la sección 6.6, y que el soporte fuera de un fabricante concreto es limitado.

6.3 Multisig m-de-n repartida

Un 2-de-3 con las llaves en manos y lugares distintos.

A favor: ninguna llave sola sirve. Resiste pérdida y robo a la vez. Nunca se reconstruye un secreto único.
En contra: el heredero tiene que operar multisig, que es la parte difícil. Y necesita el descriptor, sin el cual las llaves no sirven de nada.

6.4 Multisig con decaimiento temporal

La política cambia sola con el tiempo:

or(
  pk(Yo),                              ← hoy, al instante
  and(older(26280), pk(Heredero))      ← si pasan 6 meses sin mover nada
)

A favor: es lo más cercano a “automático”. No hace falta que nadie declare nada, ni notario, ni permiso. La regla vive en consenso.
En contra: el refresh de la sección 5, el techo de 455 días, y que la ruta se publica el día que se usa (sección 9).

6.5 Custodia colaborativa con servicio

Un tercero profesional tiene una llave y coordina. El modelo más interesante resuelve el techo de los 455 días saliéndose de la cadena: una llave de herencia con plazo (uno o dos años), y el beneficiario reclama con dos secretos, uno que localiza el respaldo en el servidor del proveedor y otro que lo descifra. Al iniciar el reclamo corre un período de gracia (7 o 30 días) en el que te avisan varias veces; si estás vivo, lo cancelas.

A favor: el heredero no necesita ser técnico, y el período de gracia es una prueba de vida honesta y práctica.
En contra: hay una empresa en el camino, con datos tuyos y de tu beneficiario, con KYC habitualmente, y con la posibilidad de desaparecer. El secreto vive en un servidor.

6.6 Shamir no es multisig (la confusión más común)

Se parecen porque los dos dicen “m de n”. Hacen cosas distintas:

Shamir (SLIP-39) Multisig
Qué se reparte Un secreto, partido en pedazos Llaves independientes
Al recuperar Se reconstruye la semilla completa Nunca se reconstruye nada: cada llave firma aparte
Quién lo hace cumplir Nadie. Es matemática, fuera de la cadena El consenso de Bitcoin, en el script
Se ve on-chain No. Parece una wallet normal Sí (salvo taproot por key path)
El punto débil El instante de la reconstrucción: la semilla completa existe, entera, en una máquina, en un momento y lugar La complejidad operativa y el descriptor

La diferencia que importa para herencia: Shamir tiene un momento de vulnerabilidad total que multisig no tiene nunca. A cambio, el heredero de un Shamir opera una wallet normal, y el de un multisig tiene que operar un multisig.

Regla práctica: si el heredero no es técnico, Shamir es más realista. Si el monto justifica la complejidad y hay alguien que sepa, multisig es estructuralmente superior. Y no son excluyentes: puedes tener multisig con una de las llaves respaldada en Shamir.

7. El eslabón humano

La capa que decide, y la única sin solución criptográfica. Cuatro condiciones, todas necesarias:

  1. Saber que existe. Si tu heredero no sabe que tienes bitcoin, el mejor plan del mundo no se activa nunca. Suena obvio y es el fallo número uno.
  2. Poder encontrarlo. Saber que existe y no saber dónde está el respaldo es lo mismo que no saber nada.
  3. Poder ejecutarlo. Entender qué hacer, con qué software, en qué orden. Bajo estrés y luto. Sin poder preguntarte.
  4. No poder ejecutarlo antes de tiempo. Que es exactamente lo contrario de los tres anteriores.

La tensión es real y no se resuelve del todo, se administra: cada gramo de claridad que le das a tu heredero es un gramo de riesgo que agregas hoy. Las herramientas para administrarla son la separación de roles (quien sabe dónde ≠ quien tiene el secreto ≠ quien hereda) y el timelock, que permite que el heredero sepa todo sin poder hacer nada mientras tú sigas moviendo monedas.

Y el riesgo que nadie quiere nombrar: un heredero que sabe cuánto hay y cómo llegar a él se convierte en objetivo de terceros, y en algunos casos en el propio riesgo. No es cinismo, es diseño: por eso existe el período de gracia, y por eso el timelock es una defensa y no solo una comodidad.

8. Lo que envejece

Un plan de herencia es lo único en tu setup que tiene que funcionar dentro de veinte años sin que tú lo toques. Qué se degrada:

Pieza Cómo envejece
El software La wallet que usas hoy puede no existir. El descriptor y el estándar (BIP-39, miniscript) sí sobreviven: por eso se respalda el descriptor, no “la app”
El hardware Un dispositivo de 2026 en un cajón en 2040: batería, USB obsoleto, firmware sin soporte
El papel y el metal El papel se degrada; el acero grabado no
Las personas Los cofirmantes se mudan, se pelean, mueren antes que tú, o dejan de hablarte
Las empresas Un servicio de custodia colaborativa a 30 años es una apuesta corporativa
El timelock Se vence si nadie refresca. Es lo primero que falla cuando enfermas
Tu memoria La passphrase que “obviamente” ibas a recordar

Lo único que no envejece es el estándar abierto. Un descriptor y unas palabras BIP-39 se pueden restaurar en cualquier software futuro. Todo lo demás hay que revisarlo con fecha.

9. Lo que la herencia le hace a tu privacidad

Es un costo que hay que aceptar a conciencia:

  • La ruta de herencia se publica. En P2SH y P2WSH, cualquier gasto revela la política completa, incluida la rama del heredero y su plazo. O sea: le dices a un atacante cuál es tu eslabón débil y cuándo esperarlo.
  • En taproot no. Cada rama es una hoja distinta: gastar por la ruta normal no revela la de herencia. Solo se publica el día que el heredero la usa, cuando ya no importa.
  • Tu heredero ve tu saldo desde hoy. Para armar la política le entregas un xpub. Con él ve saldo e historial completos, durante todos los años que falten. Es una conversación que hay que tener antes.
  • Consolidar para refrescar barato une tus monedas. El mantenimiento del plan pelea con tu privacidad.

Conclusión práctica: un plan de herencia con timelocks quiere ser taproot.

10. Lo que no hereda bien

No todo se hereda como una semilla. Estas son las excepciones que hay que resolver aparte:

Activo El problema
Saldo custodial No hay llave que heredar. Se hereda por soporte al cliente, con papeles y a discreción de la empresa. O no se hereda
Wallets con operadores cofirmantes Si el heredero no logra cooperar con ellos, la salida unilateral a la capa base es el único camino, y deja de ser viable si la comisión supera el saldo
Nodo Lightning con canales No es una semilla: hay estado. Sin el respaldo de canales, los fondos en canales no se recuperan solos
Posiciones DeFi Tienen su propio reloj, y es mucho más rápido. Un préstamo colateralizado se liquida solo si el precio se mueve y nadie lo atiende. Un timelock de 6 meses no sirve: ahí el plazo tiene que ser de días
Cuentas y accesos (exchanges, 2FA, correo) El 2FA que te protege es el que bloquea a tu heredero

El punto de DeFi merece una línea más, porque es el que rompe los planes bien hechos: una posición apalancada no espera a que se abra un timelock de herencia. Necesita una ruta de emergencia corta, o instrucciones de cierre, o las dos.

Buenas prácticas y errores comunes

  • ✅ Escribe la carta de instrucciones esta semana. Sin un solo secreto adentro: qué existe, dónde vive, a quién llamar. Es el paso de mayor retorno y menor riesgo de todo el post.
  • ✅ Elige un plazo de 6 a 12 meses si usas timelock relativo, y ponte el recordatorio del refresh en el calendario.
  • ✅ Respalda el descriptor, no solo las semillas. Sin él, las llaves correctas no arman la wallet.
  • ✅ Separa roles: quien sabe dónde, quien tiene el secreto y quien hereda no tienen por qué ser la misma persona.
  • ✅ Ponle fecha de revisión anual a todo el esquema. La gente se muda, se divorcia y se pelea; tu plan de 2026 asume una familia de 2026.
  • ❌ No pongas secretos en el testamento. Se vuelve público al ejecutarse.
  • ❌ No diseñes un esquema que solo tú sabes operar. Eso no es herencia, es un acertijo.
  • ❌ No uses una wallet señuelo sin dejar constancia de que hay algo más. La negación plausible funciona igual de bien contra tu familia que contra un ladrón.
  • ❌ No confundas “se lo dije a mi esposa” con un plan. Decirlo una vez, hace tres años, en la cocina, no es documentación.
  • ❌ No dejes posiciones apalancadas sin una ruta de emergencia corta.

Caso práctico: elige tu plazo y haz un refresh de verdad

Una tarde, con montos ridículos. Es la única forma de saber si tu plan es real o una intención.

  1. Elige el plazo en la tabla de conversión. Si dudas, 6 meses (26.280 bloques).
  2. Arma una wallet con ruta de recuperación temporizada (Liana es la implementación más directa de esto) con descriptor taproot, y mándale 20.000 sats.
  3. Guarda el descriptor donde lo guardarías de verdad. Sin él no hay wallet, y es la causa número uno de pánico.
  4. Haz un refresh: gástate a ti mismo y confirma que el contador vuelve a cero. Anota cuánto costó la comisión y cuántos UTXOs tuviste que tocar. Ese número, multiplicado por los años que planeas vivir, es el costo real de tu plan.
  5. Escribe la carta de instrucciones de esa wallet de prueba, sin secretos adentro.
  6. Dale la carta a tu heredero y sal de la habitación. No respondas preguntas: tú no vas a estar. Dale una semana.

Los resultados posibles: si recupera los sats, tu plan es real, ponle revisión anual. Si se detiene a mitad de camino, acabas de reproducir por 20.000 sats el escenario exacto que te haría perder todo. Si no entiende qué hacer con lo que le diste, el problema no es su capacidad: es tu documentación.

Recursos útiles

La capa criptográfica completa, política por política, en mi serie Secure Policies in Bitcoin (en inglés). Es el complemento técnico de este post:

Cierre

Casi todo lo que se publica sobre herencia en Bitcoin habla de la capa criptográfica, que es justamente la que ya está resuelta. Miniscript existe. Los timelocks funcionan. El multisig es sólido. Puedes armar hoy una política que se ejecuta sola en veinte años sin pedirle permiso a nadie.

Y aun así, la mayoría de los planes van a fallar por el fracaso C: alguien que no supo que existía, no encontró el papel, no entendió el procedimiento, o dejó vencer un plazo que no sabía que había que refrescar.

Lo que se probó, funciona. Lo que no, es una hipótesis. El simulacro es el plan; lo demás es intención.

Y si te quedas con un solo dato técnico, que sea el techo: ~455 días. Es el límite del reloj que Bitcoin te presta, y define lo que puedes diseñar. Todo plan de herencia que hayas visto con plazos de “dos años sin actividad” o lo resuelve fuera de la cadena, o no existe.

  • Acción hoy: la carta de instrucciones. Una hoja, sin un solo secreto adentro, que diga qué existe, dónde vive y a quién llamar. Media hora, cero riesgo, y es la diferencia entre “no encontraron nada” y “supieron qué buscar”.
  • Pregunta para la comunidad: si mañana no estás, ¿cuánto tarda alguien de tu familia en saber que hay bitcoin? ¿Y cuánto en poder moverlo?

Con este cierra la serie. Empezó en el único punto de Bitcoin que no puedes verificar y termina en el único que no vas a estar para operar.

🔑 Serie · Vida de una llave

Cómo nace una llave, qué la sostiene, cómo te la quitan, qué revela mientras la usas y cómo se transfiere cuando ya no estás. Cada entrega se lee sola.

  1. 🔒 He oído un rumor: entropía, cuántica y las barbas del vecino · cómo nace: el único punto que no puedes verificar
  2. 🔑 La passphrase que nadie puede heredar · el secreto que te salva y no te sobrevive
  3. 🛡️ Nadie rompe la criptografía: rompen lo que está alrededor de la llave · cómo te la quitan mientras la usas
  4. 🕵️ Bitcoin no es anónimo, es público · qué revela cada vez que la usas
  5. ⏳ El techo de los 455 días · cómo se transfiere cuando ya no estás ← estás aquí

techflows@blink.sv
Nostr: npub1ahlmfhkf4rszm2uv45jnkc2jrcwjfmc0dgdgzfese8md8z2ldx4qqy88la
Si esto te es útil, un zap es la mejor señal. Si algo está mal, corrígeme públicamente: lo agradezco más que el zap.

https://stacker.news/items/1551584

Write a comment