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.