HTLC: contratos de tiempo bloqueado por hash
Qué es un HTLC
Un HTLC (Hashed Time-Locked Contract) es un tipo de contrato inteligente nativo de Bitcoin que bloquea un pago bajo dos condiciones simultáneas:
- Hashlock: el receptor puede reclamar los fondos si revela un preimage (un secreto) cuyo hash coincide con un valor prefijado.
- Timelock: si el receptor no reclama antes de un plazo, el emisor puede recuperar los fondos.
La combinación produce una primitiva poderosa: permite enviar un pago condicional a través de una cadena de intermediarios sin necesidad de confiar en ninguno de ellos. Es la pieza que hace posible el enrutamiento en Lightning Network.
Los dos mecanismos en detalle
Hashlock: prueba de conocimiento de un preimage
El hashlock es un script de Bitcoin que exige, para gastar el output, revelar un valor R tal que SHA256(R) = H, donde H está codificado en el propio script. R se llama preimage y H se llama payment hash. El receptor original genera R al azar y comparte H con el emisor a través de una invoice. Solo el receptor conoce R, así que solo él puede destrabar los HTLCs en cada salto.
Timelock: CLTV y CSV
- CLTV (
OP_CHECKLOCKTIMEVERIFY, BIP-65): bloquea un output hasta una altura de bloque o timestamp UNIX absoluto. Ejemplo: "este output no puede gastarse antes del bloque 900.000". - CSV (
OP_CHECKSEQUENCEVERIFY, BIP-112): bloquea un output durante un número relativo de bloques desde su confirmación. Ejemplo: "no puede gastarse hasta que pasen 144 bloques desde que fue minado".
Cómo funciona un HTLC en Lightning
Imaginemos un pago de Alice a Carol, con Bob como nodo intermedio: Alice → Bob → Carol
- Carol genera
R, calculaH = SHA256(R)y lo envía a Alice dentro de una invoice. - Alice crea un HTLC con Bob: "Bob puede cobrar X sats si revela
Rantes del bloque 900.100; si no, yo recupero los fondos". - Bob crea un HTLC con Carol: "Carol puede cobrar X − fee sats si revela
Rantes del bloque 900.050". El plazo es menor, dando a Bob margen de recuperación. - Carol revela
Rpara cobrar su HTLC a Bob. - Bob, ahora que conoce
R, la usa para cobrar su HTLC a Alice.
Si Carol no revela R, ningún HTLC se ejecuta y los fondos vuelven al expirar el timelock. Bob nunca necesita confiar en Alice ni en Carol.
Por qué los timelocks son decrecientes a lo largo de la ruta
El margen temporal (cltv_delta) entre saltos es esencial. Si todos los HTLCs vencieran a la vez, un nodo intermedio podría quedar en una "carrera": aprende el preimage un bloque antes del vencimiento y debe publicarlo on-chain urgentemente. El decrecimiento garantiza ventana de seguridad para cada intermediario.
Limitaciones y ataques conocidos
Privacidad del payment hash
El mismo H se usa en todos los saltos de una ruta. Cualquier par de nodos puede correlacionar sus HTLCs y deducir que pertenecen al mismo pago, rompiendo parcialmente la privacidad del onion routing.
Channel jamming
Un atacante puede enviar HTLCs falsos y nunca revelar la preimage, congelando la liquidez de los canales hasta que expiren los timelocks. El coste para el atacante es casi nulo (las comisiones solo se pagan si el pago se completa). Se trabaja en mitigaciones basadas en upfront fees.
Wormhole attack
Si dos nodos no adyacentes colaboran, pueden saltar al intermediario entre ellos: cuando el nodo posterior aprende la preimage, la pasa directamente al anterior fuera de banda, dejando al nodo del medio con un HTLC pendiente sin cobrar su comisión.
PTLCs: la evolución post-Taproot
Los PTLCs (Point Time-Locked Contracts) reemplazan el hashlock por un punto en la curva secp256k1, aprovechando la linealidad de las firmas Schnorr. En lugar de revelar un preimage, el receptor "completa" una adaptor signature. Las ventajas:
- Cada salto usa un punto distinto: el pago no es correlacionable por un
Hcomún. La privacidad del onion routing se recupera plenamente. - On-chain son indistinguibles de un gasto Taproot normal, mientras que los HTLCs on-chain son claramente reconocibles.
La adopción de PTLCs requiere cambios coordinados en los BOLT y en las implementaciones. Sigue siendo trabajo en progreso en 2026.
Un HTLC es, en esencia, un "te pago si me demuestras que sabes el secreto, y si no, me devuelves mi dinero en X bloques". Todo Lightning se construye sobre esta idea simple.
Errores habituales
- Creer que los HTLCs solo existen en Lightning: son scripts de Bitcoin válidos on-chain y se usan también en atomic swaps entre cadenas.
- Confundir CLTV (timelock absoluto) con CSV (timelock relativo). Ambos se usan en Lightning pero para propósitos distintos.
- Asumir que el payment hash identifica al pagador o receptor: solo identifica el pago, pero sí correlaciona saltos de una misma ruta.
- Pensar que el channel jamming roba fondos: no los roba, pero inutiliza liquidez temporalmente.
- Creer que PTLCs ya están activos en Lightning: Taproot habilita la criptografía, pero la estandarización y despliegue en las implementaciones siguen en curso.
Conceptos relacionados
Fuentes primarias
- BOLT 3: Bitcoin Transaction and Script Formats
- BOLT 4: Onion Routing Protocol
- BIP-65: OP_CHECKLOCKTIMEVERIFY (Todd, 2014)
- BIP-112: CHECKSEQUENCEVERIFY (Friedenbach et al., 2015)
- Poon, Dryja — "The Bitcoin Lightning Network" (2016)