Vai al contenuto
buybitcoinsmart

Glossario / Lightning e layer 2

Keysend

Che cos'è un keysend?
Keysend invia un pagamento Lightning senza fattura: chi paga genera la preimmagine di 32 byte, ne calcola l'hash per ottenere il payment hash e trasporta il segreto dentro la onion.

Keysend inverte il flusso normale di Lightning, in cui il destinatario sceglie un segreto e ne pubblica l'hash in una fattura. Il segreto del mittente viaggia nel record TLV personalizzato 5482373484, un numero pari, che BOLT 1 impone a un nodo che non conosce keysend di rifiutare invece di ignorare. Puoi pagare una chiave pubblica di nodo nuda senza alcun scambio preliminare, e rinunci alla ricevuta crittografica che una fattura avrebbe lasciato.

Come funziona

Keysend si basa sulla metà più severa di una regola di BOLT 1: un lettore scarta un record TLV sconosciuto di tipo dispari e prosegue, ma su uno sconosciuto di tipo pari deve far fallire l'intero flusso.

Gli identificatori di tipo sotto 2^16 sono riservati ai BOLT e tutto da 2^16 in su è libero per i record personalizzati, e BOLT 1 indica di scegliere un numero dispari quando i nodi ordinari dovrebbero ignorare i dati, uno pari quando dovrebbero rifiutarli. bLIP-3 documenta che 5482373484 fu scelto a caso dall'implementazione originale di lnd, e termina con un quattro, quindi keysend è finito dalla parte che rifiuta. Ecco perché serve un feature bit: i nodi disposti annunciano il feature bit 54/55, chiamato keysend, che dipende da var_onion_optin, e bLIP-3 dice che i mittenti dovrebbero cercarlo invece di inviare alla cieca e vedere il pagamento fallire.

Il compito del mittente, descritto in bLIP-3, è breve. Generare un valore casuale crittograficamente sicuro di 32 byte, inserirlo in quel record e impostare il campo payment_hash in update_add_htlc con il suo SHA-256. Non riutilizzare mai una preimmagine, e mai riutilizzarne una di una fattura già pagata. Il pacchetto è offuscato a ogni salto, così un salto recupera solo l'indirizzo del successivo e nessuno nel mezzo vede il record. Il nodo finale calcola l'hash del valore che trova, lo verifica rispetto all'hash che gli è stato chiesto di accettare e regola.

Il rifiuto è volutamente silenzioso. BOLT 4 ha una risposta letterale per un payload che un nodo non ha compreso, PERM|22 invalid_onion_payload, che può persino indicare il tipo TLV che l'ha causato. bLIP-3 chiede ai destinatari di restituire invece PERM|15 incorrect_or_unknown_payment_details, così un keysend rifiutato è indistinguibile da un payment hash che il nodo non ha mai emesso.

Dove lo vedi

Keysend è l'infrastruttura sotto i boost dei podcast.

bLIP-10 definisce un secondo record, di tipo 7629169, scelto in origine da Breez, che porta un oggetto JSON semplice allegato al pagamento keysend: il titolo del podcast, l'episodio, ts per la posizione di riproduzione in secondi, action impostato su boost o stream, e un message facoltativo, che è ciò che rende un boostagram. Lo streaming al minuto imposta seconds_back su 60. Quel record è dispari, ed è per questo che bLIP-10 non si preoccupa della compatibilità con le versioni precedenti: un host che ignora i metadati conserva comunque i sats. Esiste perché un keysend da solo non dice nulla al destinatario, quindi un'app deve indicare da sé il programma.

La stessa lacuna tiene keysend fuori dal percorso di acquisto. Un prelievo da un exchange o ti consegna una fattura o te ne chiede una, perché la piattaforma deve collegare il pagamento al tuo conto, e la parola non compare in nessuno dei 63 record di exchange né nelle 41 recensioni di wallet di questo sito. bLIP-3 espone il compromesso con onestà: si aspetta che keysend ceda il passo a un pagamento spontaneo progettato meglio, cita le offerte e AMP, ed elenca ciò a cui rinunci nel frattempo, la prova del pagamento e ogni voce in capitolo del beneficiario sulla scadenza CLTV finale.

Keysend vs indirizzo Lightning

Keysend e un indirizzo Lightning ti permettono entrambi di pagare qualcuno che non ti ha mai consegnato una fattura, e solo uno dei due salta davvero la fattura. Digitare user@example.com manda il tuo wallet a fare una richiesta HTTPS che restituisce una fattura BOLT11 nuova, quindi il destinatario ha comunque scelto la preimmagine e tu finisci per avere una ricevuta sostenuta dalla sua firma. Keysend non richiede alcuna richiesta web né alcun server, solo la chiave pubblica del nodo di 33 byte e una rotta verso di essa, e non ti lascia nulla per dimostrare in seguito il pagamento, perché il segreto è stato tuo fin dall'inizio. Se mai dovessi aver bisogno di dimostrare di aver pagato, scegli la fattura.

Da non confondere con

Domande frequenti

Keysend fa parte della specifica Lightning?

No, keysend è definito nel bLIP-3, una proposta di miglioramento di Lightning creata l'8 dicembre 2021 per documentare ciò che le implementazioni avevano già rilasciato. Non è servita alcuna modifica ai BOLT perché gli identificatori di tipo TLV da 2^16 in su sono liberi per i record personalizzati, ma il tipo 5482373484 di keysend è pari, quindi BOLT 1 impone a un nodo che non lo supporta di rifiutare il payload invece di ignorarlo.

Un pagamento keysend dimostra che ho pagato?

No, perché la preimmagine l'hai generata tu e non il destinatario, e non c'è alcuna firma di fattura che colleghi il pagamento a lui. bLIP-3 elenca la perdita della prova del pagamento tra i principali svantaggi di keysend, quindi usa una fattura ogni volta che la ricevuta conta.

Perché il mio pagamento keysend è fallito?

Il più delle volte perché la destinazione non accetta keysend, e questo non si può capire dall'errore. Un nodo che rifiuta i pagamenti spontanei restituisce PERM|15 incorrect_or_unknown_payment_details, lo stesso fallimento di una preimmagine errata o di un payment hash che il nodo non ha mai emesso, ed è per questo che bLIP-3 indica di inviare solo a nodi che annunciano il feature bit keysend, registrato come 54/55 in bLIP-2.

Leggi anche

Termini correlati

Altro in Lightning e layer 2

Leggi questa pagina in inglese