Bitcoin Core 32.0 Multisig Vérifiez Vos Co-Signataires

Imaginez préparer une transaction Bitcoin à plusieurs mains, tout se passe bien jusqu’au moment où le fichier refuse de s’ouvrir chez l’un de vos co-signataires. C’est précisément le signal d’alarme lancé mi-octobre 2026 autour de la future version 32.0 de Bitcoin Core. Un simple changement de format par défaut pour les transactions partiellement signées, les fameux fichiers PSBT, pourrait transformer une mise à jour anodine en casse-tête pour ceux qui gèrent des fonds en multisignature.

Un changement de format qui change la donne pour les multisig

La version 32.0 de Bitcoin Core n’est pas encore sortie au moment où ces lignes sont écrites, mais les notes de version circulent déjà et le message est clair. Par défaut, le logiciel basculera du format PSBT version 0 vers la version 2. Pour la plupart des utilisateurs solo, cela restera transparent. Pour les configurations multisig, où plusieurs portefeuilles doivent signer la même transaction, le risque d’incompatibilité devient réel.

Le 14 octobre, un utilisateur a rapporté sur les canaux du projet que des fichiers générés par le nouveau portefeuille graphique ne s’importaient plus correctement dans des co-signataires restés sur des versions antérieures. Les développeurs ont pris note et reporté le correctif vers la version 32.1. Ce signalement isolé ne prouve pas encore un bug généralisé, mais il suffit à rappeler une règle d’or : dans le multisig, l’ordre des mises à jour compte autant que la sécurité des clés.

Pourquoi le format PSBT est-il si sensible

Les fichiers PSBT, pour Partially Signed Bitcoin Transactions, permettent de construire une transaction étape par étape. Chaque co-signataire ajoute sa signature sans jamais exposer sa clé privée. C’est l’outil standard des setups multisig, des coffres d’entreprise aux solutions de garde collaborative. Quand le format évolue, la compatibilité entre logiciels devient critique.

Un précédent correctif PSBT, déjà documenté, avait montré qu’une faille dans ce format pouvait rediriger des fonds sans vol de clé. L’épisode avait rappelé à toute la communauté que le diable se cache souvent dans les détails d’interopérabilité. Avec le passage à la version 2 par défaut, Bitcoin Core modernise son approche, mais impose une vigilance accrue aux utilisateurs qui ne contrôlent pas tous les logiciels de la chaîne de signature.

Les notes de version précisent que ceux qui pilotent Bitcoin Core via les appels RPC peuvent explicitement demander l’ancien format. Cette option offre une porte de sortie temporaire, mais elle suppose une maîtrise technique que tous les utilisateurs multisig n’ont pas. Pour les autres, la solution la plus sûre reste de synchroniser les versions avant toute migration.

Un correctif reporté et une sortie encore floue

Au 24 octobre 2026, la page de cycle de vie du projet indiquait toujours une date de sortie indéterminée pour Bitcoin Core 32.0. Seules des versions candidates étaient disponibles au téléchargement. Les développeurs ont choisi de reporter le correctif lié aux fichiers PSBT vers 32.1, ce qui signifie que la première version publique de la ligne 32.x pourrait encore comporter cette friction pour certains setups.

Ce report s’inscrit dans un contexte plus large de durcissement de la politique de sécurité. Le 22 octobre, un amendement a été intégré pour permettre un rétroportage plus rapide des correctifs concernant les vulnérabilités faciles à redécouvrir, y compris par de grands modèles de langage. Antoine Poinsot, développeur actif, a souligné sur la liste de diffusion bitcoindev que la période d’embargo traditionnelle retardait inutilement la disponibilité des versions corrigées.

La période d’embargo ne sert à presque rien mais elle retarde la disponibilité d’une version corrigée.

Antoine Poinsot, développeur Bitcoin Core

Cette évolution de la politique de divulgation montre une prise de conscience face aux nouvelles capacités d’analyse automatisée. Elle n’efface pas pour autant le besoin de prudence côté utilisateurs. Une fois la 32.0 sortie, la ligne 29.x sortira de la fenêtre de maintenance. Seules les branches 30.x, 31.x et 32.x continueront de recevoir des correctifs. Les détenteurs de multisig sur d’anciennes versions devront donc planifier leur migration avec soin.

Trois failles attendues après la sortie

Les notes de version de Bitcoin Core 32.0 annoncent également la divulgation, deux semaines après la publication, de trois vulnérabilités de sévérité moyenne ou élevée déjà corrigées dans la version 30.0. Cette pratique de divulgation retardée reste courante pour laisser le temps aux utilisateurs de se mettre à jour. Elle souligne néanmoins l’importance de ne pas rester trop longtemps sur des versions anciennes.

Pour les configurations multisig, le message est double. D’un côté, rester sur une version trop ancienne expose aux failles déjà patchées. De l’autre, passer trop vite à 32.0 sans vérifier les co-signataires peut créer des frictions opérationnelles. L’équilibre se trouve dans une migration coordonnée, version par version, en testant d’abord les échanges de fichiers PSBT dans un environnement de test.

