MSTR Cat

Blockchain/Nivel IV · El protocolo a fondo/4.1 Script/Lección 4

Bloqueos temporales: CLTV y CSV

El reloj que no se puede dar marcha atrás, y la mediana que lo mantiene honesto

MaterialesUn explorador de bloques con vistas de detalles de transacciones (por ejemplo, mempool.space o blockchain.com).Una calculadora capaz de manejar marcas de tiempo de UnixLos documentos de especificación BIP65, BIP68 y BIP113

Curiosidad

  1. ¿Por qué existe un campo de transacción para retrasar los gastos si una nueva transacción siempre puede eludirlo?
  2. ¿Cómo puede un minero individual mentir sobre el tiempo sin romper el consenso entre los demás?
  3. ¿Cuál es la diferencia entre esperar hasta un año específico y esperar dos años a partir de ahora?

Explorar

  1. Cada transacción de Bitcoin lleva un campo nLockTime, un valor de cuatro bytes que impide que la transacción sea minada antes de un momento determinado. Si el valor es inferior a 500.000.000, representa una altura de bloque; si está en o por encima de ese umbral, se trata de una marca de tiempo Unix. Sin embargo, este mecanismo solo aplica a esa instancia específica de transacción. Un usuario siempre puede crear una nueva transacción con los mismos insumos y un nLockTime cero, gastando las monedas de inmediato. El nLockTime por sí solo no ofrece seguridad para condiciones futuras, ya que no vincula al propio resultado de la transacción.
  2. OP_CHECKLOCKTIMEVERIFY (CLTV), propuesto por Peter Todd en BIP65 y activado en diciembre de 2015, cambia esta dinámica. CLTV es un opcode de script que compara el nLockTime de la transacción con un valor en la pila. Si el tiempo de bloqueo es menor que el valor requerido, la ejecución falla. Dado que esta verificación tiene lugar dentro del script de bloqueo de la salida, todo intento de gastar esa salida de transacción no gastada (UTXO) específica debe cumplir con esta condición. Esto crea un timelock absoluto: las monedas no pueden ser gastadas hasta que se alcance un punto de consenso global en términos de tiempo o altura del bloque.
  3. Los timelocks relativos funcionan de manera diferente, midiendo la duración en lugar de puntos absolutos. BIP68 reinterpreta el campo nSequence de las entradas de transacción, que anteriormente no se utilizaba con este fin, para codificar demoras relativas. OP_CHECKSEQUENCEVERIFY (CSV), definido en BIP112 y activado junto con BIP68 en julio de 2016, compara el valor de secuencia de la entrada con una duración requerida. Esto permite a los scripts imponer condiciones como “esta salida no puede ser gastada hasta 144 bloques después de que se haya confirmado”. La demora es relativa a la confirmación específica de ese UTXO, lo que la hace ideal para rutas de recuperación basadas en el tiempo o para el vencimiento de canales de pago.
  4. Los bloqueos basados en el tiempo también dieron a los mineros un incentivo para manipular las marcas de tiempo. Los mineros podían establecer las marcas de tiempo de los bloques hasta dos horas en el futuro para incluir más transacciones con timelock antes de lo previsto. BIP113, activado simultáneamente con los timelocks relativos en julio de 2016, introdujo el concepto de Median Time Past (MTP). Ahora, las verificaciones de los timelocks se comparan con la mediana de las marcas de tiempo de los once bloques anteriores en lugar de con la marca de tiempo del propio bloque. Esto asegura que ningún minero pueda influir significativamente en el “reloj”; el MTP suele estar aproximadamente una hora por detrás del tiempo real, lo que proporciona una referencia estable y verificable para todos los cálculos relacionados con los timelocks.
  5. Estos mecanismos sustentan aplicaciones complejas como los canales de pago y los protocolos de herencia. En los canales Lightning, los pagos en tránsito utilizan timelocks absolutos (CLTV) para que un pago no reclamado pueda ser reembolsado tras un plazo determinado, mientras que las demoras relativas (CSV) en las propias salidas de una parte le dan al otro lado tiempo para sancionar un estado del canal obsoleto. En cuanto a la herencia, los scripts pueden combinar requisitos de multisignatura con timelocks: quizás se necesiten dos claves para el acceso diario, pero después de un año de inactividad, una tercera clave (un heredero) se une al quórum mediante una condición CSV. Estos parámetros se fijan al crear la billetera y no pueden modificarse una vez que los fondos están bloqueados.
  6. Los timelocks son restricciones permanentes; se desbloquean a una hora determinada, pero no ofrecen mecanismo alguno para volver a bloquearlos o prolongar los retrasos después de su activación. Si un script codifica un valor de secuencia de 100 bloques, las monedas se vuelven utilizables exactamente cuando se alcanza esa altura relativa desde la confirmación. Los errores en la codificación pueden hacer que los fondos estén inaccesibles por más tiempo del previsto o, por el contrario, desbloquearlos demasiado pronto. Para verificarlo personalmente, abra cualquier transacción reciente en un explorador de bloques e inspeccione el campo nLockTime. La mayoría de las billeteras lo configuran con la altura actual del bloque, por lo que la transacción no puede colocarse en un bloque de altura inferior; eso elimina uno de los incentivos para que los mineros reescriban el bloque más reciente con el fin de obtener sus comisiones (‘fee sniping’).

Datos clave

  • Los valores de nLockTime inferiores a 500,000,000 se interpretan como alturas de bloque; los valores iguales o superiores son marcas de tiempo de Unix.
  • OP_CHECKLOCKTIMEVERIFY (BIP65) se activó en diciembre de 2015 y aplica timelocks absolutos a nivel de script.
  • OP_CHECKSEQUENCEVERIFY (BIP112) y BIP68 se activaron en julio de 2016, lo que permitió los timelocks relativos a través del campo nSequence.
  • El Tiempo Medio Pasado (MTP), introducido por BIP113, utiliza la mediana de los once bloques anteriores para evitar la manipulación del tiempo por parte de los mineros.
  • Las demoras en CSV se miden en relación con la altura o el momento de confirmación del UTXO específico que se está utilizando.
  • Las billeteras suelen establecer nLockTime en la altura actual del bloque para mitigar los riesgos de fee sniping.

Ejercicio nueve, seis, tres, uno

9ReunirEnumera 9 usos de los timelocks que puedas encontrar descritos (Lightning, bóvedas, herencia, custodia, intercambios atómicos y otros), indicando si cada uno utiliza un bloqueo absoluto o relativo.
6AgruparAgrupa los 9 en 6 según su finalidad: reembolso, plazo de penalización, herencia, bloqueo de ahorros, fecha límite del contrato u otro.
3DestilarReduce las 6 a 3 razones por las que un timelock debe estar en el script de la salida, en lugar de solo en la transacción de gasto.
1CristalizarEscribe una oración que explique cómo el MTP transforma los timelocks de un modelo basado en la confianza en los mineros a una regla de consenso determinista.

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

Abrir en la academia interactiva →

EN PT ZH JA KO RU DE FR MS