PP merchant data

Associare un pagamento a un ordine è il problema poco appariscente che ogni pagina di pagamento deve risolvere, e bitcoin lo rende più difficile perché una transazione non porta alcun numero di fattura. BIP70 lo risolveva consegnando al wallet del cliente un cookie e chiedendolo indietro. Oggi gli esercenti risolvono lo stesso problema con un indirizzo monouso per ordine, che è al tempo stesso più semplice e più riservato.

Come funziona

Stato: storico. Merchant data era il campo 7 di PaymentDetails e il campo 1 del messaggio Payment che tornava indietro, ed è scomparso con il resto di BIP70 quando è stato rilasciato Bitcoin Core 0.20.0 il 3 giugno 2020.

L'opacità era il punto. Al wallet veniva detto di trattare quei byte come privi di significato e di restituirli inalterati, il che permetteva a ogni esercente di inventare il proprio schema senza che nessun altro dovesse capirlo.

Due schemi erano comuni. Una breve chiave di ricerca, ad esempio un identificatore d'ordine di 16 byte, manteneva piccola la richiesta e spostava il lavoro sul database dell'esercente. Un blocco autocontenuto conteneva l'intero carrello e lasciava il server senza stato, al costo della dimensione.

Il secondo schema ha un buco che le specifiche segnalavano. Quei byte tornano da software su cui l'esercente non ha il controllo, quindi tutto ciò che se ne legge è input fornito da un attaccante. Un negozio che vi avesse memorizzato un prezzo o un codice sconto e si fosse fidato della copia restituita si sarebbe costruito un generatore di buoni sconto. Il rimedio è quello ordinario per uno stato che fa andata e ritorno: allegare un codice di autenticazione del messaggio e verificarlo prima di leggere un solo campo.

La dimensione contava più di quanto sembri. L'intera richiesta firmata doveva raggiungere il cliente, e renderla come codice QR impone un tetto rigido: il simbolo più grande, la versione 40 al livello di correzione degli errori più basso, contiene 2.953 byte di dati binari. Quel tetto è il motivo per cui BIP72 ha definito il parametro r=, così che un link breve potesse puntare a una richiesta servita via HTTPS invece di portarla con sé.

Dove lo vedi

Il compito che un tempo svolgevano i merchant data oggi lo svolge l'indirizzo stesso.

Un software di cassa come BTCPay Server deriva un indirizzo nuovo per ogni fattura, così un pagamento in arrivo identifica da solo il proprio ordine senza alcuna andata e ritorno e senza stato restituito. Questo batte BIP70 due volte: non c'è nulla che il pagatore possa manomettere, e si evita il riutilizzo degli indirizzi che altrimenti pubblicherebbe l'intero incasso di un esercente a chiunque legga la catena. Le piattaforme custodiali funzionano allo stesso modo, ed è così che un deposito arriva sul tuo conto e non su quello di qualcun altro.

Da tutto questo vale la pena portarsi via un avvertimento. Diverse altre reti richiedono un memo o un destination tag accanto a un deposito, e ometterlo fa finire i tuoi fondi in un conto collettivo senza nulla che li colleghi a te. Bitcoin non ha alcun campo del genere. Se una pagina di deposito ti chiede di allegare un tag, un memo o un codice di riferimento a una transazione bitcoin, il modulo è configurato male o è falso, e recuperare un deposito davvero inviato nel posto sbagliato è lento e spesso impossibile.

PP merchant data vs PP memo

I merchant data erano scritti per una macchina; un memo era scritto per una persona. I primi non venivano mai mostrati al cliente, il secondo esisteva solo per essere mostrato. I loro modi di fallire differiscono di conseguenza: un memo non verificato inganna una persona che legge una schermata di conferma, mentre i merchant data non verificati ingannano il software contabile dell'esercente stesso. Nessuno dei due era firmato al ritorno, ed è per questo che entrambi andavano trattati come non attendibili.