Mono-directional Payment Channels

1. A deposita fondi in un multisig
2. Si crea una tx di "refund" con timelock
3. A Crea degli stati successivi mettendo la propria firma
4. Prima del timelock B aggiunge la propria firma e pubblica la tx
   • È incentivato a pubblicare l'ultimo stato perché più conveniente per lui

Timelock in Bitcoin

• Campo nLockTime - uint a 32 bit nella transazione
• Firmato dal SIGHASH più utilizzato (SIGHASH_ALL)
• Se 0 la tx può essere minata in qualunque blocco
• Se < 500 * 1e6 viene interpretato come block height
• Altrimenti interpretato come UNIX Timestamp
  • Calcolato come la media dei timestamp degli ultimi 11 blocchi

Bitcoin Script

• Linguaggio volutamente non Touring-complete
• Stack based
• Composto da molti op-code
• Permette di creare diversi "contratti"
• scriptPubKey - determina le condizioni per spendere un output
• scriptSig - soddisfa le condizioni
• Eseguiti in ordine, se ci sono errori la transazione non è valida

Esempio

OP_CSV e OP_CLTV

Timelock a livello di Script, non di transazione

• Permette di creare contratti che contengono timelock relativi
• OP_CSV abbreviazione di OP_CHECKSEQUENCEVERIFY
• Sfrutta il campo nSequence degli input
  • Originariamente utilizzato per poter "aggiornare" una transazione nella mempool
• Introdotto con un soft-fork (BIP 112)

• Come timelock tradizionali
• OP_CLTV abbreviazione di OP_CHECKLOCKTIMEVERIFY
• Sfrutta sempre il campo nLockTime delle transazioni
• Introdotto con un soft-fork (BIP 65)

Punishment-based Payment Channels

• A e B depositano fondi in un multisig
• Si crea lo stato iniziale del canale
  • Due versioni "specchiate", diversa per le due parti
• Permette la chiusura unilaterale (senza collaborazione) ma i fondi di chi chiude saranno bloccati per un certo periodo di tempo
• Permette anche di "punire" l'altra parte se si comporta male tramite una "revocation key"
  • Ad ogni stato viene scambiata la key dello stato precedente
• Incentivo a comportarsi bene
  • Rischio di perdere tutta la mia parte se vengo punito

"eltoo" Payment Channels

• A e B creano due multisig (uno di "update" e uno di "settlement")
• A e B depositano i fondi in quello di update
• A e B si scambiano una tx di update:
  • Può spendere qualunque output depositato nel multisig di update
  • Crea un nuovo output che può essere speso subito con il keypair di update o più tardi con il keypair di settlement
• A e B si scambiano una tx di settlement che spende quella di update con il keypair di update
• Nessun incentivo a comportarsi "bene":
  • Se mando un update vecchio l'altra parte può ri-spenderlo nella finestra di tempo prima del settlement

Multi-hop Payments. HTLC FTW

• Creare canali direttamente con molte persone non è efficiente
• Sarebbe bello poter "prendere in prestito" il canale di qualcun altro per fare un pagamento
• HTLC permettono di implementare una soluzione molto elegante
  • HTLC = Hashed Time-lock Contract
  • Contratto che permette di sbloccare dei fondi presentando una pre-image entro un certo timeout
  • Scaduto il timeout i fondi tornano al mittente

Esempio

Stato iniziale: A <-> B <-> C. A vuole pagare C

1. C genera un segreto e ne calcola l'hash che passa a B
2. B crea un HTLC che permette a C di ottenere i fondi se mostra il segreto entro un giorno. Scaduto il timeout B recupera i propri soldi
3. A crea un HTLC che permette a B di ottenere i fondi se mostra il segreto entro un giorno. Scaduto il timeout A recupera i propri soldi
4. C verifica la catena di HTLC e, se soddisfatto, rivela il segreto, prendendo i fondi da B
5. B copia il segreto e può prendere i soldi da A

Principali implementazioni

• Una specifica unificata "Basis of Lightning Technology" (BOLT)
• Tre principali implementazioni
  • c-lightning (Blockstream - C)
  • lnd (Lightning Labs - Golang)
  • Eclair (ACINQ - Scala)

Mappa di mainnet

Mappa di testnet