Silent Payments

Si Bob publie une adresse Bitcoin ordinaire, chacun peut suivre ses encaissements dans un explorateur. Un explorateur de blocs est une application permettant de consulter les transactions et les blocs d’un réseau donné. Fournir une nouvelle adresse à chaque personne est préférable, mais il faut pouvoir les distribuer. Silent Payments traite ce problème : Bob publie des données fixes et Alice s’en sert pour créer une sortie propre au paiement, un enregistrement du montant et de la condition pour le dépenser ensuite. Le contact public ne réapparaît donc pas comme la même adresse de réception dans la chaîne. [1] [3] [9] [7]

Une adresse Silent Payments contient une scan key publique et une spend key publique. Une clé privée est une valeur numérique secrète ; la clé publique correspondante peut être partagée. Les noms indiquent leurs rôles : la scan key concerne la recherche des paiements, la spend key leur dépense. Les clés privées correspondantes restent chez Bob. Sur mainnet, le réseau principal de Bitcoin, elle commence par sp1 et utilise Bech32m. Ce n’est ni une adresse Taproot ordinaire commençant par bc1p ni une sauvegarde du portefeuille. Cette paire publique permet à l’expéditeur compatible de calculer la destination, mais ne lui donne ni droit de dépense ni liste des encaissements de Bob. [1] [5] [9]

Pour payer Bob, le portefeuille d’Alice sélectionne des montants reçus auparavant. Les références à ces montants forment les entrées de la nouvelle transaction. Le calcul de la destination utilise les clés des entrées qui respectent les règles de BIP352 ; tous les types d’entrées ne conviennent pas. Alice combine leurs clés privées avec la scan key publique de Bob à l’aide d’ECDH. Cette méthode cryptographique permet aux deux parties de calculer indépendamment le même secret sans échanger leurs clés privées. À partir de ce secret et de son lien avec les entrées précises, le portefeuille ajuste la spend key publique de Bob et obtient la clé de la nouvelle sortie. Le lien avec les entrées empêche de répéter la destination lorsqu’une clé d’entrée est réutilisée. Si Alice utilise RBF, c’est-à-dire remplace une transaction non confirmée, par exemple pour augmenter ses frais, et modifie les entrées, le portefeuille doit recalculer la destination. Il ne peut pas simplement reprendre l’ancien résultat. [1] [4]

Le portefeuille de Bob examine les transactions admissibles et calcule les sorties possibles à l’aide de sa scan key privée et des données publiques des entrées. Lorsqu’il trouve une correspondance, il inscrit la sortie parmi ses fonds. Dans la chaîne, c’est une sortie Taproot sans notification spéciale. Bob n’a pas besoin d’être connecté lors de l’envoi ni de répondre auparavant à Alice, mais son portefeuille devra traiter ensuite les données nécessaires. [1] [6]

La scan key repère les paiements ; la spend key permet de les dépenser avec les données dérivées. La spend key privée peut rester séparée du scanner connecté. La fuite de la seule scan key privée ne permet pas de voler, mais peut révéler les encaissements avec les données publiques. La confier à un serveur de scan tiers a donc des conséquences sur la confidentialité. Ni la seed ni la spend key privée ne sont transmises à ce serveur. [1]

Silent Payments ne demande pas de transaction de notification particulière, mais calculs et transferts de données ne sont pas gratuits. Le destinataire examine les transactions admissibles et effectue les calculs cryptographiques décrits. Sur téléphone, l’indexation, la source des données et le temps depuis le dernier scan comptent. Une simple liste d’adresses ne suffit pas. Un nœud est un logiciel qui vérifie les transactions et les blocs et communique avec les autres participants du réseau. Un nœud personnel et un fournisseur externe ont des exigences et des effets différents sur confidentialité et disponibilité. [1] [2] [8]

Bob peut utiliser des labels, des variantes de paiement dérivées, par exemple pour différents projets. Il n’a pas à effectuer un scan entièrement indépendant pour chacune. Les variantes publiques partagent cependant la scan key : un observateur peut donc reconnaître leur propriétaire commun. Un label aide Bob à classer un encaissement, sans créer une identité anonyme distincte. Le label spécial de monnaie rendue désigne le reste d’un paiement effectué par Bob lui-même. S’il dépense un montant reçu auparavant qui dépasse le paiement et ses frais, le reste revient dans son portefeuille. Il ne s’agit pas d’un remboursement par un commerçant. BIP352 réserve le label m = 0 à cet usage. Le portefeuille le recherche toujours lors de la récupération et ne doit pas le publier comme contact pour les paiements d’autres personnes. [1] [4]

Imaginons que Bob perde son téléphone, mais conserve sa sauvegarde. La seed est la valeur secrète de départ dont le portefeuille dérive les clés ; l’utilisateur la sauvegarde généralement au moyen d’une Seed Phrase, des mots de récupération dans un ordre précis. Ces mots ne suffisent pas à rendre n’importe quelle application capable de retrouver les Silent Payments. Elle doit prendre en charge la même dérivation des clés et savoir repérer ces paiements. Sauvegarder les labels utilisés et la date de début d’utilisation du portefeuille facilite la récupération. Pour retrouver les fonds actuels, le portefeuille peut examiner les données nécessaires des transactions contenant des UTXO restants : des montants reçus individuellement et pas encore dépensés. Retrouver l’historique complet exige un parcours plus large de la chaîne. Un affichage vide avant la fin du scan ne signifie donc pas forcément que l’argent est perdu. [1]

Silent Payments limite les liens dus à la réutilisation d’adresse, mais ne cache ni montants, ni date de confirmation, ni historique des entrées dépensées. Alice connaît son propre paiement à Bob et une commande peut contenir des informations personnelles. Si Bob regroupe ensuite plusieurs UTXO, il peut révéler leur relation. Silent Payments n’est pas CoinJoin et leur combinaison n’est pas automatiquement sûre : BIP352 souligne l’absence de preuve formelle pour des expéditeurs indépendants qui collaborent. [1] [3]

BIP352 cite josibake, Ruben Somsen et Sebastian Falbesoner comme auteurs ; son numéro a été attribué en 2023. Lors de la vérification du 17 octobre 2026, son statut est Complete. Cela ne signifie pas une prise en charge universelle : envoi, réception, scan et récupération doivent être vérifiés séparément. Le protocole utilise Taproot existant sans nouveau Soft Fork, c’est-à-dire un durcissement des règles de validité adopté par le réseau. Les anciennes applications non compatibles ne peuvent pas traiter correctement une adresse sp1. [1] [2]