Silent Payments BIP-352 : confidentialité et limites

Tu affiches une adresse Bitcoin pour recevoir des paiements. Une fois. Sur une page de dons, une facture ou un profil public. Si tu la réutilises, n’importe qui peut retrouver sur la chaîne les versements reçus à cette même destination. Tu n’as pas publié ton identité bancaire ; tu as quand même offert un point de regroupement.

Silent Payments, défini par le BIP-352, propose une issue précise : publier une adresse de réception stable, tandis que chaque paiement crée une sortie Bitcoin distincte que l’observateur extérieur ne peut pas relier à cette adresse par le seul examen de la chaîne. C’est une protection utile pour celui qui reçoit régulièrement. Encore faut-il un wallet capable de l’utiliser et de retrouver les paiements.

Le problème n’est pas de publier une adresse. C’est de la réutiliser sur la chaîne

Quand tu publies la même adresse Bitcoin dans plusieurs endroits, tu facilites les paiements. Tu facilites aussi l’enquête. L’explorateur de blocs n’a pas besoin de connaître ton nom pour réunir les sorties envoyées à cette adresse, voir leurs montants et suivre leurs dépenses ultérieures. Si ton nom figure sur la page où tu as affiché l’adresse, l’étape d’identification est déjà faite.

La parade classique consiste à donner une adresse différente à chaque payeur. C’est simple quand un wallet peut créer une nouvelle facture à chaque échange. C’est beaucoup moins pratique pour une page de dons imprimée, un QR code sur une carte ou un profil que tu ne peux pas mettre à jour à chaque versement. Donner une liste d’adresses à l’avance reporte seulement le problème : il faut distribuer la bonne et surveiller celles qui ont déjà servi.

Exemple hypothétique : tu publies un QR code pour un projet indépendant. Trois personnes te versent chacune 0,01 BTC à des dates différentes. Sur une adresse classique réutilisée, ces trois paiements se retrouvent au même endroit public. Le vrai enjeu est le lien entre une identité publiée et une série de versements.

Le BIP-352 vise exactement cette situation : une adresse stable à communiquer sans créer, pour chaque paiement, une sortie réutilisant cette adresse.

Une adresse à afficher, une sortie différente pour chaque paiement

La transaction reste inscrite sur Bitcoin. Ce qui change, c’est la manière de calculer la sortie destinée au receveur.

Le receveur publie des données permettant de former son adresse Silent Payments. Le wallet de l’expéditeur combine ces données avec des informations issues des entrées qu’il utilise pour créer une destination propre au paiement. Le wallet du receveur parcourt ensuite les transactions pertinentes et retrouve celles qui lui appartiennent grâce à sa clé de scan. Il n’a pas eu besoin de générer une nouvelle adresse à remettre à l’expéditeur ni de recevoir une notification inscrite à part sur la chaîne.

Pour l’observateur qui n’a que l’adresse publiée et la chaîne, les sorties obtenues ne ressemblent pas à des paiements répétés à une même adresse. Pour l’expéditeur, en revanche, le destinataire choisi n’est pas un mystère : il a eu son adresse sous les yeux. Si une facture, un échange de messages ou une plateforme révèle le lien, BIP-352 ne peut pas l’effacer. La protection porte sur le lien public entre l’adresse stable et les sorties, pas sur les informations détenues ailleurs.

Le mécanisme utilise des sorties Taproot existantes, sans transaction de notification distincte. Les entrées de l’expéditeur et les montants restent visibles. Lors de la dépense des fonds, d’autres rapprochements redeviennent possibles.

Le coût de la discrétion se déplace vers ton wallet

Dans un paiement ordinaire, ton wallet sait quelles adresses il a créées. Avec Silent Payments, une adresse publiée peut conduire à des sorties différentes à chaque envoi. Le receveur doit donc scanner les transactions éligibles pour trouver celles qui lui reviennent. Le BIP chiffre à 33 octets les données de tweak à fournir par transaction éligible pour faciliter ce travail. Son estimation de 30 à 50 Mo par mois s’appuie sur des données de janvier 2023 à juillet 2024 : c’est un repère historique du volume de données, pas une mesure de la consommation d’un wallet en 2026.

Ce coût n’est pas une taxe supplémentaire inscrite sur chaque paiement. C’est du calcul, du temps, de la batterie et des données à recevoir. Un wallet léger qui ne conserve pas lui-même une vue complète du réseau doit obtenir les informations nécessaires au scan. Cake Wallet documente le recours à un serveur Electrum doté de l’index tweaks et un repli possible vers son infrastructure. Ce serveur fournit des données de scan ; sa présence ne prouve pas qu’il possède ta clé privée de scan ni qu’il identifie à lui seul tes réceptions. Elle compte néanmoins dans le choix de l’intermédiaire dont tu dépends pour retrouver les fonds.

