PaymentRequest

PaymentRequest était le message qui permettait à un portefeuille d'afficher le nom d'une entreprise au lieu d'une suite de caractères. Il comportait cinq champs, et les deux qui comptaient étaient pki_type, l'un de none, x509+sha256 ou x509+sha1, et signature, portant sur les détails sérialisés. Pour qui paie aujourd'hui, la leçon survit au protocole : un nom affiché sur un écran de paiement n'est digne de confiance que dans la mesure où quelqu'un s'est porté garant de lui.

Comment cela fonctionne

Statut : obsolète. Bitcoin Core a pris en charge le traitement de PaymentRequest de 0.9.0 jusqu'à ce que 0.20.0 le retire le 3 juin 2020, et aucun portefeuille maintenu n'analyse ce message aujourd'hui.

Cinq champs, dans l'ordre :

• payment_details_version, un entier de 32 bits valant 1 par défaut. Il n'a jamais été incrémenté.
• pki_type, une chaîne valant « none » par défaut. Les alternatives étaient « x509+sha256 » et « x509+sha1 ».
• pki_data, contenant une structure X509Certificates avec le certificat feuille du marchand en premier et les éventuels intermédiaires ensuite.
• serialized_payment_details, obligatoire, la chaîne d'octets opaque décrite ailleurs dans ce glossaire.
• signature, les octets prouvant que l'ensemble vient bien du détenteur du certificat.

La procédure de signature comporte une petite astuce. Le marchand remplit chaque champ, met signature à vide, sérialise le message complet, hache ce résultat, signe le hachage avec la clé privée associée au certificat feuille, puis écrit la signature dans le champ qu'il venait de laisser vide. Un vérificateur vide à nouveau le champ, resérialise et vérifie. Simple, autonome, et dépendant de rien d'autre que du certificat.

Cette dépendance était le problème. Valider la chaîne exigeait que le portefeuille détienne un magasin de certificats racines, que les logiciels de bureau héritaient du système d'exploitation et que les logiciels mobiles traitaient souvent mal. Même une implémentation correcte prouvait seulement qu'une autorité de certification avait attesté un nom de domaine, et un magasin de racines contient des centaines d'autorités, dont chacune peut délivrer un certificat pour n'importe quel nom. L'option la plus faible proposée, x509+sha1, a particulièrement mal vieilli : une collision SHA-1 pratique a été publiée le 23 février 2017, quatre ans après la rédaction du BIP70.

Où cela se voit

Deux endroits utilisent encore le nom PaymentRequest, et un seul concerne le bitcoin.

Le premier est le code et la documentation archivés, où le type MIME BIP71 application/bitcoin-paymentrequest marquait la réponse renvoyée par un serveur marchand. Le second est la plateforme web moderne, où PaymentRequest désigne une API de navigateur pour le paiement par carte et les moyens de paiement enregistrés, sans aucun rapport avec ce protocole. Un développeur qui emploie ce mot aujourd'hui pense presque certainement à celle du navigateur, et confondre les deux est l'erreur la plus courante dans les recherches sur l'ancienne documentation bitcoin.

Pour qui achète du bitcoin, la conclusion porte sur la manière dont une identité se rattache aux paiements. Les plateformes d'échange résolvent la question par des comptes et la vérification d'identité : la plateforme sait qui vous êtes et vous vous fiez à sa réputation. L'auto-conservation résout la question en vous faisant vérifier l'adresse vous-même. Le BIP70 tentait une troisième voie, en empruntant le système de certificats du web, et cette voie est fermée.

PaymentRequest vs PaymentDetails

PaymentRequest est l'enveloppe ; PaymentDetails est la lettre qu'elle contient. Lire l'enveloppe indique qui a signé et avec quel certificat, mais pas ce qui est demandé. Les montants, les scripts, l'expiration et le mémo se trouvent tous dans le message interne, qui figure dans l'enveloppe sous forme de chaîne d'octets non analysée précisément pour que la signature ne puisse pas être invalidée par un réencodage. Un portefeuille devait vérifier la première avant de se fier à quoi que ce soit dans le second.