Billeteras con timelock y recuperación diferida

¿Cómo se hereda sin dar hoy el control?

Imagina una caja fuerte con dos cerraduras. La primera la abres tú, cuando quieras. La segunda solo gira si la caja lleva un año sin abrirse, y la llave la tiene tu hermana. Mientras abras la caja de vez en cuando, la llave de tu hermana es un trozo de metal. Si dejas de abrirla, tu hermana puede entrar. Una billetera (wallet) con timelock funciona así, con una diferencia: el reloj no está en la caja, está en la cadena de bloques.

Esta entrada explica el mecanismo y sus costes. El marco legal y las estrategias generales están en herencia y planificación de bitcoin. Los opcodes en sí, en Script y timelocks.

Dos ramas en el mismo script

El script de la billetera tiene dos caminos para gastar. La rama principal usa tus claves y funciona al instante. La rama de recuperación usa otras claves (las del heredero, de un proveedor o de una copia guardada aparte) y exige además que haya pasado cierto tiempo. En Miniscript se escribe, por ejemplo, or_d(pk(PRINCIPAL),and_v(v:pkh(RECUPERACION),older(N))) dentro de wsh(). En Taproot, la recuperación puede ser una hoja del árbol de scripts.

No hace falta que nadie vigile el plazo: lo hacen cumplir las reglas de consenso. Antes del plazo, un gasto por esa rama es inválido y los nodos lo rechazan. Después del plazo, es tan válido como el tuyo.

CSV y CLTV: dos formas de medir el plazo

Aquí la diferencia decide cómo se mantiene viva la billetera.

CSV (relativo). Con older(N), el plazo cuenta desde que se confirma la transacción que creó cada UTXO, según BIP-68 y BIP-112. Cada moneda tiene su reloj. La que recibiste hace un año vence antes que la de ayer. El valor ocupa 16 bits, así que el máximo es 65.535. En bloques son unos 455 días a diez minutos por bloque (cuenta aproximada, porque el ritmo real varía). En modo tiempo la unidad es de 512 segundos, y el tope sale en unos 388 días. Hay una consecuencia práctica: con CSV no hay plazo de cinco años, y hay que refrescar antes de esos 455 días.

Si escribes un número mayor en un descriptor, Bitcoin Core lo acepta sin error y el nodo solo mira los 16 bits bajos y el bit 22, que decide si cuenta bloques o tiempo. Liana y Nunchuk lo rechazan, y el conversor enlazado más abajo avisa, pero un descriptor escrito a mano no tiene esa red. older(262800), pensado como cinco años, abre la rama en 656 bloques, unos 4,6 días (lo explica la entrada de Miniscript). Y BIP-68 solo vale en transacciones con nVersion 2 o superior.

CLTV (absoluto). Con after(T), el script lleva escrita una altura o una fecha fija (BIP-65). Si T es menor que 500.000.000 se lee como altura de bloque. Si es igual o mayor, como fecha en formato Unix. La fecha se compara con el median-time-past (BIP-113), que va algo por detrás de la hora real. Todas las monedas de ese script vencen a la vez, da igual cuándo llegaron.

Un ejemplo con números inventados. Un plazo CSV de 26.000 bloques, unos 180 días. Recibes tres monedas confirmadas en los bloques 900.000, 910.000 y 920.000. La rama de recuperación se abre en los bloques 926.000, 936.000 y 946.000. Cuando la cadena llega al 930.000, la primera moneda ya es gastable por el heredero y las otras dos aún no. Con CLTV y T = 940.000, las tres se abrirían a la vez en el bloque siguiente, el 940.001, porque una transacción con nLockTime 940.000 solo entra en un bloque de altura mayor. Un bloque de diferencia no importa en un plan a un año, pero sí a quien lo programe al bloque.

Para convertir plazos en bloques y comprobar que no pasas del tope de 65.535, tienes el Conversor de timelocks. Es una conversión aproximada, nunca una promesa de fecha.

Refrescar: la prueba de vida en cadena

Cuando vence el plazo, la rama de recuperación queda abierta al lado de la principal. No se cierra sola. Si no refrescas a tiempo, quien tenga la clave de recuperación puede gastar, aunque tú sigas vivo y con la billetera en el cajón.

