---
title: "Contrato con bloqueo de hash y tiempo (HTLC)"
description: "Un HTLC permite cobrar un pago con una preimagen antes del vencimiento y reembolsarlo por otra ruta de gasto después. Explica cómo coordina canales de pago e intercambios atómicos y dónde puede fallar."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Contrato con bloqueo de hash y tiempo (HTLC)

> Solo con fines educativos; no constituye asesoramiento de inversión, jurídico ni de seguridad. La seguridad de un HTLC depende de los scripts o contratos exactos, las reglas de las cadenas, la política de confirmación, las comisiones, la vigilancia y la actuación oportuna.

<a id="answer"></a>

## Respuesta directa

Un contrato con bloqueo de hash y tiempo (HTLC) es un pago condicional con dos rutas de gasto rivales. Antes del vencimiento, el receptor puede cobrar revelando un valor `x` cuyo hash coincida con el valor comprometido `h = H(x)` y cumpliendo las firmas o autorizaciones exigidas. Después, el pagador puede usar la ruta de reembolso. El orden exacto en el límite lo determinan la cadena y el contrato, no la palabra «antes».

El bloqueo de hash enlaza acciones: conocer la misma preimagen puede permitir cobrar un pago entrante relacionado tras pagar otro saliente. El bloqueo temporal limita cuánto permanece condicional el dinero. Los canales de pago usan estas propiedades para reenviar pagos y los intercambios atómicos para coordinar transferencias en sistemas distintos.

Un HTLC no es automáticamente sin confianza, atómico, privado ni autoejecutable. También exige scripts o contratos correctos, hash y codificación compatibles, vencimientos escalonados, supuestos de finalidad, acceso a comisiones, vigilancia y confirmación antes del plazo. El HTLC de Lightning es un diseño Bitcoin especificado; otro contrato puede tener semántica distinta.

- **Rama de hash:** revela la preimagen y satisface la autorización de éxito mientras la ruta sea válida.
- **Rama de tiempo:** satisface la autorización de reembolso cuando madura el bloqueo absoluto o relativo.

<a id="mechanism"></a>

## Cómo funciona

Para un pago, Bob elige una preimagen nueva e impredecible `x`, calcula `h = H(x)` y entrega `h` a Alice. Alice bloquea fondos con reglas que comprometen `h`, identifican a las partes autorizadas y fijan el vencimiento `T`.

- Alice comprueba algoritmo, codificación, importe, activo, receptor, destino de reembolso, cadena y vencimiento antes de financiar.
- Bob verifica la salida realmente financiada o el contrato desplegado, no un borrador ni la interfaz.
- Si Bob cobra por la rama de éxito, aporta `x`; la lógica verifica `H(x) = h` y la autorización.
- Publicar o transmitir `x` puede permitir que Alice o un intermediario liquide otro HTLC con el mismo hash de pago.
- Si no se usa a tiempo la rama de éxito, el reembolso pasa a ser válido en `T`; eso no lo transmite ni confirma.
- Aún hay que preparar o conservar la transacción, pagar comisión suficiente, enviarla, vigilar reemplazos y conflictos y obtener confirmaciones.
- Tras revelar `x` a una contraparte o cadena pública, debe tratarse como público y no reutilizarse en otra condición.

Bitcoin distingue bloqueos absolutos y relativos. `OP_CHECKLOCKTIMEVERIFY` de BIP 65 impide gastar hasta la altura o tiempo de bloque codificado por el tiempo de bloqueo; `OP_CHECKSEQUENCEVERIFY` de BIP 112 espera a que la entrada alcance una edad relativa. Los campos de la transacción también deben ser compatibles. Un bloqueo temporal es una regla de validación, no un programador.

En Lightning, `update_add_htlc` lleva importe, `payment_hash` y `cltv_expiry`. Cada salto ofrece un HTLC saliente que vence antes que el entrante correspondiente, dejando tiempo para conocer la preimagen y cobrar aguas arriba. BOLT 3 define las rutas de salida de compromiso, `HTLC-success` y `HTLC-timeout`, además de firmas, revocación, recorte por polvo y demoras; el esquema de dos ramas no implementa un canal completo.

<a id="example"></a>

## Ejemplo

Supongamos, solo como ejemplo didáctico, que Alice cambia `1 BTC` por `20 ETH` de Bob. Solo ilustra el orden: una implementación real necesita código revisado para cada cadena y no debe copiar estos plazos nominales.

- Alice genera `x` y `h = H(x)` nuevos y bloquea `1 BTC` para que Bob cobre con la preimagen y Alice reembolse tras `48 hours`.
- Tras verificar la transacción Bitcoin y su política de confirmación, Bob bloquea `20 ETH` con hash y codificación compatibles; la ruta de Alice termina tras `24 hours` y luego queda la de reembolso de Bob.
- Antes de revelar `x` para cobrar `20 ETH`, Alice verifica ID de cadena Ethereum, bytecode, dirección, activo, importe, partes, `h` y ambas rutas invocables.
- Bob obtiene `x` del cobro o del mensaje acordado e intenta la ruta de éxito Bitcoin antes de su plazo posterior.
- Si el intercambio se detiene antes de revelar, cada reembolso solo se habilita conforme a su cadena; cada parte debe enviarlo y confirmarlo.

