PaymentDetails

PaymentDetails était la partie que le commerçant signait réellement, et l'enveloppe externe ne portait que le certificat qui le prouvait. Il contenait sept champs : un nom de réseau valant par défaut main, une liste de sorties, un horodatage obligatoire, une expiration facultative, un mémo, une URL de rappel et un bloc opaque merchant_data. Un URI BIP21 accompagné d'une page de paiement remplit aujourd'hui la même fonction, sans signature et sans serveur.

Comment cela fonctionne

Statut : historique. Bitcoin Core a supprimé le BIP70 dans la version 0.20.0 le 3 juin 2020, et PaymentDetails n'a aucune implémentation active. Il est documenté ici parce que les noms de champs figurent encore dans d'anciens guides d'intégration et dans la référence pour développeurs de bitcoin.org.

C'est Protocol Buffers, et non JSON, qui portait la structure. Ce choix comptait pour une raison qui mérite qu'on s'y arrête : le commerçant sérialisait PaymentDetails en une chaîne d'octets et plaçait ces octets exacts dans le PaymentRequest externe comme champ opaque plutôt que comme message imbriqué. La signature couvrait la chaîne d'octets, de sorte qu'aucune bibliothèque réencodant les mêmes champs dans un ordre différent ne pouvait invalider une signature valide.

Les sept champs se répartissaient entre instructions et tenue de comptes.

• network, une chaîne valant par défaut "main", "test" étant la seule autre valeur définie.
• outputs, une liste répétée, chaque entrée associant un montant en satoshis à un script. Plus d'une sortie était autorisée, et les commerçants s'en servaient pour répartir le paiement d'un même client entre un portefeuille chaud et un stockage à froid sans demander au client d'envoyer deux fois.
• time, un horodatage unix obligatoire indiquant quand la demande avait été créée.
• expires, un horodatage unix facultatif après lequel un portefeuille était censé refuser. C'est ce champ qui donnait au BIP70 l'air d'un terminal de carte, car un commerçant pouvait annoncer un prix en monnaie fiduciaire et le garantir pendant une fenêtre fixe.
• memo, une note UTF-8 affichée au payeur.
• payment_url, l'adresse où le portefeuille publiait son message Payment après diffusion.
• merchant_data, des octets opaques renvoyés tels quels pour que le commerçant puisse rattacher un paiement à un panier d'achat.

Seuls time et les scripts de sortie étaient obligatoires. Tout le reste pouvait être omis par le commerçant, et la plupart l'omettaient.

Où cela se voit

L'idée derrière PaymentDetails a survécu au message, et c'est là ce qu'il est utile de remarquer.

L'expiration d'un prix est désormais gérée par la plateforme d'échange plutôt que dans votre portefeuille. Achetez via un écran d'achat instantané et vous obtenez un taux coté avec un compte à rebours à côté ; laissez le compte à rebours s'achever et la cotation est reconstruite au nouveau prix. C'est expires réimplémenté dans une application web, et cela protège le vendeur contre la volatilité exactement de la même façon. L'appariement des ordres dans un carnet d'ordres de plateforme d'échange remplit la même fonction autrement, en ne cotant jamais de prix fixe.

L'équivalent côté commerçant de tout le message est un enregistrement de facture dans un logiciel de paiement. BTCPay Server et des outils similaires génèrent un URI BIP21, le maintiennent ouvert pendant un nombre de minutes configuré et rapprochent la transaction entrante d'un identifiant de commande interne, ce qui est précisément à quoi servait merchant_data.

PaymentDetails vs reçu

PaymentDetails était la demande ; le reçu dans le BIP70 était le PaymentACK que le commerçant renvoyait ensuite. L'un décrivait ce qui devait se produire, l'autre confirmait que le commerçant l'avait vu se produire. Ni l'un ni l'autre n'était un fait de blockchain, et c'est la limite que les gens sous-estimaient : un accusé de réception signé par un commerçant prouve que le serveur du commerçant a dit quelque chose, pas qu'une transaction a été confirmée. Ce sont les confirmations, et non les reçus, qui règlent un paiement en bitcoin.