confidentialité, Silent Payments et sécurité de l’infrastructure Bitcoin
La newsletter Bitcoin Optech #422 met cette semaine en lumière trois sujets qui illustrent assez bien la direction prise par une partie du développement Bitcoin : améliorer la confidentialité, rendre les nouveaux usages réellement accessibles sur mobile et renforcer la sécurité des infrastructures existantes.
Au programme : un protocole expérimental appelé Babilonia, de nouveaux travaux autour des Silent Payments pour les clients légers, une mise à jour de sécurité importante pour BTCPay Server, ainsi que plusieurs améliorations de robustesse dans Bitcoin Core.
Bitcoin Optech #422 en vidéo
Dans cette vidéo, je reviens sur les principaux éléments de la newsletter et surtout sur ce qu’ils peuvent changer concrètement pour les utilisateurs de Bitcoin.
Babilonia : rendre la recherche de confidentialité moins visible
Quand on regarde la blockchain Bitcoin, on ne connaît pas directement l’identité des personnes derrière les transactions.
Cela ne signifie pourtant pas que toutes les transactions sont anonymes.
Les entreprises spécialisées dans l’analyse de blockchain utilisent notamment des heuristiques, c’est-à-dire des règles permettant de formuler des hypothèses à partir de la structure des transactions.
L’une des plus connues est l’heuristique de propriété commune des entrées.
Son principe est assez simple : lorsqu’une transaction dépense plusieurs UTXO en même temps, on peut supposer que ces différentes entrées appartiennent à une même personne ou entité.
Mais il s’agit bien d’une supposition, pas d’une preuve.
C’est précisément ce genre d’heuristique que des techniques comme CoinJoin cherchent à rendre moins fiable.
CoinJoin améliore la confidentialité… mais peut aussi être identifiable
Dans un CoinJoin, plusieurs utilisateurs construisent ensemble une transaction.
L’objectif est de rendre plus difficile l’association entre les bitcoins qui entrent dans la transaction et ceux qui en ressortent.
Cela peut fortement compliquer certaines analyses.
Mais un autre problème apparaît : certaines transactions CoinJoin possèdent elles-mêmes une structure particulière qui peut permettre de les reconnaître comme telles.
Autrement dit, on ne sait peut-être plus exactement qui a payé qui, mais on peut parfois identifier qu’un outil destiné à améliorer la confidentialité a été utilisé.
C’est ici qu’intervient Babilonia.
Adam Gibson a présenté sur Delving Bitcoin une proposition de protocole combinant CoinJoin probabiliste et mécanisme de pari dissimulé. L’objectif est notamment de casser l’heuristique de propriété commune tout en produisant une transaction qui, vue depuis la blockchain, peut davantage ressembler à un paiement classique.
Un pari comme mécanisme de confidentialité
Le principe général de Babilonia consiste à faire participer deux utilisateurs à une sorte de pari cryptographique.
Les fonds sont regroupés, puis le résultat du pari détermine la manière dont ils sont redistribués.
Vu de l’extérieur, le transfert qui en résulte peut alors ressembler à un paiement normal plutôt qu’à une opération explicitement destinée à brouiller les pistes.
L’intérêt est intéressant conceptuellement : ne plus seulement chercher à cacher le lien entre différentes pièces, mais également éviter que la recherche de confidentialité elle-même soit trop facilement identifiable.
Le protocole utilise notamment des transactions préparées à l’avance et des signatures adaptatrices pour permettre aux participants de régler le résultat sans avoir besoin de faire confiance à l’autre partie.
Une proposition encore expérimentale
Il ne faut cependant pas présenter Babilonia comme une solution déjà prête à être utilisée.
Adam Gibson indique lui-même qu’il n’existe pas encore de mesure claire permettant d’évaluer l’efficacité réelle du système en matière de confidentialité.
Un premier mécanisme révélait également certaines informations sur la taille du pari. Une deuxième version propose donc de découper celui-ci en plusieurs sous-paris de montants différents afin de réduire cette fuite d’information.
Babilonia reste donc avant tout un travail de recherche intéressant sur la manière de concevoir des transactions plus difficiles à classifier.
Silent Payments : le défi du portefeuille mobile
Autre sujet majeur de cette newsletter : les Silent Payments.
L’idée des Silent Payments est particulièrement séduisante : permettre à quelqu’un de publier une adresse Bitcoin réutilisable tout en évitant que tous les paiements reçus apparaissent sur la blockchain sous la même adresse.
Chaque paiement peut ainsi aboutir vers une sortie différente.
C’est pratique, notamment pour afficher un identifiant de paiement publiquement sans devoir générer et transmettre une nouvelle adresse à chaque transaction.
Mais cette approche crée une difficulté importante.
Comment savoir qu’un paiement nous appartient ?
Avec une adresse Bitcoin classique, un portefeuille peut facilement rechercher les transactions associées à certaines adresses.
Avec les Silent Payments, le portefeuille doit effectuer davantage de calculs pour déterminer quelles transactions lui sont destinées.
Ce n’est pas forcément un problème pour un nœud complet disposant de toute la blockchain.
C’est beaucoup plus compliqué pour un client léger, par exemple un portefeuille installé sur un smartphone.
Un téléphone ne va évidemment pas télécharger plusieurs centaines de gigaoctets de blockchain uniquement pour vérifier si quelques paiements lui sont destinés.
Il faut donc lui fournir uniquement les informations réellement nécessaires.
BlindBit Oracle : transmettre les données utiles au portefeuille
Rob Segers a publié de nouveaux résultats autour de BlindBit Oracle v2, un serveur d’indexation conçu notamment pour faciliter la détection des Silent Payments par les clients légers.
Cette approche abandonne l’utilisation classique de certains filtres et transmet directement au portefeuille une série de données permettant de rechercher les paiements potentiellement concernés.
Les tests ont été réalisés sur plus de 255 000 blocs, depuis l’activation de Taproot jusqu’au bloc 965 089.
Le résultat montre que BlindBit Oracle nécessite environ 2,1 fois plus de données téléchargées qu’une approche utilisant des filtres dédiés à Taproot accompagnés des données nécessaires au calcul.
Mais cette comparaison ne raconte pas toute l’histoire.
Avec les filtres, lorsqu’une correspondance potentielle apparaît, le client peut ensuite devoir récupérer le bloc complet.
BlindBit évite ce téléchargement et élimine également les faux positifs de cette phase de filtrage.
Nous retrouvons donc un compromis classique dans les logiciels Bitcoin :
moins de bande passante, plus de calcul, plus de dépendance à un serveur, ou davantage de données téléchargées ?
Il n’existe pas nécessairement une solution parfaite pour tous les usages.
Le problème de la confiance envers le serveur
Il reste également une question importante.
Comment un portefeuille peut-il savoir que le serveur lui transmet réellement toutes les informations nécessaires ?
Si le serveur omet volontairement ou accidentellement certaines données, le portefeuille pourrait ne pas détecter un paiement qui lui est pourtant destiné.
BlindBit Oracle expérimente donc un système d’engagements cryptographiques permettant d’identifier après coup certaines omissions.
Le serveur publie notamment régulièrement des points de contrôle via Nostr.
Cela ne supprime pas complètement la question de la confiance, mais permet de rendre certaines manipulations détectables.
C’est probablement l’un des enjeux majeurs si les Silent Payments doivent un jour devenir courants dans les portefeuilles mobiles : obtenir une expérience simple sans sacrifier inutilement la confidentialité ou la possibilité de vérifier ce que fait le serveur.
BTCPay Server 2.4.4 : une mise à jour de sécurité importante
La newsletter annonce également BTCPay Server 2.4.4, présenté comme une version de sécurité.
BTCPay Server est une solution libre permettant notamment à une entreprise ou à un commerçant d’accepter des paiements Bitcoin sans dépendre directement d’un prestataire de paiement custodial.
Mais auto-héberger un service implique également une responsabilité : maintenir correctement son infrastructure.
La version 2.4.4 supprime notamment l’ancien mécanisme d’authentification BitPay Basic-auth et les anciennes clés API associées.
Elle renforce également la gestion des permissions afin qu’une clé API limitée ne puisse pas créer elle-même une clé disposant de davantage de droits.
Plusieurs modifications concernent également les installations utilisant LND et Docker, avec notamment :
- une meilleure isolation de certaines fonctions d’administration ;
- des mots de passe uniques plutôt qu’un mot de passe de portefeuille partagé par défaut ;
- le blocage de certaines routes d’administration LND qui pouvaient être exposées sans authentification.
Les administrateurs de BTCPay Server sont donc encouragés à mettre à jour leur installation et à examiner les éventuelles incompatibilités avec leurs intégrations existantes.
C’est aussi un bon rappel : la souveraineté technique ne consiste pas uniquement à installer un logiciel libre sur son propre serveur. Elle implique aussi de le maintenir et de suivre ses mises à jour de sécurité.
Des clés API mieux protégées dans BTCPay
D’autres changements intégrés à BTCPay Server améliorent la manière dont les clés API sont conservées.
Le serveur stocke désormais des empreintes cryptographiques et des identifiants dérivés plutôt que de conserver indéfiniment certains secrets en clair.
Les nouveaux secrets créés sont également supprimés du stockage après quelques minutes.
Autre détail intéressant : les nouvelles clés ne sont plus placées directement dans l’URL de redirection vers la page d’administration.
Cela évite qu’un secret puisse se retrouver accidentellement dans l’historique du navigateur ou dans des journaux de serveurs web.
Ce sont des changements discrets pour l’utilisateur final, mais importants pour une infrastructure manipulant potentiellement des paiements réels.
Bitcoin Core : plusieurs améliorations de robustesse
Bitcoin Core reçoit également plusieurs corrections.
Parmi elles, une vulnérabilité liée à l’option walletnotify a été corrigée.
Dans certaines configurations particulières, un utilisateur disposant déjà d’un accès RPC authentifié pouvait créer un portefeuille avec un nom spécialement conçu afin de provoquer ensuite l’exécution de commandes sur le système hébergeant le nœud.
Bitcoin Core corrige désormais correctement ce traitement.
Une autre amélioration concerne le nouveau serveur HTTP.
Avant la correction, un client pouvait envoyer des requêtes suffisamment rapidement pour faire grossir continuellement le tampon mémoire du serveur.
Lors d’un test cité dans Bitcoin Optech, 16 connexions REST ont entraîné une consommation supplémentaire de 3,2 Go de mémoire en 90 secondes avant la correction, contre environ 3 Mo après celle-ci.
Le serveur applique désormais un mécanisme de contre-pression : lorsque trop de requêtes attendent déjà d’être traitées, il arrête temporairement de lire les nouvelles données, laissant TCP ralentir naturellement l’expéditeur.
Encore une fois, ce type d’amélioration est pratiquement invisible pour l’utilisateur final.
Mais c’est justement une grande partie du développement quotidien de Bitcoin : corriger des cas limites, éliminer des vulnérabilités et rendre progressivement les logiciels plus robustes.
Lightning continue également d’évoluer
Du côté de Lightning, LDK 0.2.6 corrige notamment deux vulnérabilités, dont un risque de déni de service et un problème permettant à une contrepartie malveillante de provoquer une mauvaise allocation des frais lors de certains splices.
LND poursuit de son côté le développement des offres BOLT12, notamment avec l’ajout de la signature et de la vérification cryptographique de certains messages utilisés lors de la création des factures.
Ces évolutions sont plus techniques, mais elles participent au même mouvement : rendre Lightning progressivement plus robuste et améliorer les outils nécessaires à des usages plus avancés.
Ce qu’il faut retenir de Bitcoin Optech #422
Cette édition ne présente pas une fonctionnalité spectaculaire qui changerait Bitcoin du jour au lendemain.
Elle montre quelque chose de probablement plus représentatif de la manière dont Bitcoin progresse réellement.
Sur la confidentialité, Babilonia explore comment rendre les transactions destinées à brouiller l’analyse moins facilement identifiables.
Sur l’expérience utilisateur, les travaux autour des Silent Payments cherchent à rendre une technologie intéressante compatible avec les contraintes très concrètes d’un téléphone mobile.
Sur l’infrastructure, BTCPay Server, Bitcoin Core et les logiciels Lightning continuent de supprimer des vulnérabilités et d’améliorer leur robustesse.
Le développement de Bitcoin est souvent constitué de ce type de progrès : moins visibles qu’une nouvelle application ou qu’un mouvement de prix, mais essentiels pour construire progressivement une infrastructure plus résistante, plus privée et plus utilisable.
Pour aller plus loin
La newsletter originale Bitcoin Optech #422, publiée le 11 septembre 2026, contient l’ensemble des détails techniques, liens vers les discussions des développeurs, pull requests et benchmarks évoqués dans cet article.
Bitcoin Optech publie chaque semaine une synthèse des principaux développements techniques autour de Bitcoin et Lightning.
Chez B-Conseil, je reprends régulièrement ces évolutions pour les expliquer dans un langage accessible et montrer leurs conséquences concrètes pour les utilisateurs, les professionnels et les entreprises qui souhaitent comprendre ou utiliser Bitcoin.
Vous souhaitez comprendre Bitcoin au-delà du prix et identifier ce qu’il peut réellement apporter à votre activité ? B-Conseil vous accompagne avec des formations et un accompagnement adaptés à votre niveau et à vos usages.