CLTV y CSV

Casi todo plan de herencia con bitcoin acaba en la misma frase: «esta clave puede gastar, pero no antes de tal momento». Eso se escribe con un timelock, y hay dos formas de medir el momento. Elegir una u otra es elegir cómo vas a mantener el plan durante años.

• Absoluto: CLTV, after(). El script lleva escrita una altura de bloque o una fecha. Por debajo de 500.000.000 el número es una altura; desde ahí, una hora Unix. Todas las monedas de ese script se abren a la vez, lleguen cuando lleguen. Aplazar la fecha exige otro script y mover los fondos.
• Relativo: CSV, older(). El plazo cuenta desde que se confirma cada moneda. Cada UTXO tiene su reloj, y al moverlo vuelve a cero, así que el plazo se renueva sin cambiar de billetera. Tiene techo: 65.535 bloques, unos 455 días, o 65.535 saltos de 512 segundos, unos 388 días.

Tres detalles separan un plan que funciona de uno que falla por poco. Uno: el script no mira el reloj. Compara su número con un campo de la transacción que gasta, nLockTime o nSequence, y son los nodos los que no la dejan entrar en un bloque antes de tiempo. Dos: un plazo por fecha no se compara con la hora del bloque, sino con la mediana de los 11 anteriores (BIP-113), que va alrededor de una hora por detrás. Tres: «a partir del bloque 900.000» quiere decir que la transacción entra como pronto en el 900.001.

Para tu plan, todo eso se resume en una regla: nada se programa al bloque ni a la hora. Pasar de bloques a fechas es una estimación, y el ritmo real de los bloques varía.

«Script y Timelocks (CLTV/CSV)» es larga. Para esta lección lee «Cuatro piezas, no dos», «Altura o tiempo: el umbral de 500.000.000», «La mediana de tiempo (BIP-113)», «El script no lee el reloj», «Primer bloque válido» y «Requisitos que se olvidan». La codificación de nSequence y los límites de older() quedan para la lección siguiente. De «Bitcoin Script» basta con «scriptSig y scriptPubKey» y «Opcodes clave», si te hace falta un repaso.