Vai al contenuto
Financial Context Wiki

Contratto con hash lock e time lock (HTLC)

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.

Aggiornato

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.

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.

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.

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».

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.

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à.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...