Offerta BOLT12

Un'offerta è una richiesta di pagamento che sopravvive al fatto di essere pagata, così un solo codice stampato serve ogni cliente. Le offerte non portano firma né checksum, e i loro campi occupano i tipi TLV da 2 a 22, deliberatamente abbastanza corti per la fotocamera di uno smartphone di fascia bassa. Se ricevi bitcoin, questa è la differenza tra un codice che stampi una volta e la fattura che ne deriva, che scade 7200 secondi dopo.

Come funziona

Un'offerta BOLT12 è un flusso di record tipo-lunghezza-valore scritti con il prefisso leggibile lno, un separatore 1 e poi caratteri in stile bech32 che trasportano quei record in ordine.

Alla fine non c'è alcun checksum di sei caratteri. La specifica lo elimina sostenendo che i codici QR hanno già i propri checksum e che un'offerta danneggiata produce una stringa non interpretabile anziché un pagamento perso. Le offerte lunghe possono essere spezzate con un segno più, seguito facoltativamente da spazi bianchi, così sopravvivono all'incollaggio in un campo di testo con un limite di caratteri, e chi legge deve rimuovere il segno più e gli spazi bianchi prima di decodificare. Chi scrive deve usare tutto minuscolo o tutto maiuscolo, e dovrebbe scegliere il maiuscolo per i codici QR.

I campi stessi sono numerati. offer_chains è 2, offer_metadata 4, offer_currency 6, offer_amount 8, offer_description 10, offer_features 12, offer_absolute_expiry 14, offer_paths 16, offer_issuer 18, offer_quantity_max 20 e offer_issuer_id 22. Chi scrive deve restare entro i tipi da 1 a 79, con un secondo intervallo da 1000000000 a 1999999999 riservato agli esperimenti. Nulla in quell'elenco è una firma, e la cosa è voluta: firmare allungherebbe la stringa senza alcun beneficio, perché ogni campo non di firma viene copiato nella richiesta che segue, quindi un'offerta manomessa semplicemente non produce alcuna fattura.

Pagare richiede poi altri due messaggi. Il tuo wallet invia un invoice_request, prefisso lnr, tramite un onion message, copiando ogni campo dell'offerta compresi quelli che non comprende e firmando il risultato con una firma BIP340 su una radice di Merkle. L'emittente risponde con una fattura firmata. La costruzione di Merkle abbina la foglia di ogni campo a una foglia nonce, ed è questo che consente a chi paga di rivelare in seguito un campo di una fattura contestata senza esporre i campi vicini, cosa che una firma BOLT11 sull'intera stringa non può fare.

Due di quei tre messaggi funzionano al contrario per i rimborsi e gli sportelli automatici. Un esercente pubblica un invoice_request che indica un importo che vuole inviare, tu rispondi con una fattura e l'esercente conferma invoice_node_id prima di pagare.

Perché questo conta quando compri bitcoin

Un'offerta cambia il modo in cui pubblichi un mezzo per farti pagare, e non cambia nulla di quanto ti costa essere pagato.

Prendi la recensione di Phoenix su questo sito. ACINQ pubblica una tabella delle commissioni invece di lasciarti scoprirle: inviare tramite Lightning costa 0,4% più 4 satoshi, ricevere è gratuito quando hai già liquidità in entrata, e ricevere quando il wallet deve andare on-chain per fare spazio costa 1% più le commissioni di mining, con un nuovo canale a 1.000 satoshi. Distribuire un'offerta invece di una fattura non tocca nessuno di quei numeri. Elimina il passaggio in cui coni un nuovo codice per ogni pagatore, non il passaggio in cui qualcuno paga per la liquidità.

Il guadagno in privacy è reale ma limitato. Un indirizzo Lightning instrada ogni richiesta di fattura attraverso un server web sul dominio di qualcun altro, e quell'operatore vede gli importi e i tempi. Un'offerta instrada la richiesta tramite Lightning come onion message, e offer_paths consente a un nodo i cui canali sono tutti privati di restare raggiungibile senza pubblicare alcun node id. Ciò che questo non ti dà è la privacy dal tuo fornitore: la nostra recensione di Phoenix cita le FAQ di ACINQ, che dicono a chiare lettere che conosce la destinazione finale e l'importo dei pagamenti.