Comment préparer sa configuration multisig

La première étape consiste à inventorier précisément les logiciels utilisés par chaque co-signataire. Bitcoin Core n’est pas le seul outil capable de manipuler des PSBT. Des portefeuilles matériels, des logiciels tiers ou des solutions de garde collaborative peuvent intervenir dans la chaîne. Chacun d’eux doit être compatible avec le format généré par la version 32.0.

Ensuite, il est judicieux de tester le flux complet avec de petites quantités ou sur un réseau de test. Générer un fichier PSBT avec la version candidate de 32.0, l’envoyer aux co-signataires, vérifier qu’ils peuvent le charger, y ajouter leur signature et renvoyer le fichier final. Ce test grandeur nature révèle rapidement les points de friction.

Pour ceux qui pilotent Bitcoin Core via RPC, l’option de forcer le format version 0 offre une solution de transition. Elle permet de rester compatible avec des co-signataires plus anciens le temps que l’ensemble de l’écosystème bascule. Cette solution reste toutefois temporaire. À moyen terme, la version 2 deviendra le standard et les logiciels tiers devront s’adapter.

Le contexte plus large de la version 32.0

Bitcoin Core évolue en permanence. Chaque version majeure apporte son lot d’améliorations de performance, de sécurité et de conformité aux évolutions du protocole. Le passage au format PSBT version 2 s’inscrit dans cette logique de modernisation. Il offre davantage de flexibilité et de clarté dans la construction des transactions complexes.

En parallèle, le projet renforce sa capacité à réagir rapidement aux vulnérabilités. L’amendement du 22 octobre concernant le rétroportage des correctifs faciles à redécouvrir montre une adaptation aux réalités contemporaines. Les grands modèles de langage changent la donne en matière de découverte de failles. La communauté des développeurs ajuste ses processus en conséquence.

Cette double dynamique, modernisation des formats et accélération des correctifs de sécurité, place les utilisateurs face à une responsabilité accrue. Rester à jour est plus important que jamais, mais le faire de manière coordonnée dans un setup multisig demande de l’anticipation. Les équipes qui gèrent des fonds importants ont tout intérêt à documenter leurs procédures de mise à jour et à les tester régulièrement.

Les leçons d’un précédent correctif PSBT

Il y a quelque temps, Bitcoin Core avait déjà dû corriger un défaut lié au format PSBT. Dans certains cas, ce bug pouvait conduire à une redirection de fonds sans que les clés privées aient été compromises. L’incident avait souligné à quel point les détails d’implémentation du format sont critiques. Un fichier mal interprété peut avoir des conséquences financières directes.

Ce précédent explique en partie la prudence actuelle. Même si le signalement du 14 octobre ne décrit pour l’instant qu’un problème d’import et non une faille de sécurité, il rappelle que l’interopérabilité n’est jamais acquise. Chaque changement de format doit être validé sur l’ensemble de la chaîne de signature avant d’être déployé en production.

Les utilisateurs multisig les plus expérimentés ont déjà intégré cette logique. Ils maintiennent des environnements de test, documentent les versions de chaque composant et planifient les migrations comme des opérations critiques. Pour les autres, l’arrivée de Bitcoin Core 32.0 constitue une bonne occasion de professionnaliser leurs pratiques.

Que faire concrètement dès maintenant

La première action consiste à suivre de près les annonces officielles. La date de sortie de la 32.0 reste indéterminée, mais les versions candidates permettent déjà de tester. Télécharger une candidate, l’installer dans un environnement isolé et vérifier le comportement des fichiers PSBT avec ses co-signataires actuels est la démarche la plus prudente.

Ensuite, ouvrir le dialogue avec les autres signataires. Si l’un d’eux utilise un logiciel qui n’a pas encore annoncé de support pour le format version 2, il faudra soit attendre, soit forcer le format ancien via RPC, soit envisager une migration coordonnée de tous les outils. Le pire scénario serait qu’un seul co-signataire migre et se retrouve isolé, incapable de partager des fichiers lisibles avec les autres.

Enfin, garder un œil sur la version 32.1. Si le correctif annoncé y est bien intégré, elle constituera probablement le point d’entrée recommandé pour de nombreux utilisateurs multisig. Attendre quelques semaines supplémentaires après la sortie de 32.0 peut s’avérer plus sage que de se précipiter.

L’impact sur les différents profils d’utilisateurs

Les utilisateurs individuels qui signent seuls leurs transactions ne seront quasiment pas impactés. Le changement de format par défaut restera invisible pour eux. Les entreprises et les organisations qui utilisent le multisig pour sécuriser des trésoreries devront en revanche revoir leurs procédures. Les solutions de garde collaborative et les services de type multi-signature as a service devront aussi s’assurer de la compatibilité de leur stack.

