Le 25 septembre, Bitcoin Core a intégré une mesure de protection à sa branche de développement principale. Elle bloque un cas précis de signature PSBT qui pouvait laisser une destination de paiement sans protection. Le problème concerne SIGHASH_SINGLE, un mode de signature qui associe normalement une entrée à la sortie située à la même position. En l’absence de cette sortie, une signature peut rester valide sans engager le destinataire prévu.
Pourquoi c’est important
Cette faille n’expose pas les clés privées. Elle crée un risque d’autorisation : dans certaines conditions, un portefeuille ou un dispositif de signature pourrait afficher un destinataire, puis produire une signature qui ne garantit pas que la transaction continuera de payer ce destinataire. Les développeurs de Bitcoin Core ont indiqué que les signatures legacy concernées pourraient être réutilisées contre d’autres sorties non dépensées contrôlées par la même clé, lorsque les mêmes conditions structurelles sont réunies. SegWit v0 conserve un engagement envers la pièce concernée et son montant, mais la sortie de destination peut tout de même ne pas être liée.
Les PSBT permettent aux portefeuilles logiciels, aux appareils matériels et aux signataires hors ligne de coordonner des transactions sans transmettre les clés privées au créateur de la transaction. La frontière de signature est donc importante : une signature valide doit engager les détails approuvés par l’utilisateur. BIP 174 recommande déjà aux signataires de rejeter les modes de signature inacceptables et préconise SIGHASH_ALL lorsqu’aucune autre option n’est précisée.
Impact sur le marché
Bitcoin Core rejetait déjà ce cas limite via son interface de signature des transactions brutes, mais le parcours PSBT, notamment walletprocesspsbt, pouvait encore le signer. La modification intégrée déplace la vérification dans la logique partagée de création des signatures. Elle bloque les entrées legacy et SegWit v0 concernées tout en permettant aux autres entrées valides de la même PSBT de suivre leur cours.
La mesure a été intégrée à la branche de développement, mais aucune version de production la comprenant n’avait été confirmée au 4 octobre. Les fournisseurs de portefeuilles et les intégrateurs de signatures matérielles doivent donc examiner leur traitement des requêtes SIGHASH_SINGLE, en attendant une version ou une rétroportation.
Questions fréquemment posées
-
Quel risque la mesure de protection de Bitcoin Core visait-elle ?
Une PSBT pouvait être signée alors que la signature ne liait pas la destination de paiement approuvée par l’utilisateur. Le problème n’exposait pas les clés privées.
-
Quel est le lien entre SIGHASH_SINGLE et l’absence de sortie ?
SIGHASH_SINGLE est conçu pour lier une entrée à la sortie située à la même position. Si cette sortie est absente, la signature peut ne pas protéger la destination prévue.
-
Le problème affectait-il de la même manière les entrées legacy et SegWit v0 ?
Non. Selon les développeurs, les signatures legacy concernées pourraient être réutilisées contre d’autres sorties non dépensées dans des conditions identiques. SegWit v0 engage toujours la pièce et son montant, même si la destination peut rester sans lien.
-
Pourquoi le parcours de signature PSBT est-il important pour les utilisateurs de portefeuilles ?
Les PSBT coordonnent les transactions entre portefeuilles logiciels, appareils matériels et signataires hors ligne. Le signataire doit s’assurer que les détails de la transaction correspondent à ce que l’utilisateur a approuvé.
-
La mesure était-elle disponible dans une version de production de Bitcoin Core ?
La modification a été intégrée à la branche de développement de Bitcoin Core le 25 septembre. Au 4 octobre, aucune version de production la comprenant ni aucune rétroportation confirmée n’avait été identifiée.
WuBlockchain
CoinTelegraph
CZ Binance
CoinDesk
TheBlock