Bitcoin Core Corrige Une Faille PSBT Sans Vol De Clés

Le 25 septembre 2026, un correctif a été fusionné dans la branche de développement de Bitcoin Core. Il ne répare pas une fuite de clé privée, et c’est précisément ce qui le rend déroutant. Dans un cas très étroit de transaction partiellement signée, une signature pouvait rester valable alors que le destinataire prévu n’était plus celui qui avait été montré au signataire. Autrement dit, l’argent pouvait changer de route sans que la clé soit volée. Le 2 octobre, Bitcoin Optech a signalé ce changement dans sa lettre numéro 425. Au 4 octobre, aucune version de production publiée n’embarquait encore ce garde-fou, et aucun rétroportage confirmé n’avait été identifié dans les listes de versions du projet.

Ce décalage entre le code fusionné et le logiciel réellement installé chez les utilisateurs mérite plus qu’un titre alarmiste. La faille ne concerne pas n’importe quel envoi. Elle touche un mode de signature rare, SIGHASH_SINGLE, lorsqu’aucune sortie ne correspond à l’entrée signée. La plupart des portefeuilles grand public n’exposent jamais ce réglage. Les workflows de co-signature, les appareils hors ligne et certains outils de construction de transactions, eux, peuvent s’en approcher. Comprendre la mécanique évite deux erreurs opposées : croire que toutes les pièces sont en danger, ou croire qu’un correctif sur master protège déjà chaque nœud.

Ce que le correctif change vraiment pour les signatures

Le changement porte le numéro 35984 sur le dépôt du projet. Il a été proposé par Matias Furszyfer, connu sous le pseudonyme furszy, puis fusionné sur la branche principale de développement. Son objet est simple à énoncer et plus subtil à mesurer. Bitcoin Core ne doit plus produire de signature détachée sur une entrée marquée SIGHASH_SINGLE s’il n’existe aucune sortie au même index. Le contrôle existait déjà sur le chemin de signature des transactions brutes. Il manquait sur le chemin des PSBT, y compris la commande walletprocesspsbt.

Le correctif déplace la vérification dans la logique partagée de création de signature. Les chemins actuels et les chemins futurs passent par le même point. Les entrées legacy et SegWit v0 concernées sont laissées non signées. Les autres entrées valides du même PSBT continuent d’être signées normalement. Ce détail compte pour les coffres à plusieurs signataires : un refus localisé ne doit pas bloquer tout le dossier si une autre entrée est saine.

Pourquoi une signature peut survivre à un changement de destinataire

Une transaction Bitcoin n’est pas un virement bancaire où la banque relit le nom du bénéficiaire. C’est un document que des clés autorisent selon des règles de hachage. Le type de sighash dit exactement à quoi la signature s’engage. SIGHASH_ALL couvre, en pratique courante, l’ensemble des entrées et des sorties. SIGHASH_SINGLE est plus étroit : il relie l’entrée signée à la sortie qui porte le même numéro d’index. L’entrée 0 s’engage sur la sortie 0, l’entrée 1 sur la sortie 1, et ainsi de suite.

Ce mode a une utilité historique. Il permet à plusieurs participants de construire une transaction où chacun protège sa propre ligne de paiement sans figer toutes les autres. Le piège apparaît quand la sortie attendue n’existe pas. La signature ne s’engage alors sur aucune sortie. Elle peut rester valide si l’on remplace ensuite le destinataire, tant que la structure exploitée demeure compatible. L’auteur du correctif a décrit ce comportement comme un footgun : une arme qui part dans le mauvais sens, entre les mains de celui qui croyait seulement signer.

SIGHASH_SINGLE ne s’engage que sur la sortie située au même index que l’entrée. Si cette sortie n’existe pas, la signature ne s’engage sur aucune sortie, et elle peut rester valide même si les sorties sont échangées.

Matias Furszyfer, description du correctif 35984

La phrase est technique, mais la conséquence est humaine. Un écran de portefeuille peut montrer une adresse. Le fichier transmis à l’appareil peut, dans ce cas limite, ne pas lier la signature à cette adresse. L’utilisateur a l’impression d’avoir contrôlé le bénéficiaire. En réalité, il a autorisé une autorisation trop large. Ce n’est pas un vol de seed. C’est un contrat mal borné.

Legacy et SegWit ne cassent pas de la même façon

