Payment secret

Il payment secret di Lightning funziona come una password per fattura che il pagatore rimanda indietro prima che il nodo ricevente accetti il denaro. Il BOLT 11 gli assegna la lettera di tag s, ne fissa la lunghezza a 52 caratteri bech32 e indica a chi legge di far fallire ogni fattura che arriva senza. Per te, è il motivo per cui un nodo di routing che ha visto il tuo payment hash non può sapere che il pagamento è terminato nel tuo wallet.

Come funziona

Un payment secret è creato dal wallet del destinatario, mai dal pagatore, e resta sigillato dentro l'onion fino a quando il pagamento raggiunge il suo ultimo hop.

Il BOLT 11 lo definisce come campo con tag di tipo 16, scritto con la lettera s e un data_length fisso di 52. Quei 52 caratteri bech32 portano 260 bit, un valore di 32 byte più padding, e chi scrive una fattura deve includerne esattamente uno. Chi legge deve far fallire il pagamento se un campo a lunghezza fissa ha la lunghezza sbagliata, e ancora se non è presente alcun campo s valido.

Il pagatore copia il valore nel payload onion per l'ultimo nodo, cioè il payload, che il BOLT 4 chiama record TLV di tipo 8, payment_data, contenente il segreto di 32 byte e una cifra total_msat. Solo la destinazione può rimuovere quello strato, quindi gli hop intermedi non lo vedono mai, a differenza del payment hash su cui tutti bloccano i propri HTLC.

Il controllo all'altro capo è volutamente poco informativo. Un segreto che non corrisponde a quello atteso per quel payment hash, o che è richiesto e assente, fa fallire l'HTLC con incorrect_or_unknown_payment_details, errore PERM|15, la stessa risposta che riceve un payment hash sconosciuto. Il BOLT 4 spiega l'unificazione: la vecchia coppia, PERM|16 incorrect_payment_amount e 17 final_expiry_too_soon, permetteva a un nodo che inoltra di rinviare pagamenti con lo stesso hash a valori molto più bassi e leggere la risposta per confermare di aver trovato la destinazione.

Il supporto non è più negoziato. Il BOLT 9 elenca i bit di funzionalità 14 e 15, payment_secret, come ASSUMED, e i bit 16 e 17, basic_mpp, dipendono da esso.

Dove lo vedi

Puoi individuare un payment secret in una moderna stringa lnbc come la sequenza che inizia con sp5 e prosegue per 52 caratteri bech32.

Nei vettori di test del BOLT 11 quella sequenza è zyg3 ripetuto dodici volte e poi zygs, che codifica un segreto i cui 32 byte sono tutti 0x11. Non digiti mai un payment secret: solo chi scrive la fattura e il wallet che paga ne gestiscono il valore.

Dove il campo dimostra la sua utilità è nei pagamenti multi-parte. Quando nessuna singola rotta ha liquidità sufficiente e la fattura offre basic_mpp, il BOLT 4 consente a un wallet di dividere l'importo tra più HTLC che condividono un payment hash, e ogni parte deve portare il segreto e dovrebbe concordare su total_msat. Il ricevente non regola nulla finché non arriva il totale, e dovrebbe attendere almeno 60 secondi dopo il primo HTLC prima di far fallire l'insieme con un mpp_timeout. Quindi un prelievo Lightning più grande da un'app incentrata su Lightning come Strike che resta in sospeso per un minuto e poi torna indietro può essere un insieme di HTLC incompleto che scade, e non denaro perso. Che sia il tuo wallet a comporre quelle parti, come fa Phoenix eseguendo un vero nodo Lightning sul telefono, o un custode a farlo su un server che non gestisci, il segreto le contrassegna come un unico pagamento.

Payment secret vs payment hash

Il payment hash e il payment secret sono entrambi campi da 256 bit in una stessa fattura BOLT 11, e la differenza sta in chi può vederli. Ogni hop conosce l'hash, perché ognuno blocca su di esso l'HTLC che inoltra, mentre nessuno tranne il nodo finale conosce il segreto, che viaggia nello strato più interno dell'onion. L'hash risponde se il pagamento è stato regolato, e la preimage che lo apre è la ricevuta. Il segreto risponde se il pagatore sta lavorando dalla fattura che hai scritto, cosa che un hash non può fare, essendo visibile a tutti sulla rotta. Nella codifica sembrano gemelli: tag p e tag s, entrambi da 52 caratteri, entrambi rifiutati a qualsiasi altra lunghezza.