Inicio Arquitectura técnica HTLC: contratos de tiempo bloqueado por hash

HTLC: contratos de tiempo bloqueado por hash

Un HTLC combina un candado criptográfico (hashlock) con un candado temporal (timelock) para permitir pagos enrutados seguros entre partes que no confían entre sí, siendo la primitiva fundamental de Lightning Network.

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

  1. Carol genera R, calcula H = SHA256(R) y lo envía a Alice dentro de una invoice.
  2. Alice crea un HTLC con Bob: "Bob puede cobrar X sats si revela R antes del bloque 900.100; si no, yo recupero los fondos".
  3. Bob crea un HTLC con Carol: "Carol puede cobrar X − fee sats si revela R antes del bloque 900.050". El plazo es menor, dando a Bob margen de recuperación.
  4. Carol revela R para cobrar su HTLC a Bob.
  5. 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 H comú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)