Le risque n’est pas uniforme selon le type de pièce dépensée. Sur les entrées legacy, l’absence de sortie correspondante produit une signature sur une valeur de hachage constante, historiquement le sighash fixé à 1. Cette signature peut ensuite être réutilisée contre d’autres sorties non dépensées contrôlées par la même clé, si les mêmes conditions structurelles sont réunies. Le danger ne s’arrête donc pas à la transaction en cours. Une autorisation trop vague peut voyager.

Les entrées SegWit v0 conservent une protection plus forte sur la pièce elle-même. La signature s’engage toujours sur l’output dépensé et sur son montant. Le destinataire, en revanche, peut rester non lié. Un attaquant ne réutilise pas librement la signature sur n’importe quelle autre pièce de la même clé, mais il peut encore modifier la destination de ce paiement précis. La distinction est essentielle pour ne pas mélanger deux gravités différentes sous une seule formule choc.

Le correctif choisit la prudence pour les deux familles. Il refuse de produire la signature dangereuse plutôt que de tenter de deviner une intention. L’auteur a même noté que, s’il existait un usage légitime du cas SegWit v0, il préférerait un opt-in explicite à un comportement par défaut. Signer sans engagement sur la sortie ne doit pas être un accident de parcours.

Le chemin PSBT était le trou dans la raquette

Bitcoin Core savait déjà écarter ce cas limite lorsqu’on signait une transaction brute. Le chemin PSBT, lui, pouvait continuer. Cette asymétrie est le cœur de l’épisode. Les utilisateurs avancés et les intégrateurs ne passent pas tous par la même porte. Les portefeuilles matériels, les co-signatures et les outils hors ligne vivent dans l’univers PSBT, défini notamment par le BIP 174. C’est précisément là que le contrôle manquait.

Le BIP 174 demande déjà aux signataires de rejeter les modes de signature inacceptables. Il recommande SIGHASH_ALL par défaut. Le standard avait donc posé le principe. L’implémentation du chemin PSBT ne l’appliquait pas partout. Déplacer le test dans la création partagée de signature ferme la porte pour SignTransaction, pour SignPSBTInput et pour tout futur appelant. C’est une correction d’architecture, pas un pansement sur une seule commande.

Le nouveau test est explicite. Si le type de hachage, une fois masqué, correspond à SIGHASH_SINGLE et si l’index de l’entrée dépasse le nombre de sorties, la création de signature échoue. Les autres entrées du même dossier ne sont pas punies. Un PSBT mixte peut donc avancer sur ce qui est sain et rester incomplet sur ce qui est dangereux. C’est le comportement voulu.

Une version fusionnée n’est pas une version installée

Le point le plus concret pour un détenteur de bitcoins est calendaire. Le code est sur la branche de développement. Il n’est pas, au 4 octobre 2026, dans une version de production confirmée. Un candidat de publication peut circuler en parallèle sans que ce garde-fou y figure. Confondre une fusion sur master et un binaire publié est une erreur classique, et elle est coûteuse dès qu’on parle de signature.

Tant qu’un rétroportage n’est pas annoncé dans une version stable, les installations actuelles conservent l’ancien chemin PSBT. Cela ne signifie pas qu’un attaquant peut vider un portefeuille à distance. Cela signifie que le logiciel peut encore accepter de signer le cas limite si un PSBT mal formé, ou malveillant, lui est présenté. La surface réelle dépend du flux : qui construit la transaction, qui choisit le sighash, qui relit l’écran, qui combine les signatures.

Ce que PSBT recouvre dans la vie d’un portefeuille

Une PSBT, pour Partially Signed Bitcoin Transaction, est un dossier de travail. Elle transporte la transaction inachevée, les informations sur les pièces dépensées, les signatures déjà collectées et des métadonnées utiles aux signataires suivants. Elle a été conçue pour que des appareils qui ne se font pas confiance puissent coopérer sans se donner les clés. Un ordinateur en ligne prépare. Un appareil hors ligne signe. Un coordinateur assemble. Personne n’a besoin de voir la seed des autres.

Cette séparation est une force. Elle est aussi la raison pour laquelle un trou sur le chemin PSBT compte davantage qu’un trou sur un outil de développeur rarement lancé. Le format est devenu le langage commun des hardware wallets, des multisignatures familiales, des coffres d’entreprise et de certains flux de place de marché. Quand le dossier ment sur ce qui est engagé, l’écran du signataire devient le dernier rempart. Encore faut-il que l’écran ait de quoi afficher.