Deux clés jouent des rôles distincts. La clé de scan sert à repérer les paiements ; la clé de dépense sert à les dépenser. Cette séparation permet de garder la capacité de dépense hors ligne tout en laissant un appareil connecté chercher les versements. Elle ne dispense pas de protéger la clé de scan : quelqu’un qui la possède peut apprendre quels paiements arrivent, même s’il ne peut pas les dépenser avec elle seule.

La restauration mérite le même sérieux. Retrouver la phrase de récupération ne signifie pas nécessairement revoir instantanément tous les paiements. Le wallet peut devoir parcourir de nouveau les transactions pour les retrouver. Vérifie aussi comment sauvegarder les éventuels labels, ces étiquettes qui servent à distinguer les sources de paiement. Avant d’afficher partout le même QR code, teste les fonctions de sauvegarde, de restauration et de rescan du wallet qui reçoit les fonds.

Envoyer et recevoir : vérifie les deux wallets

BIP-352 décrit un protocole et un format d’adresse nouveaux. Une vieille application qui sait recevoir du Bitcoin par une adresse classique ne sait pas automatiquement recevoir par Silent Payments. La spécification précise que les anciens logiciels, ou ceux qui n’ont pas implémenté le protocole, ne sont pas compatibles. Cette limite est structurelle, pas un réglage caché.

Vérifie séparément deux capacités. Envoyer vers une adresse Silent Payments exige que le wallet de l’expéditeur sache construire la sortie correcte à partir des entrées de sa transaction. Recevoir exige que le wallet du destinataire génère l’adresse, repère les paiements, conserve les informations nécessaires et puisse ensuite dépenser les sorties détectées. Le mot « support » peut désigner l’une de ces deux moitiés ; il faut demander laquelle. Une plateforme d’échange ou un wallet qui refuse l’adresse ne devient pas compatible parce que le destinataire a installé un autre logiciel.

Le support réel dépend des versions et de la fonction. Au 22 octobre 2026, la documentation de Cake décrit l’envoi et la réception, mais réserve la réception Silent Payments au premier compte Bitcoin et demande d’activer le scan. Les notes de version de Sparrow distinguent le support matériel à l’envoi introduit en 2.4.0, le 10 février 2026, des wallets de réception ajoutés en 2.5.0, le 21 mai 2026. Ce sont deux exemples documentés, pas une liste exhaustive ni une promesse sur toute version installée.

Si tu envisages un usage réel, vérifie la documentation de ta version, fais un petit envoi depuis une source compatible, constate la détection, puis teste la restauration avant d’y faire transiter des montants importants.

La question touche aussi à ta liberté d’accès. Nous avons déjà expliqué pourquoi détenir tes clés ne te place pas automatiquement hors système : acquisition, connexion au réseau et intermédiaires comptent encore. Silent Payments règle un problème différent et plus étroit, celui de l’adresse de réception publique réutilisée.

Dépenses et labels peuvent encore laisser des indices

Si tu rassembles plusieurs sorties dans une dépense, tu crées d’autres indices possibles. Masquer le lien à la réception n’efface pas les indices que tu peux laisser en dépensant les fonds. Un service qui t’identifie lors de l’achat peut aussi conserver ses propres données : ce lien extérieur ne disparaît pas avec BIP-352.

Les labels ne créent pas des identités publiques indépendantes. Ils distinguent des sources de paiement sans imposer autant de scans séparés, mais des adresses étiquetées qui partagent la même clé de scan peuvent être reconnues comme appartenant au même receveur. Deux activités que tu voulais garder distinctes deviennent ainsi rapprochables.

Notre position est simple : afficher une adresse permanente tout en publiant involontairement son historique de réception est une mauvaise concession. BIP-352 apporte une réponse technique crédible. La discrétion se paie ici en contraintes de logiciel, de scan et de sauvegarde. Si ton cas d’usage est ponctuel et qu’une adresse différente peut être remise à chaque payeur, tu disposes déjà d’une solution plus simple. Si tu as besoin d’un point de réception public durable, Silent Payments mérite alors un examen sérieux.

Avant de publier un QR code pour longtemps, pose trois questions à ton wallet : sait-il recevoir par BIP-352, comment retrouve-t-il les paiements, et comment les récupères-tu après restauration ? Puis pose une quatrième question à celui qui t’envoie des fonds : son logiciel sait-il envoyer à cette adresse ? La discrétion d’une adresse n’a de valeur que si tu peux recevoir, retrouver et dépenser l’argent sans confier ta sécurité à un mot dans une fiche produit.