La respuesta corta
El locktime de una transacción, almacenado como nLockTime, fija el primer punto en que
una transacción de Bitcoin puede incluirse en un bloque. El valor se interpreta como una
altura de bloque cuando es inferior a 500.000.000 y como un timestamp cuando alcanza o
supera ese umbral.
No hace válida una transacción por sí solo. Las entradas, firmas e importes todavía deben cumplir las reglas normales. El locktime añade una condición: la altura o el tiempo elegidos deben haber pasado antes de que los mineros puedan incluir la transacción.
Cómo funciona
Bitcoin Core 31.1 compara nLockTime con la altura del bloque candidato o, para un bloqueo
basado en tiempo, con la mediana de tiempo pasada de la red. BIP 113
define ese tiempo como la mediana de los timestamps de los 11 bloques anteriores. Así el
reloj avanza de forma monótona sin confiar en el timestamp de un solo minero.
El límite es estricto. Una transacción con locktime de altura 900 todavía llega demasiado
pronto para el bloque 900 y pasa a ser elegible en el bloque 901. La función
IsFinalTx
de Bitcoin Core implementa esa comparación.
Hay otro detalle necesario. Si todas las entradas usan el valor de secuencia final
0xffffffff, Bitcoin Core ignora nLockTime. Al menos una entrada debe usar un valor de
secuencia inferior para que el locktime de la transacción tenga efecto. La
definición actual de transacción
documenta ambos campos.
Un ejemplo concreto
Supongamos que dos partes preparan una transacción de reembolso con locktime de altura. Pueden firmarla y guardarla antes de la altura objetivo, pero un minero todavía no puede incluirla. Cuando la cadena supera esa altura, la misma transacción firmada puede pasar a ser elegible sin que ninguna de las partes la modifique.
Este patrón resulta útil para protocolos que necesitan una salida alternativa demorada.
No es lo mismo que bloquear el propio UTXO. Un nLockTime simple
retrasa una transacción concreta. Todavía puede existir otra transacción válida que gaste
la misma salida.
Lo que suele confundirse
El locktime no es una alarma de reloj, una promesa de confirmación ni una reserva de espacio en un bloque. Solo impide confirmar antes de un límite. Después, la transacción aún debe llegar a los mineros y ofrecer una comisión competitiva.
Tampoco es lo mismo que OP_CHECKLOCKTIMEVERIFY. BIP 65
permite que el script de una salida exija un locktime compatible en cualquier transacción
que la gaste. Eso puede impedir que la salida se gaste antes del límite. El nLockTime de
una transacción solo demuestra que esa transacción preparada debe esperar.