Le BIP 174 ne se contente pas de définir des champs. Il fixe une étiquette de responsabilité. Le signataire doit refuser un mode qu’il juge inacceptable. Le finaliseur ne doit pas inventer une intention absente. Le combineur ne doit pas perdre des informations nécessaires à la suite. Un autre correctif récent, sur la préservation du type de sighash lors d’une fusion d’entrées, rappelle que ces dossiers sont fragiles dès qu’un champ optionnel disparaît en silence.

Les quatre familles de sighash, sans jargon inutile

SIGHASH_ALL est le mode par défaut de la vie courante. La signature couvre les entrées et les sorties de façon large. Changer le bénéficiaire casse la signature. C’est le contrat que l’utilisateur croit signer lorsqu’il valide un envoi.

SIGHASH_NONE s’engage sur les entrées, pas sur les sorties. Il laisse à d’autres le soin de remplir les destinataires. Il est rare hors de protocoles très spécifiques, et il doit être affiché comme un choix, jamais comme un oubli.

SIGHASH_SINGLE relie une entrée à la sortie de même index. Il est utile dans certaines constructions collaboratives. Sans sortie correspondante, il ne relie plus rien. C’est le mode au centre du correctif.

ANYONECANPAY est un modificateur. Il réduit l’engagement sur les autres entrées, afin que d’autres participants puissent ajouter leurs propres fonds. Combiné à SINGLE, il devient un outil de protocole. Combiné par erreur, il élargit ce qu’un tiers peut encore modifier après coup.

Aucun de ces modes n’est une faille en soi. Le consensus Bitcoin les accepte parce que des protocoles en ont besoin. Le danger naît quand un logiciel produit une signature que l’humain n’a pas voulu dans ce périmètre. Le correctif ne supprime pas SIGHASH_SINGLE. Il refuse le cas où ce mode ne protège aucune sortie.

Un scénario concret, du fichier jusqu’à l’adresse

Imaginons un trésor familial à deux clés. L’un des signataires prépare un PSBT sur un ordinateur. Il veut payer un fournisseur. Le fichier circule vers le second appareil. Dans le cas sain, chaque entrée s’engage sur les sorties affichées. Dans le cas limite, une entrée est marquée SINGLE et la transaction n’a pas de sortie à cet index. L’appareil, s’il suit l’ancien chemin, peut produire une signature quand même.

Un tiers qui peut modifier le dossier après cette signature, ou qui a construit le dossier dès le départ, peut alors ajuster le destinataire sans invalider cette autorisation. Sur une entrée legacy, la réutilisation éventuelle contre d’autres pièces de la même clé aggrave le tableau, toujours sous les mêmes conditions structurelles. Sur une entrée SegWit v0, l’engagement sur la pièce et le montant limite la casse, sans la supprimer.

Le scénario exige un accès au flux de signature. Il ne se déclenche pas parce qu’une adresse de réception a été publiée sur un réseau social. Il ne se déclenche pas non plus parce qu’un nœud a été mis à jour en retard. Il se déclenche dans un atelier de co-signature où quelqu’un contrôle la forme du PSBT. C’est déjà beaucoup, pour une entreprise ou une succession. Ce n’est pas une épidémie de portefeuilles mobiles.

Qui est exposé, qui ne l’est presque pas

Le détenteur qui envoie depuis un portefeuille simple, avec le sighash par défaut, n’est pas la cible de ce correctif. Le risque pratique se concentre sur trois profils. D’abord, les équipes qui construisent des PSBT à la main ou via des scripts. Ensuite, les coffres multisignatures dont un coordinateur n’est pas entièrement de confiance. Enfin, les intégrateurs qui exposent le choix du sighash sans le traduire en langage clair sur l’appareil.

Les bourses qui signent en interne avec leurs propres politiques sont un cas à part. Elles ne dépendent pas du binaire grand public, mais elles dépendent parfois des mêmes primitives. Un processeur de paiements qui accepte des PSBT externes doit savoir quel mode il tolère. Un outil qui combine des signatures avant diffusion doit refuser un dossier dont une entrée ne s’engage sur aucune sortie.

Les mineurs et les nœuds validateurs ne sont pas le sujet. La règle de consensus n’a pas changé. Une signature déjà produite selon les anciennes règles reste une signature que le réseau peut accepter. Le correctif agit en amont : il empêche le logiciel de fabriquer l’autorisation douteuse. Il n’annule pas le passé.

