Payment IDs dans Monero: Pourquoi Ils Ont Été Abandonnés

L'Ascension et la Chute des Payment IDs

Les Payment IDs étaient autrefois une fonctionnalité omniprésente dans l'écosystème Monero. Si vous avez utilisé Monero avant 2019, vous les avez presque certainement rencontrés lors de dépôts sur des plateformes d'échange ou de paiements à des commerçants. Ces identifiants supplémentaires étaient annexés aux transactions pour aider les destinataires à distinguer les multiples paiements entrants. Malgré leur utilité, les Payment IDs ont introduit des problèmes significatifs de confidentialité et d'ergonomie qui ont finalement conduit à leur abandon.

Comprendre cette histoire est important pour quiconque utilise Monero aujourd'hui, surtout lorsqu'on interagit avec des services plus anciens qui peuvent encore faire référence aux Payment IDs. Que vous échangiez via MoneroSwapper ou gériez votre propre portefeuille, savoir ce qui a remplacé les Payment IDs et pourquoi vous aide à effectuer des transactions de manière plus sûre.

Qu'étaient les Payment IDs ?

Un Payment ID était une chaîne hexadécimale de 64 caractères (32 octets) pouvant être jointe à une transaction Monero. Considérez-le comme un numéro de référence ou un identifiant de facture intégré directement dans la transaction blockchain. Il existait deux types :

Payment IDs Longs (Non Chiffrés)

Le format original de Payment ID était une chaîne de 32 octets transmise en clair dans le champ supplémentaire de la transaction. Lorsque vous envoyiez une transaction avec un Payment ID long, toute personne consultant la blockchain pouvait voir la valeur du Payment ID. C'était la méthode la plus ancienne, largement utilisée par les plateformes d'échange et les processeurs de paiement.

Le problème était immédiatement apparent du point de vue de la confidentialité : si une plateforme d'échange publiait son adresse de dépôt et attribuait des Payment IDs uniques à chaque utilisateur, un observateur pouvait identifier tous les dépôts vers cette plateforme et potentiellement relier les Payment IDs à des utilisateurs spécifiques par l'analyse du timing ou des montants.

Payment IDs Chiffrés (Payment IDs Courts)

Pour résoudre le problème du texte clair, Monero a introduit les Payment IDs chiffrés en 2017. Il s'agissait de valeurs de 8 octets chiffrées avec un secret partagé dérivé des clés à usage unique de la transaction. Seul le destinataire pouvait déchiffrer le Payment ID à l'aide de sa clé privée de visualisation. Sur la blockchain, le Payment ID chiffré apparaissait comme des données aléatoires pour tous les autres.

Les Payment IDs chiffrés étaient intégrés aux adresses intégrées, qui combinaient une adresse Monero standard avec un Payment ID de 8 octets en une seule chaîne d'adresse. Cela les rendait plus faciles à utiliser car l'expéditeur n'avait pas besoin de copier-coller manuellement un champ de Payment ID séparé.

Pourquoi les Plateformes et Services Utilisaient les Payment IDs

La raison pratique des Payment IDs était simple : les plateformes d'échange et les commerçants devaient attribuer les paiements entrants à des utilisateurs ou des commandes spécifiques. Comme Monero utilise des adresses furtives qui rendent chaque sortie de transaction unique, un service recevant des milliers de dépôts quotidiennement avait besoin d'un mécanisme pour déterminer quel dépôt appartenait à quel client.

Le flux de travail typique était :

• La plateforme d'échange donne à tous les utilisateurs la même adresse de dépôt mais attribue à chaque utilisateur un Payment ID unique
• L'utilisateur envoie des XMR à l'adresse de la plateforme avec le Payment ID attribué
• La plateforme scanne les transactions entrantes par Payment ID pour créditer le bon compte

Ce système fonctionnait mais était fragile. Les utilisateurs oubliaient fréquemment d'inclure le Payment ID, entraînant des dépôts perdus nécessitant une récupération manuelle par les équipes de support. C'était l'un des problèmes de support les plus courants pour les plateformes acceptant Monero et une source majeure de frustration pour les utilisateurs.

Les Problèmes de Confidentialité des Payment IDs

Même les Payment IDs chiffrés introduisaient plusieurs vulnérabilités de confidentialité qui compromettaient les garanties fondamentales de confidentialité de Monero :

Traçabilité par les Métadonnées

