Glosario / Transacciones y comisiones
Locktime
También se conoce como nLockTime.
- ¿Qué es el locktime?
- El locktime ocupa los últimos cuatro bytes de una transacción y establece la altura de bloque o la hora real a partir de la cual la red la aceptará en un bloque.
Piense en el locktime como en un cheque posdatado escrito en el protocolo. Un campo, dos significados, decididos por un umbral: cualquier valor por debajo de 500.000.000 cuenta bloques, y cualquier valor igual o superior cuenta segundos desde 1970. La mayoría de las transacciones que usted envíe llevarán un locktime, y este no hará nada más que protegerle de una sutil artimaña de los mineros.
Cómo funciona
El locktime está justo al final de la transacción serializada y se comprueba antes de considerar cualquier otro aspecto del gasto.
La regla del umbral es lo que hace que un solo campo cumpla dos funciones. Un locktime de 900.000 significa que la transacción no puede aparecer en un bloque por debajo de la altura 900.000. Un locktime de 1.800.000.000 es una marca de tiempo Unix y significa que la transacción no puede aparecer hasta que el tiempo mediano de los once bloques anteriores supere ese momento. La línea divisoria, 500.000.000, corresponde al 5 de noviembre de 1985: queda con holgura antes de que existiera bitcoin y con holgura por encima de cualquier altura de bloque verosímil. El campo tiene cuatro bytes, así que el momento máximo que puede expresar es el 7 de febrero de 2106.
Hay un interruptor. El locktime solo se hace cumplir si al menos una entrada tiene un número de secuencia inferior a 0xffffffff. Con todas las entradas en 0xffffffff, el campo se ignora por completo, y así funcionaron las transacciones durante años, antes de que las billeteras le encontraran un uso.
Ese uso es la protección contra el fee sniping (volver a minar el bloque anterior para quedarse con sus comisiones). Cuando las comisiones son altas, un minero que pierde la carrera por un bloque tiene un incentivo para intentar volver a minar el bloque anterior y robar sus comisiones en lugar de seguir construyendo hacia delante. Si las billeteras ponen el locktime de cada transacción en la punta actual de la cadena, esas transacciones pasan a ser inválidas en cualquier bloque anterior, lo que elimina la mayor parte del botín y el incentivo. Bitcoin Core lo hace en los gastos corrientes, y aproximadamente una vez de cada diez elige de manera uniforme una altura entre los 100 bloques anteriores, para que las transacciones de distinto software de billetera no se distingan unas de otras.
Dónde aparece
Abra cualquier transacción reciente en un explorador de bloques y el campo locktime contendrá normalmente un número cercano a la altura en la que se minó.
Ese es el comportamiento de protección contra el fee sniping, y verlo es una leve huella digital del software que construyó el pago. Las billeteras que dejan el campo en cero también están anunciando algo. Las empresas de análisis de cadena leen este campo precisamente porque muy pocos usuarios piensan en él.
Los usos deliberados son más limitados. Un locktime en el futuro crea una transacción que puede firmarse y entregarse ahora, pero no difundirse hasta más tarde, y esa es la base de los esquemas de herencia sencillos y de las rutas de reembolso. Las transacciones de cierre forzado de Lightning y los intercambios submarinos usan bloqueos temporales (timelocks) para que una contraparte que desaparezca no pueda dejar su dinero atrapado para siempre. Quien construya estas transacciones debería tener en cuenta su punto débil evidente: una transacción bloqueada solo vale lo que valen las monedas que la respaldan, y si el remitente gasta antes esas entradas de otra forma, la transacción posdatada pasa a no valer nada.
Locktime frente a OP_CHECKLOCKTIMEVERIFY
El locktime restringe una transacción; el opcode (código de operación) OP_CHECKLOCKTIMEVERIFY restringe una moneda. La diferencia importa porque solo uno de los dos obliga a alguien que no sea la persona que firma.
Un locktime lo elige quien construye la transacción, así que no protege a nadie: un remitente puede simplemente construir otra transacción sin él. OP_CHECKLOCKTIMEVERIFY, definido en el BIP65 y activo en la red desde el bloque 388.381, el 14 de diciembre de 2015, pone la condición en el script de bloqueo de la propia salida. Cualquier gasto futuro de esa moneda debe llevar a su vez un locktime igual o posterior al punto indicado, y ninguna firma puede eludirlo. Eso es lo que hace que un bloqueo temporal pase de ser una intención a ser una regla, y es la razón por la que los diseños de bóveda, escrow (depósito en garantía) y herencia se escriben con el opcode y no con el campo.