Payment hash

Ogni hop di una rotta Lightning vede lo stesso payment hash, ed è ciò che identifica il pagamento per ciascuno di essi. BOLT 11 ne richiede esattamente uno per fattura, scritto come 52 caratteri bech32 che portano 256 bit. Mostrare il segreto corrispondente è l'unico modo per reclamare il denaro, e conservare quel segreto in seguito è la tua ricevuta.

Come funziona

Un payment hash nasce come il suo opposto: il destinatario sceglie 32 byte casuali, detti preimmagine del pagamento, e pubblica solo il loro SHA-256.

Quel valore entra nella fattura sotto il tag p, che BOLT 11 fissa a un data_length di 52 e richiede esattamente una volta. Da lì viaggia lungo la rotta dentro update_add_htlc, messaggio di tipo 128, i cui campi sono l'id del canale, un contatore di 64 bit, l'importo in millisatoshi, il payment_hash stesso, una scadenza CLTV e un onion di 1366 byte. In quel messaggio svolge un doppio ruolo: viene anche passato alla costruzione dell'onion come dati associati, così gli HMAC a ogni hop si impegnano su di esso. Ripetere un vecchio pacchetto onion contro un payment hash diverso fallisce quindi al primo nodo che lo verifica.

Il regolamento percorre l'hash all'indietro. Il destinatario restituisce la preimmagine in update_fulfill_htlc, messaggio di tipo 130, come semplice valore di 32 byte, e ogni nodo a monte la ripassa indietro lungo gli stessi canali. Un nodo che riceve una preimmagine il cui SHA-256 non corrisponde all'hash che sta trattenendo non la ignora semplicemente: BOLT 2 dice che deve inviare un avviso e chiudere la connessione oppure inviare un errore e far fallire il canale, perché non esiste una spiegazione innocente.

On-chain l'hash viene ridotto. Lo script di output HTLC non contiene affatto il valore di 32 byte; esegue un confronto OP_HASH160 contro RIPEMD160(payment_hash), un impegno di 20 byte, e chi spende fornisce la preimmagine nel witness. Due HTLC offerti con lo stesso importo arrotondato e lo stesso payment hash producono output identici byte per byte anche quando le loro scadenze differiscono, ed è per questo che BOLT 3 deve specificare una regola di ordinamento per essi.

Un requisito sembra strano finché non si vede l'attacco che sta dietro. Un nodo deve accettare più HTLC che portano lo stesso payment hash, e BOLT 2 ne dà il motivo: se i duplicati fossero rifiutati, un attaccante potrebbe sondare con un hash noto e scoprire se quel nodo stava già trattenendo quel pagamento. L'id separato di 64 bit esiste per distinguere i duplicati.

Perché questo conta quando compri bitcoin

Due dei 63 exchange recensiti qui documentano un pagamento Lightning nelle loro note sulle commissioni: Strike, la cui nota sui prelievi dice che i prelievi verso wallet sono disponibili tramite Lightning e on-chain, e Coinbase, la cui tabella delle commissioni fissa un invio Lightning allo 0,2% dell'importo inviato.

Quando uno di questi pagamenti si blocca, non c'è nessun ID di transazione da cercare, perché nulla è arrivato alla blockchain. Il payment hash è l'unica stringa che sia il registro del tuo wallet sia il back office dell'exchange possiedono, quindi copiala dalla schermata di dettaglio del pagamento prima di chiuderla. Un servizio di assistenza che chiede "l'ID di transazione" di un prelievo Lightning sta chiedendo questo valore.

L'errore che ricevi non ti dirà molto, ed è voluto. BOLT 4 accorpa cinque problemi distinti in un unico codice di errore, incorrect_or_unknown_payment_details, numerato PERM|15: il nodo finale non conosce l'hash, il payment secret non vi corrisponde, l'importo per quell'hash è troppo basso, la scadenza è troppo vicina all'altezza di blocco attuale, oppure mancano metadati di pagamento obbligatori. La specifica spiega l'accorpamento. I vecchi codici separati permettevano a un nodo che inoltra di indovinare dove fosse diretto un pagamento inviando lo stesso hash più avanti a un valore molto più basso e leggendo la risposta. Il tuo wallet non ti sta nascondendo il motivo: non gli è mai stato comunicato, quindi rigenerare la fattura e pagare di nuovo è la risposta pratica.