Ce que l’écran d’un appareil devrait toujours montrer

Un hardware wallet n’est utile que s’il affiche ce qu’il engage. L’adresse, le montant et le réseau ne suffisent pas quand le mode de signature est exotique. L’appareil devrait dire, en clair, si la signature couvre toutes les sorties, une seule, ou aucune. Il devrait refuser de signer un SINGLE sans sortie jumelle, même si l’ordinateur hôte insiste. Le correctif de Bitcoin Core va dans ce sens pour son propre chemin. Il ne remplace pas la vigilance des autres implémentations.

Le logiciel hôte peut mentir. C’est même sa définition dans le modèle de menace du portefeuille matériel. L’écran de l’appareil est le témoin. Si cet écran résume mal le sighash, le témoin est myope. Les fabricants qui parsent les PSBT ont donc un travail parallèle : aligner leur refus sur la même règle, et l’expliquer sans code source.

• Adresse de destination affichée et comparée hors ligne.
• Montant et frais relus sur l’appareil, pas seulement sur l’ordinateur.
• Mode de signature nommé, surtout s’il n’est pas ALL.
• Refus explicite si une entrée SINGLE n’a pas de sortie jumelle.
• Journal du coordinateur conservé le temps de l’audit.

Pourquoi le consensus laisse passer ce qui est dangereux

Bitcoin sépare volontairement la validité et la sagesse. Une transaction peut être valide selon les règles du réseau et néanmoins stupide selon le souhait de son signataire. Le consensus ne devine pas l’intention. Il vérifie des preuves. Si une signature legacy sur le hachage constant est acceptée par les règles, les nœuds n’ont pas à la rejeter au nom du bon sens. Le bon sens appartient aux portefeuilles.

Cette frontière explique pourquoi le correctif n’est pas un soft fork. Il ne change pas ce que le réseau considère comme dépensable. Il change ce que Bitcoin Core accepte de signer. D’autres logiciels peuvent encore produire la signature. Un attaquant outillé n’a pas besoin de Bitcoin Core pour fabriquer un PSBT hostile. Il a besoin qu’une victime, ou un co-signataire distrait, appose une autorisation trop large.

C’est aussi pourquoi le discours « mettez à jour votre nœud pour être en sécurité » est incomplet ici. Mettre à jour le logiciel qui signe compte. Mettre à jour le nœud qui relaie ne répare pas une signature déjà donnée. Les deux gestes sont sains. Ils ne protègent pas la même chose.

La réutilisation legacy, le vrai surplus de gravité

Sur SegWit v0, le mal est local : la destination de cette dépense peut bouger. Sur legacy, la signature peut devenir un sésame réutilisable. Le hachage constant ne dépend pas de la pièce. Si une autre sortie non dépensée est contrôlée par la même clé et si la structure exigée est reproduite, l’autorisation peut resservir. Les développeurs l’ont indiqué clairement. Ce n’est pas une hypothèse de forum.

La leçon pratique est ancienne, et elle revient par la fenêtre. Les pièces legacy qui dorment sur une clé réutilisée concentrent le risque. Une clé qui ne sert qu’une fois limite le butin même quand une signature est trop large. Ce n’est pas une raison d’abandonner toute hygiène sur SegWit. C’est une raison de ne pas traiter toutes les adresses comme interchangeables dans un audit.

Les portefeuilles modernes dérivent des adresses et évitent la réutilisation. Les vieux backups, les imports de clés nues et certains outils d’entreprise ne le font pas. Un audit sérieux commence par la question : cette clé a-t-elle déjà signé autre chose, et reste-t-il des pièces legacy sous son contrôle ?

Ce que les équipes de trésorerie peuvent vérifier dès maintenant

Inutile d’attendre la note de version pour resserrer le process. Une équipe peut décider que tout PSBT entrant est rejeté s’il contient un sighash autre que ALL, sauf exception écrite. Elle peut exiger que le coordinateur soit open source et épinglé à un commit. Elle peut séparer la personne qui prépare le fichier de la personne qui compare les identifiants de transaction avant diffusion.

Le second contrôle le plus utile est humain. Deux yeux sur l’écran de l’appareil, pas deux yeux sur le même ordinateur. L’ordinateur est la partie non fiable. L’appareil, s’il affiche assez, ne l’est pas. Si l’appareil n’affiche pas le sighash, le process doit interdire les modes exotiques en amont, dans l’outil de construction.

