Apro questo post per fare chiarezza sull'argomento covenant e canali multipli Lightning Network.
Non sarò io a fare chiarezza
Ho una conoscenza molto superficiale di queste cose che bollono in pentola, non ho fatto nessun approfondimento tecnico personale. Ho solamente letto e ascoltato qualche articolo/podcast generalisti (molti dei quali con la voce di Zucco) che citavano l'argomento. Faccio un breve sunto di quel poco che ho intercettato ad un livello molto superficiale, invoco quindi ogni esperto del forum per portare approfondimenti di qualsiasi livello, anche molto tecnici mi farebbero piacere.
Ci troviamo di fonte ad un problema nel Lightning Network, al momento i canali che si aprono sono solo tra due parti, quindi il routing tra canali avviene al momento tra chi ha un canale in comune con qualcuno con cui ha un canale in comune con qualcuno che ha un canale in comune con colui con cui devi transare. La ricerca di un percorso di routing avviene tra canali che coinvolgono ognuno due persone.
(Fin qui è corretto? Ho capito male?)
Si vorrebbe creare canali tra più di due parti. Per farlo ci sarebbero due modalità:
1)una "brutta" e non elegante da sviluppare in cui bitcoin resta così com'è
2)una "bella" in cui si modifica bitcoin introducendo i covenant per predisporre un approccio elegante a questi canali multipli nel Lightning Network
I problemi dei covenant sono i seguenti:
1) intanto servirebbe un softfork con gran parte della community da mettere d'accordo e vista la crescente decentralizzazione di bitcoin, non sembra una cosa così scontata da poter realizzare (bitcoin è gia ossificato?)
2) dato che i covenant potrebbero portare comportamenti collaterali imprevisti (per esempio sembra che diminuirebbero la privacy dei singoli coin, si potrebbero marchiare certi coin per sempre rendendoli meno fungibili) non è ancora chiaro se potrebbe valerne la pena tra pro e contro
3) ci sono vari covenant proposti e non è chiaro quale sia il migliore, per lo meno non a me
Qualcuno sa dipanare i miei dubbi e eventualmente correggere cavolate che ho scritto?
Tra i vari covenant ci sono CTV, CheckTXHASH, altri? In cosa differiscono? Negli anni passati avevo sentito parlare di anyprevout (APO) è pure lui un covenant o è un'altro argomento?
La versione "brutta" per fare canali multipli come si svilupperebbe dal punto di vista informatico?
Sempre se ho capito bene, con i covenant si potrebbe ricevere transazioni sul ligthnning network anche se il tuo nodo è offline?
Per quello che ne so io hai scritto tutte cose corrette.
I covenants sono regole che vincolano, nello scriptPubKey della transazione iniziale, le modalità di spesa successiva degli UTXO coinvolti.
Ad esempio potrei inviare dei btc ad un indirizzo X specificando che quei btc (o parti di essi) possano poi essere spesi solo a favore dell'indirizzo Y.
Nell'ambito di LN i covenants sono una soluzione per creare canali multi-party nativi, come scrivi.
I canali multi party sono una forma di scaling molto potente perchè sarebbero necessarie meno transazioni per aprire, chiudere e rifinanziare i canali.
Inoltre risolverebbero un limite : attualmente LN funziona con il
revocable sequence maturity contract (RSMC) ossia le parti di un canale devono mantenere l'intera cronologia delle transazioni, con il rischio che una delle parti tenti di spendere un vecchio stato (barando)
Con i covenants la storia delle transazioni verrebbe sempre sovrascritta all'ultimo stato valido, bypassando il problema (un altro modo per raggiungere questo scopo è l'upgrade Eltoo tramite una nuova opzione di firma chiamata SIGHASH_ANYPREVOUT)
I covenant renderebbero anche più semplici e decentralizzati i bridge verso i L2 (rollup), che attualmente avvengono con tecniche onerose e complesse come BitVM2
Inoltre sarebbero possibili i vault, cioè forme più sicure di cold wallet (potrei stabilire che i btc che mando ad un indirizzo siano spendibili solo a favore di un altro indirizzo sempre sotto il mio controllo).
Come sempre c'è il rovescio della medaglia: come dici la perdita di fungibilità sarebbe il più rischioso. I
reverse covenants fisserebbero delle regole retroattive su chi quando e come può spendere i btc coinvolti in una transazione. Un entità governativa potrebbe creare delle blacklist o whitelist imponendo la successiva spesa solo a favore di certi soggetti (es solo chi è conforme al KYC/AML): la conseguenza potrebbe essere che il mercato si rifiuta di accettare pagamenti che contengono questi vincoli e, di riflesso, la creazione di btc di serie a e serie b.