Lorsque tous les utilisateurs d'une plateforme envoyaient à la même adresse, le mécanisme d'adresse furtive était compromis. Un observateur pouvait identifier qu'une transaction était destinée à une plateforme spécifique simplement en reconnaissant l'adresse publique. Le Payment ID, même chiffré, ajoutait des métadonnées distinctives à la transaction. Les transactions avec Payment IDs semblaient différentes de celles sans, créant deux classes de transactions réduisant l'ensemble d'anonymat.

Le Problème des Deux Pools

Les transactions avec Payment IDs et celles sans formaient deux pools visuellement distincts sur la blockchain. Cette distinction fournissait des informations aux analystes de chaîne. Si une transaction contenait un Payment ID chiffré, il était très probable qu'elle soit destinée à une plateforme d'échange ou un commerçant, réduisant considérablement les destinataires possibles.

Analyse du Timing et des Schémas

Les plateformes traitaient généralement les dépôts par lots ou avec un timing prévisible. Combiné au modèle d'adresse de dépôt unique, cela créait des schémas que des analystes sophistiqués pouvaient exploiter. La combinaison d'une adresse connue, de schémas temporels et de la présence de Payment IDs rendait les attaques de corrélation plus réalisables qu'elles n'auraient dû l'être.

L'Erreur Utilisateur comme Fuite de Confidentialité

Lorsque les utilisateurs oubliaient le Payment ID, ils devaient souvent contacter le support et prouver que la transaction était la leur. Cela impliquait généralement de partager la clé privée de la transaction ou des informations de la clé de visualisation, créant une fuite supplémentaire de confidentialité et une trace documentaire reliant leur identité à la transaction.

Le Calendrier d'Abandon

La communauté Monero a reconnu ces problèmes et a agi à travers plusieurs mises à niveau du protocole :

• 2018 (v0.13, Beryllium Bullet) — Les Payment IDs longs (non chiffrés) ont été dépréciés, et les logiciels de portefeuille ont commencé à afficher des avertissements lorsque les utilisateurs tentaient de les utiliser
• 2019 (v0.15, Carbon Chamaeleon) — Les Payment IDs longs ont été interdits au niveau du protocole. Les transactions avec des Payment IDs non chiffrés étaient rejetées par le réseau
• Mises à jour des logiciels de portefeuille — Les portefeuilles GUI et CLI ont progressivement supprimé les champs de Payment ID et encouragé l'utilisation des sous-adresses
• Migration des plateformes — Les principales plateformes ont migré des Payment IDs vers les sous-adresses au cours de 2019 et 2020, certains retardataires prenant plus de temps

Les Payment IDs chiffrés (courts) via les adresses intégrées fonctionnent encore techniquement au niveau du protocole, mais sont fortement déconseillés. Les logiciels de portefeuille modernes cachent complètement l'option ou affichent des avertissements clairs. Le consensus de la communauté est que les sous-adresses sont le remplacement approprié.

Sous-adresses : Le Remplacement Supérieur

Les sous-adresses ont été introduites comme le remplacement recommandé des Payment IDs. Une sous-adresse est une adresse unique dérivée de l'adresse principale de votre portefeuille à l'aide d'une relation mathématique que seul votre portefeuille peut calculer. Chaque sous-adresse est cryptographiquement liée à votre adresse principale, mais le lien est invisible pour les observateurs extérieurs.

Comment Fonctionnent les Sous-adresses

Votre portefeuille Monero peut générer un nombre essentiellement illimité de sous-adresses à partir de votre adresse primaire. Chaque sous-adresse ressemble à une adresse Monero complètement indépendante pour quiconque consulte la blockchain. Lorsque quelqu'un envoie des XMR à votre sous-adresse, la sortie de la transaction utilise les clés publiques de la sous-adresse pour générer l'adresse furtive, garantissant que seul votre portefeuille peut identifier le paiement.

Les principaux avantages des sous-adresses par rapport aux Payment IDs incluent :

• Pas d'adresse partagée — Chaque client ou paiement reçoit une adresse unique, éliminant totalement le problème de l'adresse unique
• Pas de fuite de métadonnées — Les transactions vers les sous-adresses sont identiques aux transactions vers les adresses principales sur la blockchain
• Pas d'erreur utilisateur — Les utilisateurs envoient simplement à l'adresse fournie sans avoir besoin de se souvenir d'un champ de Payment ID supplémentaire
• Non reliables — Un observateur ne peut pas déterminer que deux sous-adresses appartiennent au même portefeuille
• Pas de problème de deux pools — Toutes les transactions se ressemblent, qu'elles utilisent des adresses principales ou des sous-adresses