Enfin, les sauvegardes de PSBT intermédiaires ne devraient pas traîner dans des boîtes mail. Un dossier à moitié signé est déjà une autorisation partielle. Le stocker au même endroit que des exports de clés, ou le transférer via un canal que le coordinateur ne contrôle pas, élargit la fenêtre. Le correctif réduit une classe de signatures. Il ne chiffre pas les pièces jointes.

Multisignature : le coordinateur est le métier à risque

Dans un coffre à trois clés dont deux suffisent, le coordinateur prépare souvent le PSBT. Les signataires font confiance à l’affichage de leur appareil. Si le coordinateur est compromis, il peut tenter de glisser un mode SINGLE sans sortie, en espérant qu’un logiciel signe quand même. Le correctif ferme cette espérance pour Bitcoin Core à jour. Un autre signataire logiciel, non patché, peut rester le maillon faible.

La parade de fond n’est pas seulement logicielle. Elle est dans la politique de quorum. Un coffre sérieux documente les types de sighash autorisés. Il refuse les transactions dont une entrée n’a pas de sortie jumelle. Il conserve les PSBT finaux, pas seulement les txid, afin de pouvoir expliquer plus tard ce qui a été engagé. Cette archive est parfois le seul moyen de distinguer une erreur d’un détournement.

Les successions et les coffres familiaux sont particulièrement exposés au coordinateur « pratique ». Un proche compétent prépare tout. Les autres signent sur confiance. Le correctif rappelle que la confiance doit porter sur ce qui est affiché, pas sur la personne qui a cliqué sur exporter. Un rituel de relecture, même lent, vaut mieux qu’une signature unique un dimanche soir.

Portefeuilles matériels : le hôte propose, l’appareil dispose

Le modèle de menace classique reste valable. L’ordinateur peut être infecté. Le fichier PSBT peut être substitué entre l’affichage à l’écran et l’envoi à l’appareil, si l’utilisateur ne compare pas. L’appareil doit donc reconstituer lui-même ce qu’il signe. S’il dépend du hôte pour savoir quelle sortie est liée à quelle entrée, il a déjà perdu.

Les fabricants n’ont pas tous le même parseur. Certains refusent depuis longtemps les sighash inhabituels. D’autres les acceptent pour des protocoles de place de marché ou de coinjoin. Le correctif de Bitcoin Core n’uniformise pas cet écosystème. Il aligne le logiciel de référence. Les utilisateurs d’appareils doivent lire les notes de leur fabricant, pas seulement celles du projet Bitcoin Core.

Un bon réflexe, en attendant, est de n’accepter un mode autre que ALL que si le protocole l’exige et si l’écran le nomme. Le confort d’un bouton avancé ne vaut pas une destination modifiable. Les protocoles qui ont vraiment besoin de SINGLE peuvent le demander explicitement, avec une sortie présente et un avertissement.

Ce que les développeurs d’outils devraient copier

La leçon d’ingénierie est plus large que le bug. Un contrôle de sécurité qui n’existe que sur un chemin est un contrôle absent. SignTransaction refusait déjà. SignPSBTInput non. Les deux rendaient service au même utilisateur, avec deux niveaux de protection. Centraliser le test dans la primitive partagée est la bonne réponse, et elle mérite d’être imitée dans les bibliothèques qui réimplémentent la signature.

La seconde leçon est le refus partiel. Marquer une entrée comme non signée, tout en continuant les autres, évite de casser des dossiers légitimes. Un échec global pousse les intégrateurs à contourner le contrôle. Un échec localisé les force à regarder l’entrée fautive. Le test ajouté autour de SIGHASH_SINGLE documente cette intention.

La troisième leçon est l’opt-in. Si un jour un protocole prouve qu’il a besoin du cas SegWit sans sortie, le choix devra être explicite. Le défaut doit rester le refus. Les footguns naissent des défauts généreux, pas des interrupteurs cachés dans un menu avancé.

BIP 174 avait déjà écrit la règle de prudence

Le standard des PSBT n’a pas découvert le problème en septembre 2026. Il demandait déjà aux signataires de rejeter les modes inacceptables, et il recommandait ALL par défaut. L’écart entre le texte et le chemin de code est un classique des logiciels anciens. Les PSBT ont grandi vite, parce que les hardware wallets en avaient besoin. Les coins de table de sighash ont été moins relus que les champs d’UTXO.

