PaymentDetails

PaymentDetails era la parte che il commerciante firmava davvero, e la busta esterna portava solo il certificato che la attestava. Conteneva sette campi: un nome di rete con valore predefinito main, un elenco di output, una marca temporale obbligatoria, una scadenza facoltativa, un memo, un URL di callback e un blocco opaco merchant_data. Oggi un URI BIP21 più una pagina di pagamento fanno lo stesso lavoro senza firma e senza server.

Come funziona

Stato: storico. Bitcoin Core ha rimosso il BIP70 nella versione 0.20.0 il 3 giugno 2020, e PaymentDetails non ha alcuna implementazione attiva. Questo sito lo documenta perché i nomi dei campi compaiono ancora nelle vecchie guide all'integrazione e nella documentazione per sviluppatori di bitcoin.org.

La struttura viaggiava in Protocol Buffers, non in JSON. Quella scelta contava per un motivo su cui vale la pena soffermarsi: il commerciante serializzava PaymentDetails in una stringa di byte e inseriva quei byte esatti nel PaymentRequest esterno come campo opaco, non come messaggio annidato. La firma copriva la stringa di byte, così nessuna library che ricodificasse gli stessi campi in un ordine diverso poteva invalidare una firma valida.

I sette campi si dividevano in istruzioni e contabilità.

• network, una stringa con valore predefinito "main", con "test" come unico altro valore definito.
• outputs, un elenco ripetuto in cui ogni voce abbina un importo in satoshi a uno script. Più di un output era legale, e i commercianti lo usavano per dividere un singolo pagamento del cliente tra un hot wallet e il cold storage senza chiedere al cliente di inviare due volte.
• time, una marca temporale unix obbligatoria che registra quando è stata creata la richiesta.
• expires, una marca temporale unix facoltativa dopo la quale il wallet doveva rifiutare. È il campo che faceva sembrare il BIP70 un terminale per carte, perché un commerciante poteva quotare un prezzo in valuta fiat e garantirlo per una finestra fissa.
• memo, una nota UTF-8 mostrata a chi paga.
• payment_url, dove il wallet inviava il proprio messaggio Payment dopo la trasmissione.
• merchant_data, byte opachi restituiti intatti così che il commerciante potesse associare un pagamento a un carrello.

Solo time e gli script degli output erano obbligatori. Tutto il resto il commerciante poteva ometterlo, e la maggior parte lo faceva.

Dove lo vedi

L'idea alla base di PaymentDetails è sopravvissuta al messaggio, ed è la cosa utile da notare.

Oggi la scadenza del prezzo è gestita sull'exchange e non nel tuo wallet. Se acquisti da una schermata di acquisto istantaneo, ottieni un prezzo quotato con un conto alla rovescia accanto; lascia scadere il conto alla rovescia e la quotazione viene ricostruita al nuovo prezzo. È expires reimplementato in un'app web, e protegge il venditore dalla volatilità esattamente allo stesso modo. L'abbinamento degli ordini nell'order book di un exchange fa lo stesso lavoro in modo diverso, non quotando mai un prezzo fisso.

L'equivalente lato commerciante dell'intero messaggio è un record di fattura nel software di checkout. BTCPay Server e strumenti simili generano un URI BIP21, lo mantengono aperto per un numero configurabile di minuti e riconciliano la transazione in entrata con un identificatore interno dell'ordine, ed è precisamente a questo che serviva merchant_data.

PaymentDetails vs ricevuta

PaymentDetails era la richiesta; la ricevuta nel BIP70 era il PaymentACK che il commerciante restituiva dopo. Uno descriveva ciò che doveva accadere, l'altro confermava che il commerciante lo aveva visto accadere. Nessuno dei due era un fatto della blockchain, ed è questo il limite che le persone hanno sottovalutato: una conferma firmata da un commerciante dimostra che il server del commerciante ha detto qualcosa, non che una transazione è stata confermata. Sono le conferme, non le ricevute, a regolare un pagamento in bitcoin.