Percorso cieco

Il destinatario costruisce il percorso e lo fornisce, così il pagatore instrada solo fino a un punto di introduzione pubblico e non oltre. Una fattura BOLT 12 viene rifiutata se non porta alcun percorso cieco, e i salti accecati condividono con il resto del percorso il payload fisso di 1300 byte del pacchetto onion. Se pubblichi una destinazione Lightning, l'accecamento tiene l'id del tuo nodo fuori da essa.

Come funziona

Un percorso cieco si costruisce all'indietro, dal nodo che vuole essere raggiunto e non dal nodo che paga.

Il destinatario parte da un percorso reale verso se stesso e da una chiave effimera casuale, da cui deriva una catena di chiavi di percorso disposte in modo che ogni salto possa calcolare la successiva senza che gli venga detto. Ogni salto finisce per condividere un segreto ECDH con il destinatario, e da quel segreto derivano due cose. La prima è un fattore di accecamento, l'HMAC della stringa blinded_node_id calcolato con il segreto condiviso, che il destinatario moltiplica per la chiave pubblica di quel salto. Il salto può comunque firmare il risultato, perché deriva lo stesso fattore e lo applica alla propria chiave privata, ma nessun altro può far corrispondere quella chiave al grafo pubblicato. La seconda è una chiave di cifratura, usata per sigillare un piccolo blocco di istruzioni per quel salto con ChaCha20-Poly1305 e un nonce composto da soli zeri.

Ciò che viene pubblicato è breve: il punto di introduzione in chiaro, una chiave di percorso iniziale, poi un elenco di chiavi modificate, ciascuna abbinata al proprio blocco sigillato. Dentro un blocco ci sono i campi che quel salto legge: short_channel_id o next_node_id per dove prosegue il pagamento, payment_relay per la commissione e il delta CLTV che deve applicare, payment_constraints per una scadenza massima e una dimensione minima dell'HTLC, il padding e, sull'ultimo salto, un path_id.

Tre di queste scelte sono difensive più che funzionali. Il destinatario, non il pagatore, fissa la commissione e il timelock per ogni salto accecato, così un nodo intermedio non può alzare il prezzo a metà percorso e osservare quali pagamenti falliscono. Riempie ogni blocco a una sola lunghezza e può aggiungere salti fittizi che poi scarta, così la lunghezza reale non è leggibile dalla forma. E il path_id contiene dati privati, per esempio il preimage, così il destinatario può confermare un percorso che ha costruito invece di accettarne uno che un attaccante ha lanciato contro ogni nodo di cui sospetta.

BOLT 12 aggiunge un ultimo elemento di mimetizzazione. Invece di una commissione per ogni salto accecato, una fattura porta esattamente un blinded_payinfo per percorso: una commissione base in millisatoshi, un tasso proporzionale in milionesimi, un unico delta CLTV aggregato, una dimensione minima e massima dell'HTLC e un vettore di funzionalità. La ragione dichiarata è che il dettaglio per salto rivelerebbe banalmente una non uniformità che distinguerebbe il percorso.

Perché questo conta quando compri bitcoin

I percorsi ciechi cambiano ciò che la parte centrale della rete Lightning sa di te, e non cambiano nulla di ciò che sa il tuo primo salto.

L'accecamento dei percorsi nasconde i salti successivi al punto di introduzione e non dice nulla sul nodo attraverso cui si connette il tuo wallet, che è quello che vede i tuoi importi e le tue destinazioni. Phoenix, che questo sito valuta 4,0 tra le sue 41 recensioni di wallet, è insolitamente onesto al riguardo: le FAQ di ACINQ stesse dicono che il wallet non offre alcun vantaggio di privacy rispetto a un wallet custodiale ospitato, e che ACINQ conosce la destinazione finale e l'importo dei pagamenti. Un percorso cieco in un'offerta che paghi non tocca questo punto.

La custodia elimina del tutto la questione. Wallet of Satoshi, che questo sito valuta 2,7 e segnala con un avviso, detiene le chiavi nella sua modalità custodiale, quindi entrambe le estremità di un pagamento sono registrazioni sue; ha smesso di servire i clienti degli Stati Uniti il 23 novembre 2023 e da allora ha eliminato il servizio custodiale in tutta l'Unione europea. Nulla di tuo viene accecato quando il pagamento non lascia mai i libri contabili del fornitore.

