---
title: "Contratto con hash lock e time lock (HTLC)"
description: "Un HTLC rende un pagamento riscuotibile con una preimmagine prima della scadenza e rimborsabile tramite un altro percorso dopo. Spiega come coordina canali di pagamento e atomic swap e dove può fallire."
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.

# Contratto con hash lock e time lock (HTLC)

> Solo a fini didattici; non è consulenza finanziaria, legale o di sicurezza. La sicurezza di un HTLC dipende da script o contratti esatti, regole delle catene, politica di conferma, commissioni, monitoraggio e azione tempestiva.

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

## Risposta diretta

Un contratto con hash lock e time lock (HTLC) è un pagamento condizionato con due percorsi di spesa concorrenti. Prima della scadenza il beneficiario può riscuotere rivelando un valore `x` il cui hash corrisponde al valore impegnato `h = H(x)` e soddisfacendo firme o autorizzazioni. Dopo, il pagatore può usare il rimborso. L'ordine esatto al confine è definito da catena e contratto, non dalla parola «prima».

L'hash lock collega azioni: conoscere la stessa preimmagine può consentire di regolare un pagamento in entrata dopo averne pagato uno in uscita. Il time lock limita la durata della condizione. I canali di pagamento inoltrano così i pagamenti; gli atomic swap coordinano trasferimenti su sistemi separati.

Un HTLC non è automaticamente trustless, atomico, privato o autoeseguibile. Servono codice corretto, hash e codifica compatibili, scadenze sfalsate, ipotesi di finalità, accesso alle commissioni, monitoraggio e conferma tempestiva. L'HTLC Lightning è un progetto Bitcoin specificato; altri contratti possono avere semantica diversa.

- **Ramo hash:** rivela la preimmagine e soddisfa l'autorizzazione di successo finché il percorso è valido.
- **Ramo temporale:** soddisfa l'autorizzazione di rimborso quando il blocco assoluto o relativo è maturo.

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

## Funzionamento

Per un pagamento Bob sceglie una preimmagine nuova e imprevedibile `x`, calcola `h = H(x)` e consegna `h` ad Alice. Alice blocca fondi con regole che impegnano `h`, identificano gli autorizzati e fissano la scadenza `T`.

- Alice verifica algoritmo, codifica, importo, asset, beneficiario, rimborso, catena e scadenza prima di finanziare.
- Bob verifica l'output realmente finanziato o il contratto distribuito, non una bozza o l'interfaccia.
- Se Bob riscuote dal ramo di successo, fornisce `x`; la logica verifica `H(x) = h` e l'autorizzazione.
- Pubblicare o trasmettere `x` può permettere ad Alice o a un intermediario di regolare un altro HTLC con lo stesso hash.
- Se il successo non avviene in tempo, il rimborso diventa valido in `T`; non viene però trasmesso né confermato automaticamente.
- Occorre ancora preparare o conservare la transazione, pagare abbastanza, inviarla, monitorare sostituzioni e conflitti e ottenere conferme.
- Dopo aver rivelato `x` a una controparte o catena pubblica, va trattato come pubblico e non riutilizzato altrove.

Bitcoin distingue blocchi assoluti e relativi. `OP_CHECKLOCKTIMEVERIFY` del BIP 65 impedisce la spesa fino all'altezza o tempo di blocco codificato nel locktime; `OP_CHECKSEQUENCEVERIFY` del BIP 112 attende l'età relativa dell'input. Anche i campi della transazione devono essere compatibili. Un time lock è una regola di convalida, non uno scheduler.

In Lightning, `update_add_htlc` contiene importo, `payment_hash` e `cltv_expiry`. Ogni hop offre un HTLC in uscita che scade prima del corrispondente in entrata, lasciando tempo per conoscere la preimmagine e riscuotere a monte. BOLT 3 definisce output di commitment, percorsi `HTLC-success` e `HTLC-timeout`, firme, revoca, taglio dust e ritardi; due rami non implementano un canale completo.

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

## Esempio

Come esempio didattico, Alice scambia `1 BTC` per i `20 ETH` di Bob. Mostra solo l'ordine: la produzione richiede codice verificato per ogni catena e non deve copiare queste durate nominali.

