Confidentialité, sécurité Lightning, post-quantique et covenants
La newsletter Bitcoin Optech du 4 septembre 2026 met en avant quatre sujets qui donnent une bonne idée des grands chantiers techniques autour de Bitcoin aujourd’hui.
Certains concernent des améliorations très concrètes, comme la confidentialité des paiements ou la sécurité du réseau Lightning. D’autres préparent des évolutions plus profondes, comme la résistance aux ordinateurs quantiques ou de nouvelles possibilités pour programmer les conditions de dépense des bitcoins.
d’abord en vidéo :
Voici les quatre sujets principaux à retenir.
Des Silent Payments jusque dans les paiements des pools de minage
Les Silent Payments, définis par le BIP352, permettent de publier une adresse Bitcoin statique tout en générant automatiquement une adresse différente pour chaque paiement reçu.
L’intérêt principal est la confidentialité : contrairement à une adresse Bitcoin classique réutilisée plusieurs fois, un observateur ne peut pas simplement regarder la blockchain et regrouper tous les paiements reçus par une même personne.
Une nouvelle proposition cherche maintenant à utiliser cette technique pour les pools de minage.
Un pool de minage est un service qui regroupe la puissance de calcul de nombreux mineurs afin d’augmenter leurs chances de trouver un bloc. Lorsqu’un bloc est trouvé, le pool répartit ensuite les gains entre les participants.
Aujourd’hui, un mineur peut notamment fournir au pool une clé publique étendue, appelée xpub, permettant de générer régulièrement de nouvelles adresses de paiement.
Cela fonctionne, mais crée aussi une information sensible : si la base de données du pool est compromise, il devient potentiellement possible de relier entre eux les différents paiements reçus par un même mineur.
L’alternative proposée consiste à fournir une adresse Silent Payment statique. Le pool pourrait alors générer une adresse différente à chaque paiement sans avoir besoin de conserver une liste d’adresses appartenant au mineur.
La proposition prévoit que cela fonctionne directement dans la transaction coinbase, c’est-à-dire la transaction spéciale créée par le mineur lorsqu’un nouveau bloc est trouvé. C’est elle qui distribue notamment la récompense de minage et les frais de transaction.
Comme cette transaction particulière ne fonctionne pas exactement comme une transaction Bitcoin classique, il faut adapter le mécanisme des Silent Payments. Le pool utiliserait pour cela une clé temporaire propre à chaque bloc.
L’idée est encore au stade de discussion, mais elle montre une évolution intéressante : les Silent Payments pourraient devenir un outil de confidentialité utilisable bien au-delà d’un simple portefeuille Bitcoin.
Core Lightning : une attaque par déni de service corrigée
Le deuxième sujet concerne Core Lightning, l’une des principales implémentations du réseau de paiement rapide Lightning.
Lightning permet d’effectuer des paiements Bitcoin presque instantanés et avec très peu de frais, sans enregistrer chaque paiement directement dans la blockchain.
Une vulnérabilité importante a récemment été corrigée dans Core Lightning.
Elle permettait de réaliser une attaque par déni de service, ou DoS (Denial of Service). Ce type d’attaque consiste à saturer un service avec trop de demandes afin de le ralentir ou de le faire tomber complètement.
Dans le cas de Core Lightning, l’attaquant pouvait établir une connexion normale avec un nœud Lightning et lui envoyer continuellement des demandes auxquelles le nœud devait répondre avec de gros volumes de données.
L’attaquant n’avait ensuite qu’à ne pas récupérer les réponses.
Celles-ci s’accumulaient progressivement dans la mémoire du nœud jusqu’à pouvoir provoquer son crash.
Autrement dit, un attaquant n’avait même pas besoin de posséder un canal Lightning ou d’engager des fonds : une simple connexion réseau pouvait suffire.
Le problème concernait un composant appelé connectd.
Dans ce contexte, un daemon est simplement un programme qui fonctionne en permanence en arrière-plan. connectd est le daemon de Core Lightning chargé notamment de gérer les connexions avec les autres nœuds.
Le correctif ajoute un mécanisme de régulation souvent appelé backpressure.
Derrière ce terme un peu technique, le principe est très simple : lorsqu’un programme n’arrive plus à traiter ou envoyer suffisamment rapidement les données qu’il reçoit, il doit ralentir l’arrivée de nouvelles données au lieu de continuer à remplir sa mémoire.
Core Lightning attend désormais que les réponses déjà en attente aient été envoyées avant de continuer à accepter de nouvelles demandes.
La version Core Lightning 26.06.7 contient cette correction ainsi que plusieurs autres correctifs de sécurité. La mise à jour est donc fortement recommandée.
Un point particulier concerne les utilisateurs de Docker : certaines images téléchargées entre le 28 août et le 1er septembre pouvaient afficher le numéro de la version corrigée sans intégrer réellement tous les correctifs. Les utilisateurs concernés doivent donc vérifier ou télécharger à nouveau l’image.
Cette vulnérabilité rappelle un point important : la sécurité de Bitcoin ne concerne pas seulement la cryptographie ou la blockchain.
Lightning est aussi un réseau informatique accessible par Internet. Comme n’importe quel autre service réseau, il doit donc résister aux tentatives de saturation ou aux comportements malveillants.
Le chantier post-quantique devient concret
Le risque que représentent les futurs ordinateurs quantiques revient régulièrement dans les discussions autour de Bitcoin.
Le principe est le suivant : si des ordinateurs quantiques suffisamment puissants apparaissaient un jour, certaines techniques cryptographiques utilisées aujourd’hui pour protéger les bitcoins pourraient devenir vulnérables.
Nous sommes encore loin d’une attaque pratique contre Bitcoin, mais les développeurs réfléchissent déjà aux solutions permettant d’anticiper ce scénario.
Et cette semaine, Bitcoin Optech montre que ces réflexions deviennent progressivement plus concrètes.
Préparer de nouveaux types d’adresses
Pieter Wuille, l’un des principaux contributeurs historiques de Bitcoin, poursuit notamment ses travaux sur de futurs types d’adresses compatibles avec des signatures résistantes aux ordinateurs quantiques.
L’un des candidats est appelé P2TRv2.
Mais le principal problème n’est pas uniquement de concevoir une nouvelle technologie.
Il faudra aussi réussir à convaincre les utilisateurs de déplacer leurs bitcoins vers ces nouvelles protections.
Et cette migration dépendra fortement de la disponibilité de ces fonctions dans les portefeuilles, les plateformes d’échange et les services de conservation.
Autrement dit, même une bonne solution cryptographique ne sert pas à grand-chose si personne ne peut facilement l’utiliser.
DropKick : une solution de secours
Une autre proposition, appelée DropKick, cherche à créer une sorte de filet de sécurité.
L’objectif serait d’aider certains utilisateurs qui n’auraient pas migré leurs bitcoins vers une protection post-quantique avant l’apparition d’un ordinateur quantique suffisamment puissant.
Le principe est de permettre à un utilisateur de publier à l’avance une preuve indiquant qu’il contrôle une future clé résistante aux ordinateurs quantiques.
Si la menace devenait réelle, cette preuve pourrait ensuite servir à démontrer qu’il était bien le propriétaire légitime des bitcoins avant que quelqu’un tente de voler les fonds avec un ordinateur quantique.
La technique repose sur des mécanismes cryptographiques complexes, mais l’idée générale est assez simple :
préparer aujourd’hui une preuve de propriété qui pourrait être utilisée demain en cas d’urgence.
Cette solution ne pourrait toutefois pas protéger tous les anciens bitcoins.
Certaines très anciennes formes de transactions exposent déjà directement la clé publique et seraient donc beaucoup plus difficiles à protéger.
SHRINCS : des signatures résistantes, mais beaucoup plus lourdes
Un autre projet, appelé SHRINCS, explore une famille de signatures conçues pour rester sûres face aux ordinateurs quantiques.
Le principal problème est leur taille. Une signature Bitcoin actuelle est relativement petite.
Avec certaines variantes de SHRINCS, une signature pourrait atteindre plusieurs milliers d’octets.
Une version étudiée actuellement atteint par exemple environ 5 777 octets.
Cela représente un coût très important pour la blockchain, puisqu’une transaction plus grosse prend davantage de place dans les blocs et coûte donc plus cher en frais.
Antoine Riard estime qu’une telle signature pourrait coûter environ 90 fois plus cher qu’une signature Bitcoin actuelle si aucun mécanisme spécifique n’était mis en place.
C’est probablement l’un des grands défis de la transition post-quantique :
il ne suffit pas de trouver une signature résistante aux ordinateurs quantiques. Il faut aussi qu’elle reste compatible avec les contraintes de Bitcoin en matière de coût, de taille et de décentralisation.
Covenants : mieux contrôler la manière dont des bitcoins pourront être dépensés
Le quatrième sujet concerne les covenants. Le terme est technique, mais le principe peut être résumé simplement.
Aujourd’hui, une transaction Bitcoin permet surtout de définir qui a le droit de dépenser des bitcoins.
Un covenant permettrait également d’ajouter des règles indiquant comment ces bitcoins pourront être dépensés ensuite.
Par exemple, il serait possible d’imposer qu’une transaction future respecte certaines conditions précises.
Cela pourrait servir à construire des systèmes de sécurité plus avancés, des coffres-forts Bitcoin ou certains protocoles fonctionnant au-dessus de Bitcoin.
Plusieurs propositions sont actuellement étudiées.
Le BIP448 regroupe notamment plusieurs nouvelles instructions qui pourraient être ajoutées au langage de programmation très limité utilisé par Bitcoin. Parmi elles :
OP_TEMPLATEHASH;OP_CHECKSIGFROMSTACK, souvent abrégé CSFS ;OP_INTERNALKEY.
Ces noms sont surtout intéressants pour les développeurs. Pour le grand public, ce qu’il faut retenir est que ces outils permettraient de créer des conditions de dépense plus sophistiquées.
Et surtout, on commence maintenant à voir des applications concrètes.
Des démonstrations existent déjà autour de :
- LN-Symmetry, une proposition visant à simplifier certains mécanismes de Lightning ;
- Ark, un protocole permettant d’effectuer des transactions Bitcoin hors chaîne ;
- des systèmes de coffres-forts ;
- des mécanismes permettant de gérer plus efficacement de nombreuses transactions.
Un exemple intéressant concerne Ark. Un serveur Ark pourrait théoriquement essayer d’attribuer le même actif à plusieurs utilisateurs. Avec certaines des nouvelles fonctions proposées, il serait possible de créer une preuve démontrant cette fraude et de pénaliser financièrement le serveur.
C’est une bonne illustration de l’intérêt potentiel des covenants :
créer des règles qui rendent certains comportements frauduleux techniquement impossibles ou économiquement punissables.
Bitcoin évolue surtout par petites briques
Ces quatre sujets peuvent sembler très différents, mais ils montrent finalement la même chose.
Bitcoin continue d’évoluer, mais rarement sous la forme de grandes mises à jour spectaculaires. Les changements sont souvent progressifs :
Les Silent Payments pourraient améliorer la confidentialité des mineurs.
Core Lightning renforce la résistance du réseau Lightning face aux attaques.
Les travaux post-quantiques cherchent à préparer Bitcoin à une menace qui pourrait apparaître dans plusieurs années.
Et les covenants explorent de nouvelles possibilités pour construire des systèmes plus avancés au-dessus de Bitcoin.
Toutes ces propositions ne seront pas nécessairement intégrées. Certaines sont encore très expérimentales, d’autres font toujours débat. Mais elles montrent que le développement de Bitcoin ne s’est pas arrêté.
Il avance avec une contrainte particulière : chaque nouvelle fonctionnalité doit être évaluée non seulement pour ce qu’elle apporte, mais aussi pour les risques qu’elle pourrait introduire en matière de sécurité, de complexité ou de décentralisation.
Source principale : Bitcoin Optech Newsletter #421, publiée le 4 septembre 2026