Fermata #104 - BTCPrague: il futuro di Lightning e degli hardware wallet

Nell’intervento ho citato quattro aggiornamenti di cui sono entusiasta. Uno di questi è già stato integrato nel Lightning Network e si chiama Route Blinding. Attualmente, quando inviamo a qualcuno un'invoice Lightning, il codice QR, per farci pagare, il destinatario di quell’invoice sa a chi sta mandando il pagamento. L'invoice dice al pagante quale nodo siamo. Fornisce l'ID del nodo e magari la controparte può ricollegarlo alle nostre informazioni pubbliche come, per esempio, il nostro account Twitter. Con il Route Blinding se riceverete un pagamento su Lightning, sarete in grado di nascondere chi è il destinatario finale di quel pagamento. In questo modo non dovrete più dire a nessuno, quando riceverete un pagamento, qual è l’ID del vostro nodo. Sarà possibile ricevere pagamenti senza svelare la propria identità a chi sta pagando. E’ un grande miglioramento in termini di privacy. E’ fantastico.

Sì. Uno dei problemi dell'attuale modo di effettuare i pagamenti è che tante persone usano terze parti. Negli Stati Uniti si usa molto Cash App. Ogni volta che si invia un’invoice a qualcuno tramite Cash App, l’azienda sa chi si sta pagando. Non so se lo faccia, ma Cash App ha la possibilità di prendere queste informazioni e conservarle o inviarle a Chainalysis. Improvvisamente le terze parti hanno tutte le informazioni su chi ha pagato chi, quanto e per cosa. La funzione di Route Blinding sarà inclusa in BOLT-123.

Al momento, se si ottiene un codice QR Lightning, è possibile pagarlo una sola volta. Ma mettiamo caso che vendiate oggetti artigianali e vogliate avere un codice QR per ogni singolo articolo: con le offerte BOLT-12 potete farlo. Potete stampare un'offerta (un codice QR) e tutti possono scansionarla, ricevendo ognuno un'invoice indipendente da pagare. Si tratta quindi di un modo interessante per creare invoice riutilizzabili. Ogni volta che si effettua un pagamento, si tiene traccia di chi ha pagato cosa.

LNURL fa una cosa molto simile. La differenza più grande è ciò che serve per eseguire LNURL rispetto alle offerte BOLT-12. Entrambi richiedono la scansione di un codice QR, ma poi il software deve andare a cercare la persona che ha creato il codice attraverso la rete. Il modo in cui LNURL fa questo è nel nome: URL. L'URL è una tecnologia web, la stessa che usiamo per navigare nei siti web. Utilizza l'infrastruttura web esistente per aiutarvi a trovare a chi chiedere l'invoice. Il problema è che per poterlo fare è necessario che sia in funzione un server web. Quindi bisogna avere accesso a un server web oltre che a un nodo Lightning. BOLT-12 dice: "Ok, stai già gestendo un nodo Lightning se ricevi pagamenti. Se facessimo in modo che non si debbano avere altri requisiti, come gestire un server web? Se usassimo il nodo Lightning esistente che sa come instradare i pagamenti o i messaggi?” Il pagamento è solo una forma di messaggio tra nodi. Il vostro nodo userà la rete Lightning per andare a parlare con il nodo che ha ricevuto l'offerta. Si potrà avere un codice QR statico per pagamenti Lightning senza dover gestire un web server.

Taproot è stato un grande aggiornamento avvenuto nel 2021. Ha cambiato il tipo di indirizzi che è possibile avere on-chain e ha introdotto nuove firme (firme di Schnorr, nda). Lightning è stato creato prima di Taproot. Quindi ogni volta che si creano canali, che sono transazioni multi-sig 2di2, si utilizzano le vecchie firme. Vogliamo aggiornare Lightning in modo che utilizzi tutte le nuove firme che sono state introdotte con Taproot. Uno dei motivi è che migliora la privacy on-chain. Al momento, quando un canale Lightning si chiude, è molto probabile che si possa intuire che si tratta effettivamente di un canale Lightning. Quando il canale viene chiuso lascia una sorta di traccia on-chain e noi vogliamo rimuoverla perché, come abbiamo detto prima, Chainalysis cerca di ottenere quante più informazioni possibili sulla rete. Se riusciamo a fare in modo che aperture e chiusure di canali Lightning appaiano come qualsiasi altro pagamento che avviene on-chain, eliminiamo la possibilità di guardare alla blockchain e di capire davvero chi sta spostando denaro e perché. Si tratta di una cosa davvero entusiasmante. So che ci sono due implementazioni che ci stanno lavorando.

Il quarto progetto di cui ho parlato è anch'esso legato al rapporto tra on-chain e Lightning. Si chiama Splicing. Se avete un canale Lightning che contiene, per esempio, 1 bitcoin e se avete inviato tutto il vostro saldo alla controparte, potreste voler mettere un altro bitcoin nel canale per essere in grado di continuare a pagare la controparte. Ma magari, allo stesso tempo, quella vuole prendere quel bitcoin e spostarlo in un altro canale. Quindi accade che entrambi volete ricaricare il canale di pagamento. In questo momento, l'unico modo per mettere più bitcoin nei canali esistenti è chiudere il canale e riaprirne uno nuovo: questo richiede due transazioni on-chain, per cui bisogna pagare le dovute commissioni. Se poi volete ottimizzare il routing, spostando liquidità da un canale meno utilizzato a uno più utilizzato, oggi serve fare altre due transazioni. Lo Splicing è davvero ottimo perché riduce i costi di spostamento del capitale su Lightning. Invece di dover effettuare quattro transazioni, due chiusure di canale e due riaperture per spostare i fondi, si può fare tutto in una sola transazione. Inoltre oggi, quando si chiude e si apre un canale, non è possibile inviare pagamenti durante il periodo in cui la transazione è in attesa di conferma on-chain. Lo Splicing permette invece di inviare pagamenti attraverso il canale anche mentre viene ridimensionato. 