Sous-adresses pour les Plateformes d'Échange

Pour les plateformes qui utilisaient précédemment des Payment IDs, la migration vers les sous-adresses a amélioré à la fois la sécurité et l'expérience utilisateur. Au lieu de donner à chaque utilisateur la même adresse avec différents Payment IDs, les plateformes génèrent maintenant une sous-adresse unique pour chaque utilisateur. Le portefeuille de la plateforme identifie automatiquement quelle sous-adresse a reçu le dépôt et crédite le bon compte.

Cette approche a éliminé le problème de support le plus courant (les Payment IDs oubliés) tout en améliorant simultanément la confidentialité de tous les utilisateurs. C'était un cas rare où la solution la plus confidentielle était aussi la plus conviviale.

Guide de Migration pour les Services Utilisant Encore des Payment IDs

Si vous exploitez un service qui utilise encore des Payment IDs, la migration vers les sous-adresses est simple :

• Générez des sous-adresses — Utilisez la méthode RPC du portefeuille create_address pour générer une sous-adresse unique pour chaque compte utilisateur
• Stockez le mappage — Maintenez une base de données reliant les comptes utilisateurs à leurs sous-adresses attribuées
• Mettez à jour les instructions de dépôt — Supprimez les champs de Payment ID de votre interface de dépôt et affichez uniquement la sous-adresse
• Surveillez les transactions entrantes — Utilisez la méthode RPC get_transfers, qui signale automatiquement l'index de la sous-adresse pour chaque transaction entrante
• Maintenez la compatibilité ascendante — Pendant une période de transition, continuez à scanner les anciennes transactions avec Payment ID afin que les utilisateurs ayant conservé les anciennes instructions de dépôt ne soient pas affectés

Que Faire Si Vous Rencontrez un Service Demandant des Payment IDs

Malgré l'abandon datant de plusieurs années, certaines petites plateformes et services demandent encore des Payment IDs. Si vous vous trouvez dans cette situation, voici ce que vous devez savoir :

Procédez avec prudence. Un service utilisant encore des Payment IDs en 2026 ne suit peut-être pas les changements du protocole Monero, ce qui pourrait indiquer des préoccupations plus larges de maintenance et de sécurité. Évaluez si le service est digne de confiance.

Utilisez les adresses intégrées si proposées. Si le service fournit une adresse intégrée (qui incorpore le Payment ID), votre portefeuille gérera le Payment ID automatiquement. C'est préférable à la saisie manuelle d'un long Payment ID.

Vérifiez le Payment ID deux fois. Si vous devez saisir un Payment ID manuellement, copiez-collez-le soigneusement. Vérifiez chaque caractère. Un mauvais Payment ID signifie des fonds perdus qui peuvent être difficiles à récupérer.

Envisagez des alternatives. Si un service exige un Payment ID long (non chiffré), le logiciel Monero moderne rejettera probablement la transaction. Vous devrez peut-être utiliser un service différent ou demander qu'ils passent aux sous-adresses. Des services comme MoneroSwapper utilisent une infrastructure moderne qui ne nécessite pas de Payment IDs.

La Leçon Plus Large

L'abandon des Payment IDs illustre un principe clé de la philosophie de développement de Monero : la confidentialité ne concerne pas seulement les primitives cryptographiques, mais aussi la conception du protocole et les schémas d'utilisation dans le monde réel. Même avec un chiffrement fort, les métadonnées et schémas comportementaux créés par les Payment IDs étaient suffisants pour affaiblir les garanties de confidentialité.

En remplaçant les Payment IDs par des sous-adresses, Monero a éliminé toute une classe de fuites de confidentialité tout en améliorant l'ergonomie. Ce type d'amélioration itérative, où le protocole évolue en se basant sur l'analyse de la confidentialité dans le monde réel, est ce qui distingue Monero des projets qui traitent la confidentialité comme une fonctionnalité plutôt qu'une exigence fondamentale. La suppression des Payment IDs a rendu chaque transaction Monero plus confidentielle en éliminant les métadonnées distinctives et en créant un pool de transactions plus uniforme.

Pour les utilisateurs d'aujourd'hui, le message pratique est simple : utilisez des sous-adresses pour tout, évitez les services qui exigent encore des Payment IDs quand c'est possible, et appréciez que ce changement de protocole apparemment mineur représente des années de recherche et d'effort communautaire pour renforcer la confidentialité de Monero pour tous.