Les développeurs d’outils tiers qui génèrent ou consomment des fichiers PSBT ont un travail de mise à jour à réaliser. La plupart le feront rapidement, mais le délai de transition peut créer des zones d’ombre. Pendant cette période, la communication entre les équipes techniques de chaque co-signataire devient essentielle.

Les utilisateurs de portefeuilles matériels doivent vérifier auprès de leur fabricant le niveau de support du format version 2. Certains appareils s’appuient sur Bitcoin Core ou sur des bibliothèques tierces pour la construction des transactions. Une incompatibilité temporaire n’est pas à exclure.

Une occasion de revoir sa posture de sécurité

Au-delà du simple problème de format, l’épisode Bitcoin Core 32.0 invite à une réflexion plus large. Dans un setup multisig, la sécurité ne repose pas uniquement sur les clés privées. Elle dépend aussi de la capacité de chaque participant à communiquer de manière fiable et à interpréter correctement les fichiers échangés. Un format qui évolue sans coordination peut créer des points de rupture opérationnels.

C’est pourquoi les meilleures pratiques recommandent de documenter précisément la stack logicielle de chaque co-signataire, de planifier les mises à jour en commun et de disposer d’un canal de communication dédié pour les incidents techniques. Ces habitudes, une fois prises, réduisent considérablement le risque de se retrouver bloqué face à un fichier illisible.

La modernisation du format PSBT reste positive à long terme. Elle apporte plus de clarté et de possibilités. Le chemin pour y parvenir demande simplement de la méthode. Ceux qui anticipent aujourd’hui éviteront les mauvaises surprises demain.

Suivre l’évolution jusqu’à la sortie officielle

Tant que la date de sortie de Bitcoin Core 32.0 n’est pas fixée, la situation reste fluide. Les versions candidates évoluent, les retours utilisateurs s’accumulent et les développeurs ajustent le code. Le signalement du 14 octobre a déjà conduit à un report de correctif. D’autres ajustements restent possibles d’ici la publication finale.

Les canaux officiels du projet, la liste de diffusion et les notes de version candidates constituent les sources les plus fiables. Les articles de synthèse comme celui-ci permettent de prendre de la hauteur, mais ne remplacent pas la lecture des changelogs techniques pour ceux qui gèrent des fonds importants.

Une fois la version 32.0 publiée, le compte à rebours de deux semaines avant la divulgation des trois vulnérabilités corrigées dans la 30.0 commencera. Ce sera le moment de vérifier que l’ensemble de sa configuration est bien à jour, non seulement pour le format PSBT, mais aussi pour les correctifs de sécurité.

En résumé, une vigilance de mise

Bitcoin Core 32.0 modernise le format par défaut des transactions partiellement signées. Ce changement, annonce progressive et option de fallback via RPC, reste globalement bien maîtrisé. Le signalement isolé d’un problème d’import entre le nouveau portefeuille graphique et des co-signataires plus anciens a toutefois rappelé que le multisig exige une coordination particulière.

Le correctif est prévu pour 32.1. La date de sortie de 32.0 reste indéterminée au moment de la rédaction. Trois vulnérabilités de sévérité moyenne ou élevée seront divulguées deux semaines après la publication. La ligne 29.x sortira de maintenance.

Pour les détenteurs de fonds en multisignature, la recommandation est simple : vérifier la version de chaque co-signataire avant de migrer l’un d’eux, tester le flux PSBT en conditions réelles et, si besoin, forcer temporairement l’ancien format. Cette discipline opérationnelle transforme un potentiel point de friction en simple étape de maintenance.

Dans l’univers Bitcoin, la sécurité ne se limite jamais à la protection des clés. Elle inclut aussi la capacité à faire évoluer l’ensemble de son infrastructure de manière cohérente. Bitcoin Core 32.0 en offre une nouvelle illustration. Ceux qui anticipent resteront sereins. Les autres risquent de découvrir trop tard qu’un fichier pourtant correctement signé refuse simplement de s’ouvrir.

Le temps qui reste avant la sortie officielle doit être mis à profit. Inventaire des logiciels, tests de compatibilité, discussion avec les co-signataires, préparation d’un plan B. Ces gestes, simples en apparence, font toute la différence entre une mise à jour fluide et une situation de blocage. Dans le multisig, la coordination n’est pas un luxe. C’est une condition de fonctionnement.

Les prochaines semaines diront si d’autres retours utilisateurs confirment ou relativisent le signalement du 14 octobre. En attendant, la prudence reste de mise. Vérifier avant de migrer. Tester avant de signer. Communiquer avant d’agir. Ces trois réflexes suffisent souvent à éviter les mauvaises surprises liées aux évolutions de format.

Bitcoin Core continue d’évoluer pour offrir plus de robustesse et de modernité. Les utilisateurs multisig, en restant attentifs aux détails d’interopérabilité, tirent le meilleur parti de ces avancées sans en subir les éventuels effets de bord. C’est le prix de la sécurité partagée, et il reste largement acceptable dès lors que l’on s’y prépare.