Dove l'accecamento ti darebbe qualcosa è nel prelievo stesso. Strike, la piattaforma incentrata su Lightning con la valutazione più alta di questo sito, 4,6, non aggiunge commissioni proprie sui trasferimenti e paga a una destinazione Lightning che indichi tu. Se le consegni una fattura BOLT 11, consegni il tuo nodo: la firma porta un id di recupero, quindi la chiave del beneficiario può essere recuperata da essa. Un'offerta mette lì invece un punto di introduzione, ovunque il pagatore ne gestisca una.

Il costo è diagnostico. I salti dentro un percorso cieco restituiscono errori senza dati di attribuzione, e al punto di introduzione viene indicato di aggiungere un ritardo casuale prima di inoltrare un errore, così il probing non può misurare quanto è lontano il destinatario. Un prelievo che fallisce verso una destinazione accecata quindi non ti dice quasi nulla, perciò provalo da un wallet che gestisci tu prima di dare la colpa alla piattaforma.

Dave consegna ad Alice un percorso attraverso Bob e Carol

La specifica Lightning sviluppa l'idea del percorso cieco con quattro nomi, cosa più rapida da seguire dell'algebra.

Dave vuole essere pagato senza che Alice sappia che è lui. Sceglie un percorso verso se stesso attraverso due nodi pubblici, prima Bob poi Carol, e costruisce la catena di chiavi di percorso in modo che tutti e tre derivino la propria. Poi sigilla tre blocchi: uno che dice a Bob di inoltrare a Carol, uno che dice a Carol di inoltrare a lui, e uno per se stesso con metadati e il path_id. Infine deriva i fattori che trasformano Bob in Bob primo, Carol in Carol primo e Dave in Dave primo.

Alice riceve tre righe: il primo nodo è Bob, ecco la prima chiave di percorso, ed ecco la sequenza Bob primo, Carol primo, Dave primo con un blocco sigillato accanto a ciascuno. Raggiunge Bob attraverso il normale grafo pubblico, ed è deliberato: la specifica raccomanda un tratto non accecato fino al punto di introduzione, perché non richiede il supporto dei nodi intermedi e restituisce errori che si possono leggere. Bob apre il proprio blocco di istruzioni, apprende solo che il successivo è Carol e inoltra la chiave di percorso derivata insieme al pacchetto onion. Carol usa quella chiave due volte, una per modificare il pacchetto onion, che Alice ha cifrato per Carol primo e non per Carol, e una per aprire il proprio blocco di istruzioni. Dave lo riceve per ultimo e controlla il path_id prima di accettare.

Conta cosa finisce per sapere ciascuno. Alice conosce Bob. Bob sa di essere un punto di introduzione e che il successivo è Carol. Carol sa che un pagamento accecato è passato da lei e non può dire se il destinatario sia Dave o un altro nodo di inoltro. Dave sa tutto, perché è l'unico che l'ha costruito.

Percorso cieco vs route hint

Un percorso cieco e un route hint rispondono alla stessa domanda, come raggiungere un nodo che il grafo pubblico non vede, e rivelano quantità opposte nel farlo.

Un route hint è il campo r di una fattura BOLT 11 ed è testo in chiaro. Ogni voce porta una chiave pubblica di 264 bit, uno short channel id di 64 bit, una commissione base, un tasso proporzionale e un delta CLTV, tutto in chiaro, così chiunque abbia la fattura sa da quale nodo ben connesso dipendi. Un percorso cieco nomina il punto di introduzione e poi diventa opaco: ogni salto successivo è una chiave modificata che non corrisponde a nulla nel grafo, e le commissioni arrivano aggregate invece che dettagliate. I percorsi ciechi assumono anche un compito che i route hint non hanno mai avuto, sostituendo i campi payment_secret e payment_metadata di una fattura BOLT 11.

Percorso cieco vs onion routing

L'onion routing nasconde il pagatore ai salti; un percorso cieco nasconde il beneficiario al pagatore.

Nel semplice onion routing il mittente sceglie ogni salto dal grafo pubblico e avvolge uno strato di cifratura per salto, così nessun nodo che inoltra apprende chi paga né in quale punto del percorso si trova. Il mittente conosce comunque l'intero percorso, incluso l'id reale del nodo di destinazione, il che va bene per pagare un negozio ed è inutile per pubblicare una destinazione riutilizzabile. L'accecamento dei percorsi fornisce la metà mancante senza sostituire nulla: un pagamento attraverso un percorso cieco è comunque un pacchetto onion, e l'accecamento è una modifica di chiave sovrapposta. Sono abbastanza separabili perché un destinatario che non voglia la privacy possa costruire un percorso di un solo salto che contenga solo se stesso e rivelare comunque l'id del proprio nodo.