Refrescar es gastar la moneda dentro de la misma billetera, sin descriptor nuevo. La nueva transacción crea un UTXO nuevo, y su reloj vuelve a cero cuando el refresco se confirma, no cuando lo envías. Un refresco que sigue en la mempool cuando vence el plazo no protege nada, así que hace falta margen. Vale cualquier gasto, también un pago, porque el cambio vuelve con el reloj nuevo. Si no tienes nada que pagar, te la envías a ti mismo. Liana lo ofrece desde su versión 1.0 (12 de mayo de 2023) con un botón por moneda, y su documentación lo resume así: cada moneda se debe gastar al menos una vez cada N bloques (Liana, doc/USAGE.md, consultado el 7 de octubre de 2026). Liana solo admite el bloqueo relativo: su código rechaza cualquier rama de recuperación sin older() (liana/src/descriptors/analysis.rs). Es así en la 15.0, del 1 de agosto de 2026, que sigue siendo la última versión a 7 de octubre de 2026, y su documentación dice que es la única opción «por ahora».

Tiene tres costes. El primero, las comisiones: una transacción por cada tanda de monedas, una vez por plazo y con margen. El segundo, la privacidad al consolidar. Si metes muchas monedas en una sola transacción de refresco, cualquiera que mire la cadena puede enlazarlas como propiedad de la misma persona. Está explicado en consolidación de UTXOs, y el control de monedas te deja decidir cuáles se mezclan. El tercero, también de privacidad: en P2WSH cada gasto enseña el script entero, también la rama de recuperación y su plazo. Quien mire esa transacción sabe que la billetera tiene recuperación diferida y cuánto tarda en abrirse. En Taproot no pasa si la rama principal va en el camino de clave: gastar por ahí no enseña las hojas del árbol.

Con CLTV el refresco no existe como tal. Aplazar el plazo exige un script nuevo con otra T, es decir, otro descriptor, una copia nueva para cada participante y una transacción que migre todo. Bitcoin Keeper funciona así: su código usa un bloqueo absoluto, after(), con el momento de crear la bóveda más el plazo elegido, y la app llama «re-vaulting» a esa migración (repositorio bithyve/bitcoin-keeper, consultado el 7 de octubre de 2026). En Nunchuk, la app Android guarda una fecha fija para la herencia en cadena, lo que apunta también a un bloqueo absoluto. La app manda esa fecha a la API de Nunchuk al preparar la billetera, así que el script final no sale en el código de la app. Nunchuk avisa de que ese plazo no se cambia una vez en la cadena: cambiarlo exige otra billetera y mover los fondos, con un proceso que guía su app. No hay que confundirlo con su plan de herencia «off-chain», cuyo plazo no impone el consenso.

El caso de Liquid en 2020

No es un riesgo teórico, y tampoco es un fallo de aficionados. La Liquid Federation guarda los bitcoins en una multifirma de 11 de 15, con una ruta de emergencia detrás de un timelock: claves de Blockstream que en 2020 describía como 2 de 3. El 26 de junio de 2020, el desarrollador James Prestwich hizo público el fallo, y el 28, Blockstream contó que el timelock de un UTXO grande, de 870 BTC, había vencido durante 40 minutos. Nadie tocó los fondos: según Blockstream, las claves de recuperación no se habían usado nunca. La causa: algunos timelocks se refrescaban a veces poco después de vencer, en lugar de antes (Blockstream, «Patching the Liquid Timelock Issue», 28-06-2020, actualizado el 03-07-2020). El parche adelantó el refresco.

La ayuda de Blockstream, actualizada en agosto de 2026, describe así el diseño: 4.032 bloques en cada peg-in, un timelock nuevo de 2.016 bloques en el cambio de los peg-outs y un refresco automático de lo que no se ha renovado en 1.008 bloques. Es el diseño, no el día a día: el 6 de septiembre de 2026 se suspendieron las operaciones de peg tras un fallo de seguridad, y a 6 de octubre de 2026 los peg-outs seguían en pausa (liquid.net) y no había aviso de que los peg-ins hubieran vuelto. La lección vale para una billetera personal: refresca con margen, nunca en el último día. Más contexto en Liquid Network.

Cuando la recuperación se abre

Si el dueño muere, el heredero espera el plazo y gasta por la rama de recuperación con un programa que entienda el descriptor: Liana, Nunchuk, Bitcoin Keeper o Bitcoin Core, desde la 25.0 en P2WSH y desde la 26.0 en Taproot. Si el dueño se incapacita, ocurre lo mismo, y el sistema no distingue una cosa de la otra. Es el problema del «dead man's switch» que ya describe la entrada de herencia.