- Alice genera nuovi `x` e `h = H(x)` e blocca `1 BTC` affinché Bob riscuota con la preimmagine e Alice rimborsi dopo `48 hours`.
- Verificati transazione Bitcoin e criteri di conferma, Bob blocca `20 ETH` con hash e codifica compatibili; il successo di Alice termina dopo `24 hours`, poi resta il rimborso di Bob.
- Prima di rivelare `x` per `20 ETH`, Alice verifica ID Ethereum, bytecode, indirizzo, asset, importo, parti, `h` e i due percorsi.
- Bob ottiene `x` dalla riscossione o dal messaggio concordato e tenta il successo Bitcoin prima della scadenza successiva.
- Se lo scambio si ferma prima, ogni rimborso diventa valido solo secondo la propria catena e deve essere inviato e confermato.

La differenza tra `48 hours` e `24 hours` è un margine di reazione, non un valore universale. Occorre modellare riorganizzazioni, tempo dei blocchi, finalità, esecuzione, relay, mempool, commissioni, censura e latenza su entrambi i sistemi. Il secondo attore non deve procedere solo perché l'interfaccia dice «confermato».

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

## Rischi

- **Impegno errato:** algoritmo, lunghezza o codifica differiscono e lo stesso `x` non vale su entrambi i lati.
- **Artefatto errato:** output, ID catena, indirizzo, bytecode, asset, importo, beneficiario o rimborso divergono dall'interfaccia.
- **Ordine insicuro:** scadenze uguali o troppo vicine impediscono la riscossione a monte dopo il pagamento a valle.
- **Errore di confine:** altezza, tempo blocco, timestamp, età relativa e confronti `<` e `<=` non equivalgono.
- **Nessun rimborso automatico:** la maturità rende valida la spesa; wallet, nodo, utente o watcher deve agire.
- **Commissione e dust:** la riscossione può essere antieconomica, tagliata, bloccata o impossibile senza asset nativo.
- **Conferma e riorganizzazione:** vedere transazione o preimmagine non significa regolamento irreversibile.
- **Corsa e congestione:** successo, timeout, sostituzione, conflitto o ritardo malevolo consumano il margine.
- **Implementazione:** errori di script, contratto, wallet, firma, nonce, RPC o client possono invalidare i percorsi.
- **Monitoraggio:** una parte offline può perdere rivelazione, scadenza, chiusura forzata, sostituzione o ultimo invio utile.
- **Privacy:** hash riutilizzati, preimmagini, importi, tempi ed eventi possono correlare trasferimenti.
- **Opzionalità e blocco:** una parte può immobilizzare liquidità e ritirarsi; completamento e compenso non sono garantiti.

Prima di rischiare valore, provare successo e rimborso con importo trascurabile, registrare artefatti e scadenze, riservare commissioni e assegnare monitoraggio e invio in caso di guasto.

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

## Idee sbagliate comuni

- **«I fondi tornano automaticamente alla scadenza».** Di solito si abilita solo il rimborso; qualcuno deve inviarlo e confermarlo.
- **«Soddisfare `H(x) = h` è l'intero contratto».** Contano anche firme, rami, campi, regole, revoca e autorizzazione.
- **«La stessa scadenza sui due lati è equa».** Intermediario o secondo attore necessita margine a monte dopo aver appreso `x`.
- **«Una preimmagine visibile garantisce tempo».** Conferme, riorganizzazione, congestione, commissioni e censura possono esaurirlo.
- **«Atomico significa due catene cambiate in una transazione indivisibile».** Si coordinano stati separati; restano annullamento, rimborso e stati temporanei unilaterali.
- **«Gli HTLC sono anonimi ed eliminano la fiducia».** Perdono segnali e dipendono da codice, catene, chiavi, monitoraggio e operatività.

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

## Argomenti correlati

- [Hash crittografico](/it/crypto/cryptographic-hash/)
- [Wallet MPC](/it/crypto/mpc-wallet/)
- [Rischio dei moduli multifirma](/it/crypto/multisig-module-risk/)
- [Smart contract](/it/crypto/smart-contract/)
- [Canali di stato](/it/crypto/state-channels/)

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

## Fonti

- [BIP 65: OP_CHECKLOCKTIMEVERIFY](https://bips.dev/65/) - Bitcoin Improvement Proposals (consultato: 2026-08-20)
- [BIP 112: CHECKSEQUENCEVERIFY](https://bips.dev/112/) - Bitcoin Improvement Proposals (consultato: 2026-08-20)
- [BOLT #2: protocollo peer per i canali](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) - Lightning BOLTs (consultato: 2026-08-20)
- [BOLT #3: formati di transazioni e script Bitcoin](https://github.com/lightning/bolts/blob/master/03-transactions.md) - Lightning BOLTs (consultato: 2026-08-20)
- [BOLT #4: protocollo di onion routing](https://github.com/lightning/bolts/blob/master/04-onion-routing.md) - Lightning BOLTs (consultato: 2026-08-20)

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