Glossario / Riferimento per sviluppatori
PaymentRequest
- Che cos'è PaymentRequest?
- PaymentRequest è l'involucro esterno del BIP70: racchiude un blob serializzato di PaymentDetails insieme a una catena di certificati e a una firma, così il pagatore poteva verificare chi stava facendo la richiesta.
Specificato nel BIP-70.
PaymentRequest era il messaggio che permetteva a un wallet di mostrare il nome di un'azienda invece di una stringa di caratteri. Aveva cinque campi, e i due che contavano erano pki_type, uno tra none, x509+sha256 o x509+sha1, e signature, la firma sui dettagli serializzati. Per chi paga oggi la lezione sopravvive al protocollo: un nome su una schermata di pagamento è affidabile solo quanto chi lo ha attestato.
Come funziona
Stato: obsoleto. Bitcoin Core ha gestito PaymentRequest da 0.9.0 fino a quando 0.20.0 lo ha rimosso il 3 giugno 2020, e oggi nessun wallet mantenuto interpreta il messaggio.
Cinque campi, in ordine:
payment_details_version, un intero di 32 bit con valore predefinito 1. Non è mai stato incrementato.pki_type, una stringa con valore predefinito "none". Le alternative erano "x509+sha256" e "x509+sha1".pki_data, che conteneva una struttura X509Certificates con il certificato foglia del venditore per primo e gli eventuali intermedi dopo.serialized_payment_details, obbligatorio, la stringa di byte opaca descritta altrove in questo glossario.signature, i byte che provano che l'intero messaggio proviene dal titolare del certificato.
La procedura di firma contiene un piccolo trucco. Il venditore compila ogni campo, imposta signature vuoto, serializza il messaggio completo, ne calcola l'hash, firma l'hash con la chiave privata del certificato foglia e poi scrive la firma nel campo che aveva appena lasciato vuoto. Chi verifica svuota di nuovo il campo, riserializza e controlla. Semplice, autonomo e dipendente da nient'altro che dal certificato.
Quella dipendenza era il problema. Validare la catena richiedeva che il wallet avesse un archivio di certificati radice, che il software desktop ereditava dal sistema operativo e che il software mobile spesso gestiva male. Anche un'implementazione corretta dimostrava solo che qualche autorità di certificazione aveva attestato un nome di dominio, e un archivio radice contiene centinaia di autorità, ognuna delle quali può emettere certificati per qualsiasi nome. L'opzione più debole disponibile, x509+sha1, è invecchiata particolarmente male: una collisione pratica di SHA-1 è stata pubblicata il 23 febbraio 2017, quattro anni dopo che il BIP70 era stato scritto.
Dove lo vedi
Due luoghi usano ancora il nome PaymentRequest, e solo uno dei due riguarda bitcoin.
Il primo è il codice e la documentazione archiviati, dove il tipo MIME BIP71 application/bitcoin-paymentrequest contrassegnava la risposta che restituiva il server di un venditore. Il secondo è la piattaforma web moderna, dove PaymentRequest indica un'API del browser per il pagamento con carta e con metodi di pagamento salvati che non ha nulla a che vedere con questo protocollo. Uno sviluppatore che usa oggi la parola intende quasi certamente quella del browser, e confondere le due è l'errore più comune nelle ricerche sulla vecchia documentazione di bitcoin.
Per chi compra bitcoin, la conclusione riguarda come l'identità viene associata ai pagamenti. Gli exchange lo risolvono con account e KYC, così la piattaforma sa chi sei e tu ti affidi alla reputazione della piattaforma. L'autocustodia lo risolve facendoti verificare l'indirizzo da solo. Il BIP70 ha provato una terza via, prendendo in prestito il sistema dei certificati del web, e quella via è chiusa.
PaymentRequest vs PaymentDetails
PaymentRequest è l'involucro; PaymentDetails è la lettera che sta dentro. Leggere l'involucro dice chi ha firmato e quale certificato ha usato, ma non che cosa viene richiesto. Gli importi, gli script, la scadenza e il memo stanno tutti nel messaggio interno, che si trova nell'involucro come stringa di byte non interpretata proprio perché la firma non possa essere invalidata da una nuova codifica. Un wallet doveva verificare il primo prima di fidarsi di qualsiasi cosa nel secondo.