Ce n’est pas un reproche facile. Signer correctement demande de reconstituer la transaction, de connaître le type de script, de choisir le hashtype et de ne pas produire une preuve que l’utilisateur ne peut pas lire. Le correctif montre que même un projet très relu peut laisser un chemin secondaire en retrait. La lettre Optech sert ici de caisse de résonance : ce qui est fusionné un vendredi doit encore être raconté le vendredi d’après.

D’autres travaux voisins, comme la conservation du sighash lors d’un combinepsbt, rappellent que les champs optionnels ne sont pas décoratifs. Perdre le type de signature en fusionnant deux dossiers peut empêcher la finalisation, ou pire, orienter un outil vers un défaut inattendu. La robustesse d’un format se juge à ce qu’il refuse de oublier.

Une histoire de sighash qui recommence sous un autre nom

Les modes de signature de Bitcoin ont déjà produit des surprises. Le cas du hachage constant sur legacy, quand SINGLE n’a pas de sortie, est documenté depuis des années dans les lettres techniques. Il n’était pas secret. Il était traité comme un pied dont on connaît l’emplacement, jusqu’à ce qu’un chemin logiciel marche dessus. La nouveauté n’est pas la règle de consensus. C’est la découverte que le chemin PSBT produisait encore la signature.

Cette nuance change le ton juste. Parler d’une faille zero-day qui vide les portefeuilles serait faux. Parler d’un détail de développeur sans conséquence serait faux aussi. Entre les deux, il y a un bug d’implémentation sur un format très répandu, dans un mode peu utilisé, avec un effet maximal désagréable : l’argent part ailleurs sans vol de clé. Le vocabulaire doit tenir les trois bouts.

Les titres qui promettent un vol sans clé font cliquer. Ils font aussi paniquer des lecteurs qui n’ont jamais vu un PSBT. Le devoir de précision consiste à nommer le mode, l’absence de sortie, la différence legacy et SegWit, et l’absence de version publiée. Quatre précisions suffisent à remettre l’alerte à sa taille.

Ce que le correctif ne fait pas

Il ne récupère pas des fonds déjà envoyés. Il ne révoque pas une signature déjà produite. Il ne change pas les règles que les mineurs appliquent. Il ne protège pas un appareil dont le firmware signe encore le cas limite. Il ne remplace pas la comparaison d’adresse. Il ne détecte pas un coordinateur malveillant qui utiliserait un autre logiciel pour fabriquer la preuve.

Il ne concerne pas non plus, dans son énoncé, l’ensemble des variantes Taproot de la même manière que legacy et SegWit v0. Le communiqué technique vise explicitement ces deux familles pour le refus. Étendre mentalement le correctif à tous les scripts est une facilité. Les intégrateurs Taproot doivent lire le code et les tests, pas le résumé.

Il ne rend pas non plus SIGHASH_SINGLE illégitime. Des protocoles collaboratifs peuvent encore lier l’entrée 2 à la sortie 2, si cette sortie existe. Le garde-fou ne se déclenche qu’en l’absence de cette sortie. Un outil qui construit correctement ses index n’a rien à craindre du nouveau test, sinon un refus salutaire quand il se trompe.

Comment lire une note de version sans se rassurer trop vite

Quand une version stable mentionnera le correctif, trois lignes suffiront à vérifier. Le numéro 35984, ou le message de commit sur l’absence de sortie SINGLE, doit figurer. La branche de rétroportage doit être nommée. Le binaire installé doit correspondre à cette version, pas à un paquet redistribué sans changelog. Un nœud compilé à la main sur master n’est pas une preuve que le parc de l’entreprise est protégé.

Les distributions Linux et les paquets Docker ajoutent un délai. Le code fusionné en septembre peut arriver dans un dépôt communautaire en novembre. Pendant ce délai, le process interne reste la vraie protection. Attendre le paquet pour interdire SINGLE sans sortie, c’est confondre livraison et politique de signature.

Les candidats de version méritent la même froideur. Un release candidate sert à tester. Il ne prouve pas que chaque correctif de master y est entré. Le croisement entre l’annonce du candidat et la fusion du garde-fou doit être fait commit par commit, pas par proximité de dates.

Un cadre simple pour les particuliers

