Menace quantique sur Bitcoin : un chercheur de StarkWare propose une parade sans soft fork

Une transaction protégée sans toucher au consensus

Avihu Mordechai Levy, chercheur chez StarkWare, a publié le 9 avril 2026 un papier intitulé « Quantum-Safe Bitcoin Transactions Without Softforks », accompagné d'un dépôt de code sur GitHub. Le schéma, baptisé QSB (Quantum Safe Bitcoin), vise un problème précis : les signatures ECDSA et Schnorr qui lient les éléments d'une transaction Bitcoin ne résistent pas à l'algorithme de Shor, exécuté sur un ordinateur quantique suffisamment puissant.

Le papier part d'un constat. Si la signature d'une transaction peut être falsifiée, un attaquant peut reconstruire une transaction concurrente qui dépense les mêmes fonds vers sa propre adresse, même lorsque la condition de dépense est elle-même sûre. Avec Taproot, la situation est pire selon l'auteur : toute sortie Taproot peut être dépensée par la clé, ce qui l'expose directement à un attaquant capable de calculer des logarithmes discrets.

La particularité de QSB tient à son intégration. Le schéma fonctionne avec les règles de consensus actuelles et tient dans les limites des scripts dits legacy, soit 201 opcodes et 10 000 octets, indique le papier. Il ne demande donc ni soft fork, ni signalement des mineurs, ni calendrier d'activation.

Des preuves fondées sur le hachage

QSB reprend Binohash, une construction de Robin Linus publiée en 2026, et en remplace la partie vulnérable au quantique. Le principe : le script dérive un identifiant de la transaction, puis vérifie une signature à base de hachage (de type Lamport) sur cet identifiant. Ces signatures résistent au quantique. La sécurité ne dépend plus des courbes elliptiques mais de la résistance aux préimages de la fonction RIPEMD-160.

Selon le dépôt du projet, le schéma atteint environ 118 bits de résistance à la seconde préimage face à l'algorithme de Shor, et environ 59 bits face à celui de Grover. Pour y parvenir, l'utilisateur doit résoudre un puzzle : trouver une valeur dont le hachage forme une signature DER valide, ce qui n'arrive qu'avec une probabilité d'environ 2^-46. Cette recherche se fait hors chaîne, sur des cartes graphiques.

Entre 75 et 200 dollars de calcul par transaction

Ce travail a un coût. Le papier estime la facture de calcul GPU entre 75 et 200 dollars par transaction. Les mesures de l'auteur, réalisées sur des GPU loués dans le cloud, donnent environ 75 à 150 dollars : 25 à 50 dollars pour « épingler » la transaction, puis 25 à 50 dollars pour chacune des deux séries de recherche. À titre de comparaison, CoinDesk évaluait alors les frais d'une transaction ordinaire à environ 33 cents.

D'autres limites s'ajoutent. Les transactions QSB sont valides au regard du consensus mais non standard : les nœuds Bitcoin Core ne les relaient pas par défaut. Elles doivent être transmises directement à un pool de minage qui accepte ce type de transaction, par exemple via le service Slipstream de Marathon, précise le papier. Le schéma ne couvre pas non plus les canaux du Lightning Network.

L'auteur assume ces contraintes. Il écrit que la solution fonctionne dès aujourd'hui, mais qu'elle :

should be treated as a last-resort measure

Autrement dit, une mesure de dernier recours, en raison de son coût, de la complexité de création des transactions et de sa couverture incomplète des usages de Bitcoin, selon le papier QSB. À sa publication, le dépôt indiquait que l'assemblage final de la transaction et sa diffusion sur la chaîne restaient à finaliser.

BIP-360, la voie par soft fork

QSB se pose en solution d'attente face à la piste protocolaire. La proposition BIP-360, rédigée par Hunter Beast, Ethan Heilman et Isabel Foxen Duke, crée un nouveau type de sortie, Pay-to-Merkle-Root (P2MR). Il conserve les scripts de Taproot mais supprime la dépense par clé, exposée aux attaques quantiques. BIP-360 est un soft fork : son activation suppose un consensus de la communauté. Selon CoinDesk, la proposition avait été intégrée au dépôt des BIP en février 2026, sans calendrier d'activation. Le texte de BIP-360 précise lui-même que P2MR protège contre les attaques visant des clés publiques exposées longtemps, mais pas contre les attaques rapides pendant l'attente d'une transaction dans la mempool.