La diferencia entre `48 hours` y `24 hours` es un margen de reacción, no un valor universalmente seguro. Hay que modelar reorganizaciones, tiempo de bloque, finalidad, ejecución, relés, mempool, comisiones, censura y latencia en ambos sistemas. La segunda parte no debe actuar solo porque una interfaz diga «confirmado».

<a id="risks"></a>

## Riesgos

- **Compromiso incorrecto:** algoritmo, longitud o codificación difieren entre tramos y el mismo `x` no sirve en ambos.
- **Artefacto incorrecto:** salida, ID de cadena, dirección, bytecode, activo, importe, receptor o reembolso no coinciden con la interfaz.
- **Orden inseguro:** vencimientos iguales o demasiado próximos impiden cobrar aguas arriba después de pagar aguas abajo.
- **Error de límite:** altura, tiempo de bloque, marca temporal, edad relativa y comparaciones `<` y `<=` no equivalen.
- **Sin reembolso automático:** la madurez solo valida el gasto; una cartera, nodo, usuario o vigilante debe actuar.
- **Comisión y polvo:** el cobro puede no ser rentable, recortarse en Lightning, atascarse o requerir el activo nativo de comisión.
- **Confirmación y reorganización:** ver una transacción o preimagen no implica liquidación irreversible.
- **Carrera y congestión:** éxitos, tiempos agotados, reemplazos, conflictos o retrasos maliciosos consumen el margen.
- **Implementación:** fallos de script, contrato, cartera, firma, nonce, RPC o cliente pueden anular las rutas.
- **Vigilancia:** una parte desconectada puede perder revelación, vencimiento, cierre forzoso, reemplazo o última hora útil.
- **Privacidad:** hashes reutilizados, preimágenes, importes, tiempos y eventos pueden correlacionar transferencias.
- **Opcionalidad y bloqueo:** una parte puede inmovilizar liquidez y abandonar; no se garantizan finalización ni compensación.

Antes de arriesgar valor, pruebe éxito y reembolso con un importe insignificante, registre artefactos y plazos, reserve comisiones y asigne vigilancia y transmisión para fallos.

<a id="misconceptions"></a>

## Errores comunes

- **«Los fondos vuelven automáticamente al vencer».** Normalmente solo se habilita el reembolso; alguien debe transmitirlo y confirmarlo.
- **«Cumplir `H(x) = h` es todo el contrato».** También importan firmas, ramas, campos, reglas de cadena, revocación y autorización.
- **«El mismo vencimiento en ambos tramos es justo».** El intermediario o segundo actor necesita margen aguas arriba tras conocer `x`.
- **«Una preimagen visible garantiza tiempo para cobrar».** Confirmaciones, reorganización, congestión, comisiones y censura pueden agotarlo.
- **«Atómico significa que ambas cadenas cambian en una transacción indivisible».** Se coordinan estados separados; siguen existiendo aborto, reembolso y estados unilaterales temporales.
- **«Los HTLC son anónimos y eliminan toda confianza».** Filtran señales y dependen de código, cadenas, claves, vigilancia y operación.

<a id="related"></a>

## Temas relacionados

- [Hash criptográfico](/es/crypto/cryptographic-hash/)
- [Cartera MPC](/es/crypto/mpc-wallet/)
- [Riesgo de módulos multifirma](/es/crypto/multisig-module-risk/)
- [Contrato inteligente](/es/crypto/smart-contract/)
- [Canales de estado](/es/crypto/state-channels/)

<a id="sources"></a>

## Fuentes

- [BIP 65: OP_CHECKLOCKTIMEVERIFY](https://bips.dev/65/) - Bitcoin Improvement Proposals (consultado: 2026-08-20)
- [BIP 112: CHECKSEQUENCEVERIFY](https://bips.dev/112/) - Bitcoin Improvement Proposals (consultado: 2026-08-20)
- [BOLT #2: protocolo entre pares para gestionar canales](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) - Lightning BOLTs (consultado: 2026-08-20)
- [BOLT #3: formatos de transacciones y scripts de Bitcoin](https://github.com/lightning/bolts/blob/master/03-transactions.md) - Lightning BOLTs (consultado: 2026-08-20)
- [BOLT #4: protocolo de enrutamiento cebolla](https://github.com/lightning/bolts/blob/master/04-onion-routing.md) - Lightning BOLTs (consultado: 2026-08-20)

Source: https://wiki.fcontext.com/es/crypto/htlc/index.mdx