Le particulier qui n’utilise pas de PSBT peut retenir une phrase. Son envoi habituel n’est pas le sujet. Le particulier qui signe des fichiers envoyés par un tiers devrait poser trois questions. Quel mode de signature est demandé ? L’appareil affiche-t-il toutes les sorties ? Le fichier vient-il d’un coordinateur que l’on accepterait de voir modifier la destination ?

Si une seule réponse est non, le bon geste est de ne pas signer. Il n’y a pas d’urgence légitime à valider un dossier que l’on ne sait pas lire. Les arnaques ordinaires, faux support et fausse mise à jour, restent plus fréquentes que ce cas limite. Le correctif ne doit pas servir d’excuse pour cliquer sur un binaire envoyé par message.

La mise à jour viendra par les canaux habituels du projet et des portefeuilles. D’ici là, le défaut ALL, l’écran de l’appareil et le refus des fichiers incompris couvrent l’essentiel du risque quotidien. Le reste est un sujet d’atelier, pas de panique de week-end.

Entreprises et protocoles : une checklist de revue

Une revue interne peut tenir en une page. Inventaire des logiciels qui appellent une primitive de signature. Liste des sighash acceptés. Preuve que SINGLE sans sortie est refusé, test à l’appui. Séparation entre préparation et signature. Affichage appareil vérifié sur un firmware identifié. Procédure si un PSBT revient incomplet après le correctif : ne pas contourner, corriger l’index.

Les protocoles qui utilisent SINGLE pour de bonnes raisons devraient documenter l’invariant. Chaque entrée signée ainsi a une sortie de même index, présente avant la demande de signature. Le test peut être automatique dans la construction du dossier. S’il échoue, le protocole a un bug de construction, pas un besoin soudain de signature sans destinataire.

Les échanges qui déposent des PSBT chez des clients, pour des retraits en co-signature, ont le même devoir. Le client ne doit pas avoir à deviner si la sortie 1 existe. Le fichier doit être ennuyeux. L’ennui, en signature, est une qualité.

Ce que Bitcoin Optech a choisi de souligner

La lettre 425 ne fait pas du correctif son unique sujet. Elle évoque aussi des failles de déni de service sur d’anciennes versions d’Eclair, une piste de synchronisation d’étiquettes de portefeuille, et plusieurs discussions de recherche. Le paragraphe sur le 35984 est court, et c’est tant mieux. Il dit l’essentiel : signature SINGLE sans sortie, hachage constant en legacy, réutilisation possible, refus désormais pour legacy et SegWit v0, autres entrées toujours signées.

Ce format est le bon antidote au titre unique. Une lettre technique situe le changement parmi d’autres. Elle donne la référence. Elle ne vend pas de peur. Les rédactions généralistes qui s’en inspirent devraient garder cette proportion. Le fait est sérieux. Il n’efface pas le reste du réseau, ni les autres bugs, ni les bonnes pratiques déjà connues.

Le réseau vérifie des preuves. Il ne devine pas ce que le signataire croyait autoriser. Cette frontière est toute la différence entre une transaction valide et un paiement conforme.

Principe rappelé par le correctif de signature

Garder cette phrase en tête évite les contresens. On peut avoir une transaction que les nœuds acceptent et qu’aucun utilisateur honnête n’aurait voulue. Le travail des portefeuilles est de réduire cet écart. Le travail des rédactions est de ne pas le transformer en faille de consensus imaginaire.

Les mauvaises lectures qui circulent déjà

Première mauvaise lecture : toutes les transactions Bitcoin seraient détournables. Non. Le mode par défaut lie les sorties. Deuxième : il faudrait déplacer ses pièces ce soir. Non, pas à cause de ce seul correctif. Troisième : le correctif serait déjà dans le logiciel installé parce qu’il est sur la branche principale. Non, pas tant qu’une version publiée ne le dit pas. Quatrième : la clé serait exfiltrée. Non. La clé sert à produire une preuve trop large, elle ne quitte pas l’appareil.

Cinquième mauvaise lecture : SegWit annulerait le sujet. Non. SegWit v0 lie la pièce et le montant, pas nécessairement la destination dans ce cas. Sixième : le bug serait un soft fork caché. Non. Les règles de validité ne bougent pas. Septième : un portefeuille mobile grand public serait le vecteur principal. Rien dans le correctif ne le suggère. Le vecteur est un PSBT construit avec un sighash inhabituel.