Lo stesso valore resta identico dal tuo nodo a quello del destinatario, anche attraverso ogni parte di un pagamento in più parti, che secondo BOLT 4 deve condividere un unico payment hash. Chi lo vede due volte sa di trovarsi davanti a un solo pagamento. La nostra recensione di Phoenix cita le FAQ di ACINQ stesse, che ammettono di conoscere la destinazione finale e l'importo dei pagamenti effettuati tramite il wallet: è la versione senza giri di parole della stessa esposizione, dichiarata dal fornitore e non dedotta da questo sito.

Riutilizzare una fattura è peggio che inutile per un motivo correlato. BOLT 4 lascia un nodo finale a cui viene consegnato un hash già pagato libero di trattarlo come sconosciuto oppure di accettare il denaro, quindi l'esito di un codice QR pubblicato di nuovo dipende dall'implementazione che il destinatario si trova a usare.

Decodificare il payment hash nel vettore di test per le donazioni di BOLT 11

La specifica BOLT 11 include una fattura di donazione di esempio, e il payment hash al suo interno è un valore di test fisso che nessun wallet dovrebbe mai produrre.

L'esempio è intitolato "Please make a donation of any amount using payment_hash 0001020304050607080900010203040506070809000102030405060708090102" e la stringa inizia con lnbc1pvjluez. Dopo il prefisso lnbc e il separatore bech32, pvjluez è il timestamp, 1496314658 secondi dall'inizio del 1970. Segue il campo payment secret, e dopo di esso il tag p, poi p5, che è la lunghezza: in bech32 p vale 1 e 5 vale 20, quindi il campo occupa 1 * 32 + 20 = 52 caratteri. Quei caratteri, qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypq, si decodificano nell'hash citato in quel titolo.

Nulla di tutto questo è privato. La specifica pubblica la chiave privata con cui sono firmati i suoi esempi, e126f68f7eafcc8b74f54d269fe206be715000f94dac067d1c04a8ca3b2db734, e dice che ogni fattura di quella sezione porta il payment secret 1111111111111111111111111111111111111111111111111111111111111111 salvo diversa indicazione, quindi queste stringhe sono dati di prova per i parser e non richieste di pagamento. Se un wallet o uno strumento di diagnostica dovesse mai mostrarti quell'hash fuori da una suite di test, qualcosa sta ripetendo la specifica invece di riportare il tuo pagamento.

Payment hash vs ID di transazione

Un payment hash identifica un pagamento Lightning; un ID di transazione identifica una transazione che esiste sulla blockchain di bitcoin. Entrambi sono 32 byte ed entrambi si stampano come 64 caratteri esadecimali, ed è così che finiscono nei moduli di assistenza l'uno dell'altro. Un ID di transazione viene calcolato a posteriori dai byte della transazione stessa e può essere incollato in qualsiasi block explorer. Un payment hash è scelto dal destinatario prima che il pagamento esista, non compare mai in un blocco quando il pagamento si conclude normalmente e non restituisce nulla in un explorer. Un risultato di ricerca vuoto di solito significa che hai il valore giusto e lo strumento sbagliato.

Payment hash vs payment secret

Un payment hash e un payment secret sono due valori diversi di 256 bit nella stessa fattura, trasportati nei tag p e s e ciascuno codificato come 52 caratteri bech32. L'hash è necessariamente pubblico: ogni hop deve vederlo per costruire il proprio HTLC. Il segreto viene consegnato solo all'ultimo nodo, dentro l'onion, e BOLT 11 ne riassume la funzione in una riga: "prevents forwarding nodes from probing the payment recipient" (impedisce ai nodi che inoltrano di sondare il destinatario del pagamento). Un lettore che non trova alcun campo s deve far fallire il pagamento senz'altro. L'hash è la serratura; il segreto è la prova che chi sta pagando ha ricevuto la fattura da chi l'ha emessa.