Operación de Canales y Encaminamiento

HTLCs: cómo se mueve el dinero por un canal — y por varios

• Eric de Castro
• Atualizado em 07/06/2026

⚡ Lightning · Técnico

En la página de canales en profundidad, los HTLCs aparecieron como "salidas extra" en la transacción de compromiso. Ahora vamos a abrir esa caja: qué es un HTLC, cómo hace que un pago sea atómico y cómo varios HTLCs encadenados mueven dinero a través de una red de desconocidos.

Qué es un HTLC

HTLC es Hash Time-Locked Contract — un contrato con candado de hash y plazo. En la práctica, es una salida que puede gastarse de dos maneras:

• Camino del hash (rescate). Quien revele el secreto (el preimage) que corresponde a un payment_hash se queda con el dinero.
• Camino del tiempo (reembolso). Si el secreto no aparece antes de un plazo (un OP_CHECKLOCKTIMEVERIFY, en altura de bloque), el pagador puede recuperar el dinero.

Es exactamente el "candado con secreto" de la explicación para principiantes — solo que ahora con nombre y forma. El receptor sortea un secreto aleatorio r, calcula payment_hash = SHA256(r) y coloca el hash en la invoice. El pago se completa cuando r se revela.

Prueba el candado de hash: sortea un secreto, ve el candado (hash) que va en la invoice, e intenta "rescatar":

Candado del HTLC

Candado del HTLC

Usa una preimage ficticia de 32 bytes, calcula payment_hash = SHA256(preimage) y simula si el HTLC se cumple por preimage o expira por CLTV.

Preimage ficticia — 32 bytes en hex

Generar ficticia

Candado (payment_hash = SHA256 del secreto)

Intentar rescatar el pago

Presenta una preimage. El nodo solo libera el valor si su SHA256 coincide con el payment_hash de arriba.

Preimage presentada

Verificar

Ventana de tiempo CLTV

El hashlock permite cumplir; el timelock define cuando el camino de timeout pasa a importar.

Altura actual

cltv_expiry del HTLC

delta minimo del intermediario

HTLC ofrecido vs. recibido

Cuando un HTLC está "en vuelo", se convierte en una salida en la transacción de compromiso de ambos lados — pero con papeles intercambiados:

• HTLC ofrecido (en la visión de quien envía): "pago a quien muestre el secreto; si no, recupero tras el timeout".
• HTLC recibido (en la visión de quien recibe): "recibo si muestro el secreto a tiempo; si no, el valor vuelve al otro lado".

Cada una de estas salidas tiene sus propias transacciones de rescate (HTLC-success, con el preimage) y de expiración (HTLC-timeout), y también respetan el to_self_delay y la revocación del canal — al fin y al cabo, un HTLC también forma parte de un estado que puede revocarse.

Encaminando por varios canales

Ahí está la clave de la red. Digamos que Alice quiere pagar a Carol, pero solo tiene canal con Bob, y Bob tiene canal con Carol. Carol genera una invoice con un payment_hash. Entonces:

1. Alice crea un HTLC para Bob con ese payment_hash.
2. Bob crea un HTLC para Carol con el mismo payment_hash.
3. Carol revela el secreto para rescatar el HTLC de Bob. Ahora Bob conoce el secreto.
4. Bob usa el secreto para rescatar el HTLC de Alice.

El secreto se propaga hacia atrás, desde el destino hasta la origen, liquidando cada HTLC en el camino. Como es el mismo hash en todos los saltos, o el pago llega al final y todos liquidan, o nadie liquida — esa es la atomicidad. Y Bob, por reenviar, se queda con una comisión (la diferencia entre lo que entró y lo que salió de su HTLC).

Los plazos disminuyen en dirección al destino

Hay un detalle de seguridad importante: los timeouts de los HTLCs no son iguales. El HTLC más cercano a la origen necesita expirar después que el que está más cerca del destino. Así, si el HTLC del extremo (Bob→Carol) expira, Bob todavía tiene un margen para reaccionar en el HTLC de entrada (Alice→Bob) antes de que expire también.

Ese margen que cada nodo exige es el cltv_expiry_delta. Por eso, al montar la ruta, el plazo (en altura de bloque) decrece en cada salto desde la origen hasta el destino. (Vamos a calcular eso en la página de búsqueda de camino.)

La "danza" del compromiso

Agregar (o quitar) un HTLC no es instantáneo: ambos lados tienen que acordar el nuevo estado y revocar el anterior. Según la BOLT 2, el intercambio de mensajes es más o menos este:

1. update_add_htlc — "quiero agregar este HTLC".
2. commitment_signed — "aquí está mi firma para la nueva transacción de compromiso".
3. revoke_and_ack — "vale, y aquí está el secreto que revoca mi estado anterior".

Eso ocurre en ambos sentidos hasta que los dos lados quedan comprometidos con el mismo estado nuevo. Para liquidar un HTLC, existe update_fulfill_htlc (con el preimage) o update_fail_htlc (si algo salió mal).

Fíjate que hasta aquí Bob sabe que está reenviando de Alice a Carol. Quien esconde el camino completo (para que Bob no sepa que Alice es la origen ni que Carol es el destino) es el enrutamiento onion — la siguiente página.