L'avvertimento pratico riguarda l'incollaggio. Un campo di prelievo su un exchange chiede una fattura Lightning, e una stringa lno1 non lo è. Strike, uno dei 63 record di exchange presenti qui, è nativo di Lightning e non aggiunge commissioni proprie sui trasferimenti in più di 100 paesi, ed è esattamente il tipo di flusso in cui i due formati si confondono. Né le 41 recensioni di wallet né i 63 record di exchange su questo sito documentano attualmente il supporto alle offerte come funzionalità, quindi consideralo qualcosa da confermare nelle note di rilascio del tuo wallet anziché darlo per scontato.

L'offerta di un banco di cappelli e la fattura in cui si trasforma

Un banco che vende cappelli a 25 dollari scrive un'offerta con offer_currency impostato su USD e offer_amount impostato su 2500.

Questa è la regola della specifica per una valuta diversa da bitcoin: un codice ISO 4217 di tre lettere e un importo nell'unità della valuta adeguato all'esponente ISO 4217, che per i dollari significa centesimi. Impostare offer_amount rende obbligatorio offer_description, perché chi paga per qualcosa di specifico deve sapere di cosa si tratta. Se restano tre cappelli, offer_quantity_max è 3, e se il banco non ha un limite fisso è 0. Un valore di 1 è esplicitamente ammesso, per quanto sembri strano, così un sistema di magazzino non ha mai bisogno di un caso speciale per l'ultimo articolo. offer_issuer potrebbe recitare hats@example.com Hat Stall, dato che la specifica chiede prima un dominio e poi qualsiasi testo descrittivo dopo uno spazio.

Il tuo wallet legge questo, ti quota 25 dollari e invia un invoice_request con invreq_quantity pari a 2 per due cappelli, un invreq_payer_id e facoltativamente un invreq_payer_note. In risposta arriva una fattura con un payment hash, un timestamp di creazione, almeno un blinded path e una quotazione delle commissioni per percorso che copre commissione base, commissione proporzionale, delta CLTV e l'HTLC più piccolo e più grande che trasporterà. Due regole ti proteggono qui. Il tuo wallet deve rifiutare la fattura se un campo negli intervalli da 0 a 159 non corrisponde a quanto inviato, e deve avvisarti se l'importo in millisatoshi differisce in modo significativo dalla stima in dollari fornita dall'offerta. A meno che l'emittente imposti invoice_relative_expiry, la fattura deve essere rifiutata 7200 secondi dopo la sua creazione.

Offerta BOLT12 vs fattura BOLT11

Un'offerta BOLT12 è una richiesta di una richiesta di pagamento; una fattura BOLT11 è la richiesta di pagamento.

Il testo del BOLT12 si apre con otto critiche al suo predecessore, e quelle che avverte chi paga sono queste. Una fattura BOLT11 è firmata nel suo insieme, quindi dimostrare un campo significa rivelarli tutti. I suoi importi leggibili, secondo il giudizio della specifica, si sono rivelati problematici: il moltiplicatore p era spesso gestito male, e contare in pico-bitcoin è più difficile che in satoshi. Il suo payment_secret impediva il probing solo finché la fattura restava privata tra pagatore e beneficiario, cosa che una fattura pubblicata non è. E, nelle parole della specifica stessa, le fatture devono essere fornite per utente e sono attivamente pericolose se si fanno due tentativi di pagamento per lo stesso utente. Un'offerta risponde a tutte e quattro semplicemente non essendo una fattura.

Offerta BOLT12 vs indirizzo Lightning

Un'offerta BOLT12 è una stringa autonoma; un indirizzo Lightning è un nome che il server di qualcun altro risolve per te.

Entrambi sono riutilizzabili, ed è per questo che si confondono. L'indirizzo dipende da un dominio, un certificato e un operatore che mantiene attivo il servizio, e smette di funzionare il giorno in cui uno dei tre viene meno. L'offerta dipende dal fatto che entrambi i nodi parlino onion message e da nient'altro, il che è una superficie di guasto più piccola, anche se devi confermare che il tuo wallet la gestisca anziché darlo per scontato. L'indirizzo vince sul fatto di poter essere detto a voce. Una lunga stringa lno1 è un codice QR, non qualcosa che leggi in un microfono.