Écarter ces lectures n’est pas minimiser. C’est empêcher qu’un bon correctif devienne une rumeur inutilisable. Les équipes qui doivent agir sont celles qui signent des dossiers partiels. Les autres peuvent suivre la note de version sans nuit blanche.

Une métaphore qui tient la route

Signer avec ALL, c’est parapher chaque page d’un contrat, bénéficiaire compris. Signer avec SINGLE, c’est parapher une ligne, à condition que la ligne existe. Signer avec SINGLE sans ligne, c’est parapher une page blanche que quelqu’un d’autre remplira. Le réseau accepte le paraphe. Le signataire, lui, croyait avoir lu un nom. Le correctif refuse désormais de poser ce paraphe blanc.

La métaphore aide, à condition de ne pas la pousser trop loin. Une page blanche legacy peut parfois resservir pour d’autres chèques de la même clé. Une page SegWit v0 est déjà liée au chèque précis et à son montant, mais le nom du bénéficiaire peut rester en blanc. Deux gravités, une seule règle de refus. C’est tout le correctif.

Après la fusion : ce qu’il reste à observer

Trois suites méritent d’être suivies sans les inventer. D’abord, la mention explicite dans une version stable ou un rétroportage. Ensuite, les notes des bibliothèques et des hardware wallets qui réimplémentent la signature. Enfin, d’éventuels tests publics montrant qu’un PSBT hostile est bien laissé non signé sur l’entrée fautive. Tant que ces trois points ne sont pas écrits, le process humain reste le filet.

Il sera utile aussi de voir si un protocole demande l’opt-in évoqué par l’auteur du correctif. S’il le fait, le débat devra être public. Un besoin réel de signature sans sortie ne devrait pas revenir par une option mal nommée. S’il ne le fait pas, le refus par défaut aura simplement aligné le code sur ce que les signataires croyaient déjà.

Le reste de l’actualité du réseau continue. Les discussions sur les coffres, les types de sortie et les canaux ne sont pas annulées par un garde-fou de signature. Les classer dans le même sac brouille les priorités. Ici, la priorité est locale : quoi est-ce que mon logiciel accepte d’autoriser ?

Réponses courtes aux questions qui reviennent

Faut-il considérer ses bitcoins comme volés ? Non. Aucun élément public ne décrit une campagne d’exploitation de masse. Le correctif ferme une production de signature, il ne répond pas à un siphonnage constaté.

Faut-il cesser d’utiliser les PSBT ? Non. Le format reste le bon outil pour signer sans exposer les clés. Il faut cesser d’accepter n’importe quel sighash dans ces dossiers.

Faut-il régénérer ses seeds ? Pas pour ce motif. Une seed n’a pas fuité par ce chemin. La régénération est un sujet de compromission de sauvegarde, pas de sighash.

Faut-il préférer SegWit ? Le v0 limite la réutilisation décrite pour legacy. Il ne règle pas à lui seul la destination non liée. La préférence pour des types de script modernes reste saine pour d’autres raisons, frais et malléabilité, sans être une armure complète ici.

Faut-il attendre pour mettre à jour ? Non. Quand la version qui contient le correctif sera publiée par les canaux habituels, la mise à jour du logiciel qui signe sera le bon geste. D’ici là, la politique de sighash fait le travail.

Le détail qui devrait rester après la lecture

Une clé privée prouve que son détenteur a autorisé quelque chose. Elle ne dit pas, à elle seule, que ce quelque chose est le paiement affiché. L’étendue de la preuve dépend du sighash. Quand cette étendue tombe à zéro sortie, l’affichage et la preuve divorcent. Bitcoin Core a choisi, sur sa branche de développement, de ne plus célébrer ce divorce. Les versions installées n’ont pas toutes suivi, au début d’octobre 2026.

C’est un épisode de plomberie, pas une remise en cause du protocole. La plomberie est exactement l’endroit où les fonds changent de tuyau. Les équipes qui construisent des transactions partielles ont une vérification simple à ajouter à leurs tests. Les autres ont une raison de plus de lire l’écran, puis d’attendre la note de version plutôt que le titre.

La prochaine étape utile n’est pas une rumeur de plus. C’est une ligne de changelog, un firmware qui refuse le même cas, et un coordinateur qui n’envoie plus de page blanche à parapher. D’ici là, le défaut reste le plus sûr des modes : tout engager, ou ne rien signer.