La réutilisation d’une adresse Bitcoin est souvent présentée comme un problème de confidentialité. Pourtant, elle soulève aussi un risque cryptographique réel, lié à la sécurité même de la clé privée. L’enjeu concerne autant les anciennes adresses P2PKH que les formats récents SegWit (bc1q…) ou Taproot (bc1p…) : lorsqu’une adresse est réutilisée après avoir déjà servi à dépenser un UTXO, l’ensemble des fonds associés à cette même clé dépend désormais d’un matériau cryptographique exposé plusieurs fois sur la blockchain. Le présent article expose les raisons structurelles de ce risque, les mécanismes cryptographiques en jeu, et la manière concrète d’observer la clé publique révélée lors d’une dépense.
L’exposition de la clé publique : un moment critique Avant toute dépense, une adresse Bitcoin ne révèle pas la clé publique, mais seulement un hachage :
HASH160(pubkey) = RIPEMD160(SHA-256(pubkey))
Ce hachage n’offre aucune possibilité de retrouver la clé publique. Tant qu’un UTXO reste non dépensé, la clé associée demeure mathématiquement inaccessible.
Dès qu’un UTXO est dépensé :
- la signature est publiée,
- la clé publique complète est révélée,
- la validité de la signature est vérifiée contre cette clé.
À partir de ce moment, l’adresse n’offre plus la même protection cryptographique : la clé publique est exposée à l’analyse offensive, et toute réutilisation de cette même clé multiplie les données exploitables par un attaquant.
Où se trouve la clé publique au moment de la dépense ? L’emplacement exact dépend du type d’adresse :
P2PKH (adresses commençant par 1 ou 3)
Dans les transactions P2PKH, la clé publique apparaît :
- dans le scriptSig,
- immédiatement après la signature,
- sous forme hexadécimale, généralement en clé compressée (33 octets, préfixe 02 ou 03) ou non compressée (65 octets, préfixe 04).
P2WPKH (SegWit v0, adresses bc1q…)
Dans les transactions P2WPKH, la clé publique apparaît dans le witness :
- witness[0] → signature (format DER),
- witness[1] → clé publique compressée (33 octets, débutant par 02 ou 03).
Taproot (P2TR, adresses bc1p…) Les transactions Taproot utilisent des signatures Schnorr et des clés publiques x-only. La clé publique apparaît :
- dans le script witness,
- en général sous la ligne « key path spending »,
- au format x-only : 32 octets (64 hex) sans préfixe 02/03.
Sur mempool.space mempool.space n’affiche pas “Public Key” en texte clair. Il faut lire les champs bruts hexadécimaux et reconnaître le format :
- 33 octets → pubkey compressée : commence par 02 ou 03.
- 65 octets → pubkey non compressée : commence par 04.
- 32 octets → Taproot x-only pubkey.
La clé publique est donc toujours visible, mais sous la forme d’un champ hexadécimal dans les Inputs.
Pourquoi la réutilisation affaiblit-elle la sécurité ? Révéler une fois la clé publique n’est pas critique La sécurité repose sur la difficulté du problème du logarithme discret (ECDLP). Tant qu’un attaquant ne dispose que d’une seule signature produite par la clé :
- il ne peut rien reconstituer,
- il n’a pas de matière statistique,
- ECDLP reste intact.
Révéler la même clé plusieurs fois multiplie la surface d’attaque Chaque dépense d’un UTXO associée à une même adresse publie :
- une clé publique identique,
- une nouvelle signature distincte.
En ECDSA (P2PKH, P2WPKH), chaque signature nécessite un nombre aléatoire : le nonce k. k doit être :
- unique,
- imprédictible,
- parfaitement généré.
Un défaut de génération de k — événements bien documentés — permet de récupérer la clé privée si deux signatures utilisent un même k ou des k corrélés. Exemples réels :
- bug Android 2013,
- RNG matériel défaillant,
- bibliothèques OpenSSL anciennes,
- faiblesse d’entropie au boot d’un appareil,
- smartcards produisant des nonces biaisés.
La réutilisation d’adresse multiplie les signatures produites par une même clé → augmente la probabilité d’un incident cryptographique.
- Taproot améliore la situation mais ne l’annule pas
- Taproot utilise Schnorr :
nonce dérivé de façon déterministe → élimine le risque “même k”, structure linéaire des signatures plus résistante.
Mais :
- la clé x-only reste unique et exposée,
- plusieurs signatures restent exploitables pour des analyses statistiques,
- les risques matériels demeurent,
- la cryptographie post-quantique mettra à mal toute clé publique exposée.
Concentration du risque
Un portefeuille HD (BIP32) permet d’isoler chaque UTXO derrière une clé dérivée différente. La réutilisation d’adresse annule cet avantage :
- un bug dans une seule signature → compromet tous les UTXO dépendant de cette clé.
C’est la pire configuration possible en termes de compartimentation.
Et en cas d’avancées cryptographiques (quantique ou non) ? Si un attaquant obtenait la capacité de résoudre ECDLP :
- toute clé publique déjà exposée deviendrait vulnérable,
- toutes les adresses réutilisées seraient particulièrement fragiles,
- une adresse jamais dépensée resterait protégée par HASH160.
La réutilisation d’adresse concentre ainsi un risque futur que l’écosystème cherche explicitement à éviter.
Exemple concret : clé révélée dans une transaction réelle Pour la transaction :
7ee6745718bec9db76390f3a4390b9e7daeeb401e8c666a7b261117a6af654a1
Il s’agit d’un input P2WPKH. Dans le witness :
- la signature se trouve dans witness[0],
- la clé publique compressée dans witness[1].
La clé publique révélée est :
02174ee672429ff94304321cdae1fc1e487edf658b34bd1d36da03761658a2bb09
- Avant dépense : seule HASH160(pubkey) était visible.
- Après dépense : la clé publique réelle l’est, définitivement.
Conclusion
La réutilisation d’adresse Bitcoin représente un risque cryptographique tangible. Elle ne relève pas seulement d’une mauvaise hygiène de confidentialité, mais d’un problème structurel : une clé publique ne devrait être exposée qu’une seule fois, et une signature ne devrait jamais être multipliée sur une même clé si l’on souhaite maximiser la robustesse.
Les mécanismes cryptographiques actuels sont solides, mais l’expérience montre que :
- les implémentations ne sont jamais parfaites,
- les nonces peuvent être biaisés,
- les appareils peuvent manquer d’entropie,
- les attaques matérielles existent,
- la cryptanalyse progresse.
Minimiser l’exposition des clés publiques reste une bonne pratique fondamentale, aujourd’hui comme demain, et cela passe d’abord par une règle simple : ne jamais réutiliser une adresse qui a déjà dépensé un UTXO.