Hay variantes. La multifirma que decae reduce el quórum con el tiempo: Nunchuk, en su herencia autónoma (12 de noviembre de 2025), pasa de 2 de 4 a 1 de 3 sin la clave de Nunchuk. Otras configuraciones encadenan ramas escalonadas, como el ejemplo del README de Liana: la familia con 2 de 3 al año y un tercero a los 15 meses. Puedes probar cada etapa por separado en el Simulador de quórum: primero 2 de 4, luego 1 de 3. Los compromisos de repartir claves están en diseño de una multifirma, y la entrada de billetera multifirma cubre lo básico. Si una de las ramas combina claves con MuSig2, recuerda que esa agregación funciona para todos los firmantes de la rama, no para un umbral.

Lo que un timelock no hace

No te protege de la coacción. Tu rama principal es inmediata: quien te obligue a firmar no espera ningún plazo. Un timelock solo frena el gasto si todo el gasto lleva plazo, y eso también te frena a ti. El modelo de amenazas te ayuda a decidir qué riesgo pesa más en tu caso.

Tampoco es lo mismo que una transacción prefirmada con nLockTime. Esa no la impone el script, y cualquier gasto anterior de esas monedas la invalida.

Qué significa esto para ti

Antes de fiarte de un plan así, comprueba tres cosas. Primera, el descriptor: sin él, ni la seed del heredero ni la tuya sirven para recuperar una billetera de este tipo (Liana lo dice en su documentación: sin el descriptor no se recupera desde la copia). Cada participante guarda el descriptor junto a su clave. Antes de meter fondos, restaura cada seed que viva en una hardware wallet en una segunda hardware wallet vacía (con un Trezor Model One, con la recuperación avanzada), nunca tecleándola en un ordenador ni en un móvil, y comprueba que su huella (fingerprint) coincide con la de su clave en el descriptor. Si una clave nació en una app, no la metas en ninguna hardware wallet: pruébala en esa misma app del mismo aparato, con su comprobación de copia o borrándola y restaurándola con el teclado del sistema, solo si ninguna billetera de esa seed tiene fondos, tampoco con passphrase (ver estrategias de copia de la seed). Después, que esa segunda hardware wallet acepta el descriptor guardado y enseña en su pantalla la misma primera dirección que te dio la billetera al crearla (apúntala entonces). Si esa segunda hardware wallet no forma parte del plan, bórrala al terminar: con la seed dentro es otra copia completa. Y mientras pruebas o migras, no borres nunca la única billetera con fondos, ni su app ni su aparato. Es la regla de estrategias de copia de la seed (el descriptor, en descriptores de salida).

Segunda, el aparato: no todos admiten esta política registrada. Liana lista Ledger, BitBox02, Coldcard (solo con su firmware Edge, que Liana describe como beta), Jade, Specter DIY y Krux (firmando con tarjeta SD), cada uno con versiones mínimas distintas, y Jade solo en P2WSH y por USB (Liana, doc/SIGNING_DEVICES.md, consultado el 7 de octubre de 2026). Tercera, el calendario: pon un recordatorio de refresco con margen de sobra y decide qué pasa si tú no puedes: refrescar es gastar con tu clave, y quien lo haga por ti puede gastarlo todo sin esperar.

Restaurar las seeds y cargar el descriptor, como en la primera comprobación, prueba las copias, pero no firma nada. Si restauras y ves el saldo, solo has comprobado el descriptor, ninguna rama. Una primera transacción pequeña por la rama principal, por ejemplo un refresco, sí prueba esa firma.

La rama de recuperación no se puede gastar hasta que vence el plazo. Para ensayarla, y que el heredero sepa hacerlo siguiendo tus instrucciones, monta una billetera de prueba aparte, con la misma estructura y claves nuevas, en signet, la red de pruebas donde las monedas no valen nada. Liana lo permite, y su guía de prueba pone un plazo de 2 bloques para ver la recuperación enseguida (Liana, doc/TRY.md, consultado el 7 de octubre de 2026). Eso vale para un plan con CSV, porque Liana solo usa bloqueos relativos. Con Keeper o Nunchuk, que usan un plazo absoluto, mira si la app tiene modo de red de pruebas antes de dar el plan por ensayado.

En signet puedes usar claves creadas en el ordenador, porque no protegen nada; las reales, nunca. Haz las copias de prueba, seed y descriptor, igual que las reales, y que el heredero restaure desde ellas en otro equipo y gaste desde ahí. Si pulsa «Recover funds» en la misma instalación donde se creó la billetera, no ha probado las copias, que es lo que tendrá que usar de verdad. Nunca se ensaya en la billetera real.