Timelock

Anna y Pavel pueden establecer que sus fondos compartidos se gasten en cualquier momento con la participación de ambos, pero que Anna pueda gastarlos sola únicamente después de una espera. Si Pavel deja de responder, la rama diferida ofrece una vía de recuperación acordada de antemano. Aquí, una rama es una de las opciones permitidas para gastar; cada una puede tener condiciones distintas. Por eso el bloqueo no tiene por qué impedir todas las opciones a la vez. Las reglas deben formar parte de la salida desde su creación. No basta con añadir después una nota de «desbloquear dentro de una semana» a un monedero normal. Incluso tras esperar, Anna necesitará la clave correspondiente y la información para construir una transacción válida. Timelock ayuda a controlar el acceso, pero no recupera claves perdidas. [3]

Un bloqueo absoluto establece un límite fijo que se guarda en el campo nLockTime de la transacción. Si una transacción tiene un nLockTime efectivo de altura 1 000 000, el primer bloque que puede satisfacer esa condición es el 1 000 001: la igualdad aún no basta. El bloqueo relativo mide, en cambio, una espera desde la confirmación de la salida gastada. Si la salida de Anna se crea en el bloque 1 000 000 y la rama exige esperar 6 bloques, su gasto puede cumplir esa condición como pronto en el bloque 1 000 006. Son cifras de ejemplo, no la altura actual de la red. Siguen vigentes las condiciones de las firmas, las demás entradas y otros bloqueos que pueda haber. Seis bloques tampoco equivalen exactamente a una hora: los bloques llegan a intervalos irregulares. La espera relativa no empieza al crear el monedero ni cuando Anna decide usar el dinero. [1] [2] [5]

Supongamos que acaba de cumplirse la espera de Anna. La red no actuará por ella. Alguien todavía debe construir una transacción o usar una ya preparada, aportar firmas, pagar una comisión y enviarla a la red. Solo entonces podrá un minero incluirla en un bloque. Satisfacer un Timelock es cumplir una condición, no reservar espacio ni activar una transferencia automática. Normalmente establece cuándo empieza a ser posible gastar, no cuándo esa posibilidad caduca por sí sola. Una reorganización sustituye parte de la cadena por otra rama válida. Esto puede cambiar la confirmación de una salida y el cálculo de su espera relativa. En una construcción propia hay que comprobar de antemano todas las ramas, el soporte del monedero y las copias de seguridad de claves y reglas de gasto; el tiempo no arregla una condición mal definida. [2] [5]

Las condiciones basadas en tiempo utilizan Median Time Past, abreviado MTP. Para el bloque que se evalúa, es la mediana de las marcas temporales de los últimos 11 bloques, terminando en el anterior. Ordena esos tiempos y toma el central, el sexto: eso es la mediana, no la media aritmética. BIP113 describe la regla y Bitcoin Core usa GetMedianTimePast para calcularla. El tiempo relevante no es, por tanto, la hora actual del teléfono de Anna ni la marca temporal del bloque propuesto. La medianoche del calendario no tiene por qué coincidir con el cumplimiento del bloqueo. Los bloqueos por altura esperan bloques; no descuentan segundos. [4]

Ahora podemos separar cuatro nombres de la documentación. nLockTime es un campo de toda la transacción que establece un límite absoluto. nSequence en una entrada expresa una espera relativa según BIP68. Pero nLockTime por sí solo no bloquea un UTXO, una salida aún no gastada, frente a otra transacción con ajustes distintos. Quien esté autorizado a gastar puede crear esa otra transacción si las reglas de la salida no se lo impiden. Bitcoin Script es el lenguaje con el que se expresan esas reglas de gasto. OP_CHECKLOCKTIMEVERIFY, o CLTV según BIP65, exige el ajuste absoluto correspondiente en la rama utilizada. OP_CHECKSEQUENCEVERIFY, o CSV según BIP112, comprueba el ajuste relativo, mientras que BIP68 exige la espera real. Ni CLTV ni CSV envían dinero ni aportan una firma que falte. Otra rama permitida puede ser utilizable con condiciones diferentes. [1] [2] [3]

Las siguientes secciones son una referencia técnica. Un campo es un dato guardado en la transacción; una entrada referencia una salida que se gasta. nSequence es un campo de cada entrada. Un valor especial puede desactivar el efecto de nLockTime, así que introducir una fecha no basta. nLockTime es un campo de 32 bits sin signo; cero desactiva la condición temporal absoluta. Si todas las entradas usan SEQUENCE_FINAL, de valor 0xffffffff, se ignora un nLockTime incumplido. Un bloqueo absoluto efectivo requiere al menos una entrada con otra nSequence. Se evalúa esa transacción concreta, sin congelar permanentemente sus entradas. [5] [7]

