Données marchand PP

Associer un paiement à une commande est le problème ingrat que toute caisse doit résoudre, et le bitcoin le complique parce qu'une transaction ne porte aucun numéro de facture. Le BIP70 le résolvait en remettant au portefeuille du client un cookie et en le lui réclamant ensuite. Les marchands d'aujourd'hui résolvent le même problème avec une adresse à usage unique par commande, ce qui est à la fois plus simple et plus confidentiel.

Comment cela fonctionne

Statut : historique. Les données marchand étaient le champ 7 de PaymentDetails et le champ 1 du message Payment renvoyé, et elles ont disparu avec le reste du BIP70 lorsque Bitcoin Core 0.20.0 est sorti le 3 juin 2020.

L'opacité était voulue. Le portefeuille devait traiter ces octets comme dépourvus de sens et les renvoyer sans modification, ce qui laissait chaque marchand inventer son propre schéma sans que quiconque d'autre ait besoin de le comprendre.

Deux schémas étaient courants. Une courte clé de recherche, par exemple un identifiant de commande de 16 octets, maintenait la demande à une taille réduite et reportait le travail sur la base de données du marchand. Un bloc autonome contenait tout le panier et laissait le serveur sans état, au prix de la taille.

Le second schéma comporte une faille contre laquelle la spécification mettait en garde. Ces octets reviennent depuis un logiciel que le marchand ne contrôle pas, donc tout ce qu'on y lit est une entrée fournie par un attaquant. Une boutique qui y stockait un prix ou un code de réduction et faisait confiance à la copie renvoyée s'était fabriqué un générateur de coupons. Le remède est celui qui vaut pour tout état renvoyé : joindre un code d'authentification de message et le vérifier avant de lire le moindre champ.

La taille comptait plus qu'il n'y paraît. Toute la demande signée devait parvenir au client, et son rendu sous forme de code QR impose un plafond strict : le plus grand symbole, la version 40 au plus faible niveau de correction d'erreur, contient 2 953 octets de données binaires. C'est à cause de ce plafond que le BIP72 a défini le paramètre r=, afin qu'un lien court puisse pointer vers une demande servie en HTTPS au lieu de la transporter.

Où cela se voit

Le travail que faisaient les données marchand est désormais fait par l'adresse elle-même.

Un logiciel de caisse comme BTCPay Server dérive une adresse nouvelle pour chaque facture, si bien qu'un paiement qui arrive identifie sa propre commande sans aller-retour et sans état renvoyé. Cela l'emporte sur le BIP70 à deux titres : le payeur n'a rien à falsifier, et cela évite la réutilisation d'adresse qui publierait sinon tout le chiffre d'affaires d'un marchand à quiconque lit la chaîne. Les plateformes qui conservent vos fonds fonctionnent de la même manière, ce qui fait qu'un dépôt arrive sur votre compte et non sur celui d'un autre.

Un avertissement mérite d'être retenu. Plusieurs autres réseaux exigent un memo ou un tag de destination en plus du dépôt, et son omission fait tomber vos fonds dans un compte mutualisé sans rien qui les relie à vous. Bitcoin n'a pas de tel champ. Si une page de dépôt vous demande de joindre un tag, un memo ou un code de référence à une transaction bitcoin, le formulaire est mal configuré ou frauduleux, et récupérer un dépôt réellement mal dirigé est lent et souvent impossible.

Données marchand PP vs mémo PP

Les données marchand étaient écrites pour une machine, un memo était écrit pour une personne. Les premières n'étaient jamais montrées au client, le second n'existait que pour être montré. Leurs modes de défaillance diffèrent en conséquence : un memo non vérifié trompe un humain qui lit un écran de confirmation, tandis que des données marchand non vérifiées trompent le logiciel de comptabilité du marchand lui-même. Aucun des deux n'était signé au retour, raison pour laquelle les deux devaient être traitées comme non fiables.