Recuperación diferida

La recuperación diferida es una billetera con dos ramas. La tuya gasta cuando quieras. La de respaldo usa otra clave, la de tu heredero o una copia guardada aparte, y además exige que haya pasado un plazo. Antes del plazo, esa clave no mueve nada. Después, gasta igual que tú.

Lo que más cuesta entender: la rama de respaldo no sabe si has muerto. Solo sabe que una moneda lleva N bloques sin moverse. Si pasas en un hospital más tiempo que el plazo, o simplemente te olvidas, vence igual. La prueba de vida la das tú, gastando las monedas dentro de la misma billetera antes de que venzan. Eso es refrescar.

Refrescar bien pide tres cosas. Contar desde la moneda más antigua, porque cada una tiene su reloj. Saber que el refresco cuenta cuando se confirma, no cuando lo envías: si sigue en la mempool el día que vence el plazo, no protege. Y dejar margen de semanas, no de días. Liquid lo aprendió en 2020: el timelock de un UTXO de 870 BTC estuvo vencido 40 minutos porque algunos refrescos llegaban justo después de tiempo.

Tiene costes: comisiones en cada tanda y privacidad, porque juntar muchas monedas en un refresco las enlaza, y en P2WSH cada gasto enseña la rama de recuperación y su plazo. Y no protege de la coacción: tu rama es inmediata.

Si quieres que el heredero espere más, CSV no llega: aceptas un plazo de hasta unos 455 días o usas una fecha fija con CLTV, que no se refresca. Aplazarla pide descriptor nuevo y mover los fondos. Cada billetera elige. A 7 de octubre de 2026, Liana solo usa plazos relativos y Bitcoin Keeper, una fecha fija. Son ejemplos fechados, no una recomendación.

En «Billeteras con timelock y recuperación diferida» lee «Dos ramas en el mismo script», «CSV y CLTV: dos formas de medir el plazo», «Refrescar: la prueba de vida en cadena», «El caso de Liquid en 2020» y «Lo que un timelock no hace». En «Script y Timelocks», ahora sí, «Codificación de nSequence» y «2038 y los límites de older()».