El mismo campo puede expresar dos cosas distintas y un umbral numérico las separa. Un Unix timestamp representa el tiempo en segundos desde el inicio de 1970 en UTC. El bloque candidato es aquel en el que se incluiría la transacción que se está comprobando. LOCKTIME_THRESHOLD vale 500000000. Un nLockTime inferior indica altura de bloque; un valor igual o mayor, un timestamp Unix. Con la comprobación absoluta activada, nLockTime debe ser estrictamente menor que la altura del bloque candidato o el MTP pertinente. La igualdad no basta; no es un importe, una altura media ni la fecha de activación del protocolo. [5] [8]

Un operando es un valor entregado a una instrucción; un opcode es la propia instrucción de Script. CLTV compara el requisito guardado en la rama con el ajuste de la transacción. Otra comprobación determina si la cadena ha avanzado lo suficiente. No es solo comparar la fecha de hoy con un número. OP_CHECKLOCKTIMEVERIFY exige un operando no negativo, del mismo tipo altura/tiempo que nLockTime y no mayor que nLockTime. La entrada de gasto correspondiente no puede tener nSequence 0xffffffff. El opcode no lee directamente un reloj ni la altura de la cadena; los ajustes se comprueban por separado al evaluar la validez temporal de la transacción. Siguen siendo necesarias las demás condiciones de Script. [1] [6]

El número nSequence contiene tanto la espera como interruptores que determinan su significado. Un bit es un cero o un uno de esa representación; activarlo puede habilitar una opción. Las posiciones de bits que siguen pertenecen al formato técnico, no son números de confirmaciones. En transacciones de versión 2 o superior, BIP68 activa una condición relativa para entradas cuyo bit 31 no esté activado. Los 16 bits inferiores indican la demora; el bit 22 selecciona unidades de 512 segundos y, en caso contrario, bloques. La demora en bloques parte de la altura de confirmación de la salida gastada. La temporal va del MTP del bloque anterior a esa confirmación al MTP anterior al bloque candidato. No cuenta desde la creación en el monedero. [2] [5]

CSV realiza una comprobación similar para la espera relativa. Una máscara selecciona los bits pertinentes de nSequence; disable flag es un interruptor de desactivación. Lightning Network es una red de canales de pago: sus participantes actualizan el reparto acordado de fondos bloqueados conjuntamente. La demora da tiempo a la otra parte para reaccionar si alguien publica un estado antiguo ya revocado. Una commitment transaction recoge el reparto; una clave de revocación permite a la otra parte gastar la salida correspondiente de una versión revocada mediante una rama de penalización. OP_CHECKSEQUENCEVERIFY con un operando activo no negativo exige versión al menos 2, disable flag de la entrada desactivado, igual tipo de demora y un valor de nSequence suficiente tras aplicar la máscara. BIP68 exige por separado la antigüedad real. CSV permite una rama de recuperación diferida. En una salida Lightning to_local, to_self_delay limita al propietario de la commitment transaction; la contraparte con la clave de revocación correcta puede usar la rama de penalización sin esa demora. [3] [9]

Dos números casi idénticos pueden tener efectos distintos. Los valores que comienzan por 0x se escriben en hexadecimal. NOP designa una instrucción que aquí no añade una restricción temporal. También importa si el interruptor está en la entrada de la transacción o en el valor entregado a CSV. El bit 31 es SEQUENCE_LOCKTIME_DISABLE_FLAG y desactiva la interpretación relativa BIP68 solo para esa entrada. El valor 0xfffffffe lo contiene, pero no es SEQUENCE_FINAL: permite nLockTime y CLTV efectivos. El valor 0xffffffff es final. Un operando CSV no negativo con disable flag activado actúa como NOP; ese flag activado en la entrada, en cambio, incumple una exigencia CSV activa. No deben confundirse los dos casos. [3] [7]

Un RPC es un comando para trabajar con tu nodo, el programa que verifica bloques y transacciones de Bitcoin. Decodificar solo convierte los datos guardados en un listado legible; el comando de prueba comprueba si una transacción firmada concreta pasaría. Mempool es la lista local de transacciones pendientes del nodo. En Core 31, el RPC decoderawtransaction muestra version, locktime y sequence de cada entrada. Para CLTV/CSV, inspecciona el Script realmente usado y la salida gastada; decodificar no demuestra validez. El RPC testmempoolaccept prueba un candidato firmado frente a la cadena actual, las reglas de validez de Bitcoin y las reglas locales del nodo para aceptar transacciones, sin aceptarlo en el mempool ni difundirlo. Revisa allowed y el motivo de rechazo; el éxito no promete una confirmación futura. [10] [11] [12]