Montant PP

Les unités sont la source des bugs de paiement. Le montant BIP70 était un nombre de satoshis codé sur 64 bits, alors que le paramètre amount d'un URI BIP21 est du bitcoin décimal : un même paiement s'écrit donc 250000 dans le premier et 0,0025 dans le second. Quiconque déplace des fonds entre plusieurs systèmes doit vérifier l'unité attendue par un champ avant de se fier à un total.

Comment cela fonctionne

Statut : historique. Le champ appartenait à BIP70, que Bitcoin Core a rendu obsolète dans la version 0.19 et a supprimé dans la version 0.20.0 le 3 juin 2020.

Deux champs composaient une sortie Output dans un message PaymentDetails : un script indiquant où va l'argent, et un montant indiquant combien. Le montant était un entier non signé de 64 bits exprimé en satoshis, avec une valeur par défaut de zéro, et zéro avait un sens précis. Il ne signifiait pas ne rien payer. Il signifiait que le commerçant refusait de fixer un chiffre et que le portefeuille devait demander au client, ce qui permettait le fonctionnement des pages de don.

Plusieurs sorties pouvaient figurer dans une même demande, chacune avec son propre montant, et un portefeuille payeur devait satisfaire chacune d'elles dans une seule transaction. Cela est plus utile qu'il n'y paraît. Un commerçant pouvait acheminer une partie d'une vente directement vers un stockage à froid, une autre vers un portefeuille chaud pour les remboursements, et une autre vers un affilié, sans que le client ait à envoyer trois paiements ni à connaître cette répartition.

La plage n'a jamais été une contrainte. Un entier non signé de 64 bits plafonne à 18 446 744 073 709 551 615 satoshis, soit environ 8 800 fois les 2 100 000 000 000 000 satoshis qui existeront un jour. La limite intéressante se situait à l'autre extrémité. Un montant inférieur au seuil de poussière produisait une sortie que le réseau ne relayerait pas, et la politique de Bitcoin Core fixe ce seuil à 546 satoshis pour une sortie héritée pay-to-public-key-hash et à 294 pour une sortie segwit à clé unique.

Où le rencontre-t-on

Rien n'implémente aujourd'hui le champ de montant BIP70, mais la confusion d'unités qui le sous-tend est bien vivante.

Trois spécifications, trois unités. Les URI BIP21 expriment du bitcoin. BIP70 exprimait des satoshis. Les factures Lightning BOLT11 vont plus loin encore et expriment des millisatoshis, soit un millième de satoshi. Les interfaces de portefeuille ajoutent ensuite un réglage d'affichage, si bien qu'un même solde apparaît comme 0,00250000 ou comme 250 000 selon une préférence que vous avez définie une fois et oubliée.

Le coût pratique de cette erreur est de l'argent réel. Les estimations de frais arrivent en satoshis par octet virtuel : une dépense segwit avec une entrée et deux sorties d'environ 141 octets virtuels coûte 705 satoshis à 5 sat/vB. Lisez ce chiffre comme du bitcoin et vous croiriez qu'une transaction de routine coûte plus que ce que la plupart des gens dépensent en frais sur une année.

Deux habitudes corrigent cela. Choisissez une seule dénomination dans les réglages de votre portefeuille et n'y touchez plus, afin que le nombre de chiffres attendu ne change jamais. Et lisez l'unité indiquée sur tout écran de retrait avant de lire le nombre, car les minimums des plateformes d'échange, les frais de réseau et votre solde sont souvent exprimés dans des unités différentes sur la même page.

Montant PP vs montant d'un URI Bitcoin

Un montant BIP70 était un entier de satoshis ; un montant BIP21 est un décimal de bitcoin, et le facteur entre les deux est 100 000 000. Toute la différence est là, et elle suffit à avoir de l'importance. Un champ qui contient 0,0025 dans un format contient 250000 dans l'autre, et un logiciel qui passe de l'un à l'autre sans convertir produit une erreur de huit ordres de grandeur, dans un sens comme dans l'autre. Le format moderne l'a emporté : le nombre que vous rencontrez aujourd'hui dans un lien de paiement est donc du bitcoin, sauf mention explicite de sats.