A quanto mi risulta ACINQ avrà una prima versione di Splicing nella sua prossima release (della sua implementazione Eclair, nda). Quindi è già in arrivo. Per quanto riguarda Core Lightning stiamo rivedendo la nostra implementazione. Lo avremo anche noi nella nostra prossima release, che sarà in agosto.

Sì, lo vedo. Fedimint credo che ci abbia mostrato come si può fare, perché ha speso molto tempo ed energie per costruire i suoi gateway Lightning. Fedimint è un po’ una banca comunitaria. Quando sei in una federazione Fedimint, hai la tua shitcoin per quella banca comunitaria. È una shitcoin emessa solo per quella federazione. Finirò nei guai per averla chiamata così (ride).

Ma se vuoi prenderla e scambiarla? Puoi tenere un saldo in questa moneta comunitaria e non puoi pagare nessuno al di fuori della tua comunità. Come si fa a renderla utile a una rete più ampia? L'idea che hanno avuto è: se avessimo questi operatori Lightning che per una tariffa, un po' come un cambiavalute, prendessero la vostra moneta comunitaria e pagassero? L’operatore paga l’invoice in bitcoin sul Lightning Network per conto tuo e poi tu gli dai l’equivalente in moneta comunitaria.

Sono stati tra i primi a costruire questi gateway Lightning che fungono da interfaccia per l'invio di denaro a qualcun altro tramite Lightning, anche se il saldo nominale è diverso da quello della rete.

Il termine Secure Element è utilizzato per indicare chip specifici, componenti elettronici, circuiti integrati, che sono progettati per essere sicuri. Il loro ruolo principale è quindi quello di memorizzare i dati in modo sicuro. Alcuni dati, come le chiavi crittografiche, sono generati e memorizzati all'interno del chip. Quindi, se si dispone di una chiave privata e di una pubblica, si chiede a questo dispositivo di generare una coppia di chiavi, di memorizzare la chiave privata e di fornire la chiave pubblica all'esterno. L'idea è che la chiave privata rimanga sempre memorizzata in modo sicuro all'interno del dispositivo. Non deve esserci modo di tirarla fuori.

L’industria dei chip è molto, molto complessa e la loro progettazione richiede tanti investimenti e competenze specialistiche. Non è così semplice come un software, che si può scrivere e usare. Si tratta di un hardware fisso e l'economia della progettazione dei chip impone di essere in grado di produrlo su scala. E’ normale che tutta l'industria della progettazione di chip li produca in modo closed-source. Lo fa per proteggere il proprio know-how. Satoshi Labs fa prodotti basati su software open-source. Quindi capisce davvero i vantaggi della trasparenza. Il nostro compito in Tropic Square è quello di rendere il chip verificabile e trasparente. Parzialmente open-source, forse non completamente. La cosa importante è che vogliamo fornire una soluzione che consenta di ottenere una maggiore fiducia nel modo in cui i dati vengono elaborati.

Sì, può farlo. Ma nell’industria dei chip closed-source oggi bisogna fidarsi del fornitore e se c’è un problema nel prodotto non ce ne si accorge. La realtà è che ci sono persone là fuori che possono prendere il dispositivo, trovare le vulnerabilità e violarlo comunque.

Proprio perché closed-source, le persone che possono esaminare il progetto sono poche. I produttori di chip sono grandi aziende, ma non è detto che molte persone vedano il progetto, perché la sicurezza tramite la segretezza, la protezione del know-how, viene applicata non solo all'esterno delle loro aziende, ma anche all'interno. Quindi, alla fine, questi chip vengono visti solo da un piccolo gruppo di addetti ai lavori che si occupano della progettazione vera e propria. La verificabilità e la trasparenza consentono invece di raggiungere un pubblico più ampio.

Per tornare alla tua domanda: sì, può introdurre nuovi vettori di attacco, ma rende i progettisti consapevoli di quei vettori di attacco che già esistevano ma non erano considerati dal pubblico. Noi vogliamo aprire una parte del Secure Element. Apriamo la parte in cui vengono elaborati i dati degli utenti. Mostriamo come crittografiamo i dati, dove sono memorizzati, ma non possiamo dare i dettagli sulle modalità della memorizzazione stessa. I dati sono criptati e la crittografia è robusta. Si tratta di informazioni che costituiscono qualcosa in più della semplice scatola nera.

Sì, lo speriamo. È sicuramente il nostro obiettivo. Finora abbiamo ottenuto il nostro primo prototipo e le cose sembrano andare molto bene. Attualmente le proprietà di sicurezza degli acceleratori crittografici sono in fase di valutazione e non vediamo l'ora di ottenere i risultati. Vorremmo avere un secondo prototipo l'anno prossimo ed essere pronti per la produzione di massa nel 2025.