Stratum V2 vs V1 — La révolution du protocole

Stratum est le protocole qui relie les mineurs aux pools — et la version sur laquelle tourne encore l’essentiel de Bitcoin, Stratum V1, date de 2012. Il transmet les identifiants en clair, laisse le pool décider quelles transactions entrent dans chaque bloc et concentre un contrôle que Bitcoin devait disperser. Stratum V2 corrige les trois : chiffrement de bout en bout, format binaire compact et — surtout — job negotiation, qui permet à chaque mineur de construire ses propres modèles de bloc. En mai 2026, sept pools représentant environ 75% du hashrate du réseau ont soutenu la norme : le plus grand basculement vers la décentralisation que le minage ait connu depuis des années.

À retenir

• Le défaut de fond de V1 est la centralisation : le pool construit chaque modèle de bloc, donc une poignée d’opérateurs décide de ce qui entre dans la plupart des blocs Bitcoin.
• L’atout décisif de V2 est la job negotiation : les mineurs disposant de leur propre nœud choisissent leurs transactions, brisant l’emprise des pools sur le contenu des blocs.
• Le chiffrement compte surtout pour les mineurs domestiques : le texte clair de V1 autorise le détournement silencieux de hashrate sur des réseaux non fiables ; le chiffrement Noise de V2 le rend cryptographiquement impossible.
• 2026 a été le tournant : en mai, sept pools (~75% du hashrate, dont Foundry et AntPool) ont rejoint le groupe de travail Stratum V2 — après des années de projet de niche.
• En minage solo, les enjeux diffèrent : un pool solo non custodial ne contrôle jamais vos fonds ni le contenu de vos blocs, donc les bénéfices de V2 sont surtout le chiffrement, la latence et la pérennité.

Cet article explique comment fonctionne Stratum, ce que V2 change, qui le prend en charge aujourd’hui et ce qui vient ensuite — puis se clôt par une annexe étendue sur la menace quantique, car en mars 2026 Google Quantum AI a publié des travaux qui ont raccourci l’échéance à laquelle les signatures de Bitcoin pourraient céder, et la communauté de développement rédige désormais des défenses post-quantiques (BIP-360, BIP-361, Hourglass) en réponse.

Ce qu’est vraiment Stratum

Stratum est un protocole qui relie deux parties : le pool de minage (exploite des nœuds Bitcoin, construit les modèles de bloc, distribue le travail, valide les shares, verse les récompenses) et le mineur (reçoit un en-tête de bloc à hacher, itère le nonce, soumet les résultats). Chaque Antminer, Bitaxe et Whatsminer de la planète parle Stratum. Sans lui, les pools n’existeraient pas — et sans pools, la plupart des mineurs ne supporteraient pas la variance d’un travail solitaire à grande échelle. La tâche du protocole paraît simple : livrer le bon travail au bon mineur, assez vite pour que personne ne gaspille de puissance sur des tâches périmées. Mais les détails — format des messages, chiffrement et contrôle du contenu des blocs — se révèlent d’une importance énorme.

Qu’est-ce qui cloche dans Stratum V1 ?

Stratum V1, créé par Marek “Slush” Palatinus en 2012, est un simple protocole JSON-RPC sur TCP nu : rapide à implémenter, facile à déboguer. Quatorze années de recul en ont exposé plusieurs faiblesses structurelles.

1. Communication en clair

V1 envoie tout en JSON non chiffré — identifiants du pool, adresse de portefeuille, nom du worker, soumissions de shares — lisible par quiconque se trouve sur le trajet réseau. Plus dangereux encore, le texte clair permet le détournement de hashrate : un attaquant contrôlant un segment de réseau entre vous et le pool peut rediriger discrètement vos shares vers son propre pool. Braiins a documenté des cas suspects chez des mineurs en Chine, au Kazakhstan, en Russie et en Europe — détourner seulement 1-2% du hashrate suffit à entamer la rentabilité sans être évident pour la victime.

2. Sélection des transactions contrôlée par le pool

Sous V1, le pool construit le modèle de bloc et le mineur se contente de hacher l’en-tête qui arrive. C’est le pool qui décide quelles transactions entrent dans le bloc. Comme environ cinq pools contrôlent près de 70% de la puissance, une poignée d’opérateurs décide de fait du contenu de la plupart des blocs Bitcoin. Si un gouvernement fait pression sur un pool pour censurer certaines transactions, chaque mineur de ce pool y participe à son insu. Cela s’est déjà produit de façon limitée : Marathon a miné des blocs « propres » conformes à l’OFAC en 2023 à titre d’expérience, et les mineurs d’un pool filtrant n’ont aucun moyen, au niveau du protocole, de s’y soustraire.

3. Surcharge JSON et prolifération des connexions

JSON est lisible par l’humain, ce qui est excellent pour le débogage et coûteux en bande passante — noms de champs et guillemets ajoutent 30-40% de surcharge face à un équivalent binaire. Et chaque ASIC ouvre sa propre connexion TCP : une ferme de 1 000 machines maintient donc 1 000 sessions Stratum simultanées. Invisible pour un Bitaxe ; mesurable pour une grande ferme.

4. Aucune intégrité du firmware au niveau du protocole

V1 ne peut pas vérifier qu’un mineur exécute un firmware sain et connu. Un firmware compromis peut soumettre des shares subtilement erronées qui semblent valides mais coûtent de l’argent au pool, et les détecter exige un audit hors protocole.

Comment V1 a survécu malgré tout : BIP-310

Avec quatre défauts structurels, on peut légitimement se demander comment un protocole de 2012 transporte encore l’essentiel du hashrate de Bitcoin. La réponse est BIP-310, « Stratum protocol extensions » — une proposition Informational de couche Applications, attribuée le 10 mars 2018 et rédigée par Pavel Moravec et Jan Čapek de Braiins, les deux mêmes personnes qui spécifieraient Stratum V2 l’année suivante.

Le problème que BIP-310 a résolu, c’est que V1 n’avait aucun moyen d’évoluer. Envoyez à un serveur un message qu’il ne reconnaît pas et beaucoup d’implémentations ferment simplement la connexion : il n’existait donc pas de voie sûre pour proposer une nouvelle fonction. Pire, la fonction dont les mineurs avaient un besoin urgent — le version rolling — était incompatible en arrière par nature : le mineur n’avait pas de champ pour signaler une version de bloc modifiée, et le serveur aucun moyen de lui indiquer quels bits il pouvait toucher sans risque.

Un message pour toutes les négocier

La réponse de BIP-310 fut un unique nouveau message, mining.configure, dont la spécification dit qu’il DEVRAIT être le premier message envoyé par le mineur une fois la connexion établie — avant l’abonnement, avant l’autorisation. Le mineur annonce ce qu’il sait faire et demande ce qu’il veut ; le serveur répond par ce qu’il autorisera réellement, fonction par fonction. Chaque extension reçoit un espace de noms, si bien que les paramètres se lisent version-rolling.mask, minimum-difficulty.value, etc., et chacun renvoie true, false ou une chaîne d’erreur. L’objectif de conception était explicite : rendre possible l’ajout ultérieur de fonctions sans ajouter d’autres messages.

Ce mécanisme unique porte quatre extensions :

Comment le masque de version est réellement convenu

La négociation est plus subtile qu’un « demander et recevoir », et ce détail explique beaucoup de comportements observés. Le mineur envoie un masque des bits qu’il est capable de modifier ; le serveur conserve son propre masque des bits qu’il est disposé à autoriser — certains bits de version doivent rester fixes pour que le bloc soit valide ou pour la signalisation des soft forks. Le résultat est l’intersection des deux. Un mineur peut annoncer la plage complète de 16 bits 1fffe000 et recevoir en retour 18000000 — deux bits seulement. C’est une négociation réussie, pas un échec.

Avec le masque, le mineur envoie version-rolling.min-bit-count : le nombre minimal de bits qu’il lui faut pour faire du rolling efficacement en matériel. Si le pool ne peut en accorder autant, la spécification est catégorique : le pool NE DEVRAIT PAS couper la connexion — le mineur fonctionne simplement en mode dégradé, sans pleine puissance de hachage. Cette consigne explique pourquoi une machine mal accordée sous-performe en silence au lieu d’échouer bruyamment, ce qui est exactement le genre de comportement qui envoie les gens chercher une panne matérielle inexistante.

Deux autres mécanismes à connaître. Le serveur peut changer le masque à tout moment de la session avec mining.set_version_mask, et le nouveau masque prend effet immédiatement plutôt qu’au travail suivant. Et une fois le version-rolling actif, mining.submit gagne un sixième paramètre — version_bits, après nom du worker, ID du travail, extranonce2, ntime et nonce. Le mineur ne peut positionner que les bits autorisés par le serveur ; tout ce qui sort du masque invalide la share. Le serveur reconstruit ensuite la version du bloc en prenant la valeur d’origine du travail pour chaque bit hors du masque et la valeur du mineur pour chaque bit à l’intérieur.

Quels bits sont sûrs à modifier est une autre question, traitée par une spécification jumelle — BIP-320, citée dans BIP-310 alors qu’elle était encore un brouillon sans numéro. Notre analyse approfondie d’AsicBoost couvre la mécanique au niveau des bits et l’histoire des brevets qui l’entoure.

L’ironie à relever : BIP-310 est encore formellement un brouillon, huit ans plus tard, et c’est lui qui a permis à un protocole sans chiffrement ni extensibilité de rester viable une décennie de plus. Stratum V2 rend tout cet appareil inutile — version rolling, gestion de la difficulté, mises à jour d’extranonce et identification des appareils font partie du modèle de canaux de V2, négociés dans le handshake sans aucun ajout. Le mécanisme d’extension qui a sauvé V1 est précisément ce dont V2 n’a plus besoin.

Que change Stratum V2 ?

Stratum V2 a été conçu de zéro pour corriger chacun de ces points. Il a été spécifié pour la première fois en novembre 2019 par les cofondateurs de Braiins Jan Capek et Pavel Moravec, avec le développeur de Bitcoin Core Matt Corallo ; le groupe de travail a été cofondé par Braiins et Spiral en 2022. La Stratum V2 Reference Implementation (SRI) a mûri de 2024 à 2026, et Bitcoin Core v30 a ajouté une prise en charge expérimentale de V2.

Chiffrement de bout en bout (protocole Noise)

Chaque connexion V2 est chiffrée avec le framework du protocole Noise — la même base que le VPN WireGuard. Après un handshake authentifié, tous les messages sont chiffrés (ChaCha20-Poly1305 ou AES-256-GCM). En pratique : les observateurs du réseau ne voient ni votre pool, ni votre portefeuille, ni votre worker ; le détournement de hashrate devient cryptographiquement impossible ; et les identifiants n’apparaissent jamais en transit. Les pools publient des clés publiques de long terme, et les mineurs vérifient qu’ils parlent au pool légitime et non à un intermédiaire — le même modèle de sécurité que SSH.

Protocole binaire (efficace)

V2 remplace JSON par un format binaire compact : messages plus petits (environ 30% de bande passante en moins), analyse plus rapide, moins de charge CPU des deux côtés. Pour une grande ferme, ce sont de vraies économies d’infrastructure ; pour un mineur domestique sur une connexion limitée, cela signifie des travaux qui arrivent plus vite et moins de shares périmées.

Job negotiation — la fonction décisive

C’est ce qui rend V2 historiquement important, et pas seulement techniquement meilleur. Avec le job negotiation protocol, les mineurs peuvent faire tourner leur propre nœud Bitcoin complet et construire localement leurs modèles de bloc — en choisissant les transactions à inclure, en optimisant pour les frais les plus élevés ou en appliquant leurs propres règles. Le pool ne dicte plus le contenu du bloc ; il valide la preuve de travail et paie les blocs valides. Son rôle passe de « décideur » à « agrégateur de shares et validateur de PoW », et le mineur retrouve la souveraineté sur ce que sa puissance sécurise.

Trois conséquences directes : résistance à la censure (un gouvernement peut faire pression sur un pool, mais pas sur les mineurs individuels qui construisent leurs modèles — tant qu’assez de hashrate négocie ses propres travaux, les transactions censurées finissent incluses quelque part), optimisation des frais (les mineurs disposant de leur mempool peuvent capter les transactions les mieux rémunérées, surtout en période de congestion) et décentralisation des pools (les pools deviennent une infrastructure banalisée, réduisant l’incitation à se concentrer).

En somme : la job negotiation de Stratum V2 est le changement le plus conséquent dans les protocoles de minage depuis SegWit. Elle découple la fonction économique des pools (lisser la variance, verser les récompenses) de la fonction sensible à la censure (décider du contenu des blocs) — et rend la seconde aux mineurs.

État de l’adoption (mi-2026)

Pendant l’essentiel de son existence, l’adoption de V2 est restée faible — une norme de niche soutenue par quelques pools. Début 2026, on estimait que seuls 15-20% du hashrate du réseau se connectaient effectivement via V2, surtout pour les bénéfices du chiffrement plutôt que pour la job negotiation. Puis le tableau a brusquement changé.

En mai 2026, sept des plus grands pools de minage — Foundry, AntPool, F2Pool, SpiderPool, MARA Pool, Block Inc et DMND — ont rejoint le groupe de travail Stratum V2, représentant ensemble près de 75% du hashrate mondial. D’après les données Hashrate Index citées à l’époque, Foundry pesait à elle seule environ 34%, AntPool ~14%, F2Pool ~11% et SpiderPool ~10,5%. Point essentiel : V2 ne réduit pas la concentration du hashrate — Foundry conserve la même part — mais il change qui décide du contenu des blocs, ce qui est la partie qui inquiète réellement la communauté. CoinDesk y a vu le plus grand pas vers la décentralisation que le minage ait connu depuis des années.

L’engagement est une ligne de départ, pas une arrivée. « Rejoindre le groupe de travail » signifie soutenir la norme et commencer le déploiement — pas que 75% du hashrate utilise aujourd’hui la job negotiation de V2. La plupart des mineurs en V2 acceptent encore des modèles construits par le pool et s’en servent pour le chiffrement et l’efficacité. Mais avec Foundry et AntPool à bord, un protocole resté des années en marge a soudain la portée nécessaire pour devenir la norme par défaut.

Prise en charge matérielle et firmware

C’est la partie de l’histoire de V2 la plus mal rapportée, y compris dans des versions antérieures de cet article. V2 est une capacité du firmware, et en août 2026 exactement trois familles de firmware l’implémentent nativement.

• Braiins OS+ (26.07 recommandée) — le seul firmware commercial pour Antminer doté d’un client V2 natif, du S9 au S21 XP. C’est ce qui fait basculer sur V2 la famille d’ASIC la plus déployée au monde : un reflash, aucun matériel neuf.
• AxeOS 2.14.0+ — V2 natif sur Bitaxe, livré en juin 2026, consolidé en 2.15.0.
• Firmware NerdQAxe 1.0.37+ — V2 natif sur NerdAxe, NerdQAxe+/++ et NerdOCTAxe.
• Auradine FluxOS — parmi les premiers à proposer V2 natif sur sa gamme Teraflux.
• Firmware d’origine Bitmain — V1 uniquement, sur tous les modèles, S21 et S23 compris. Aucun Antminer n’est livré avec un Stratum V2 fonctionnel.
• WhatsMiner d’origine, VNish, LuxOS, Canaan/Avalon d’origine — V1 uniquement.

Deux corrections à énoncer clairement, car les deux circulent largement et coûtent une soirée. Aucun Antminer ne prend en charge V2 dans son firmware d’origine — certaines versions exposent un réglage d’apparence V2 qui ne négocie jamais de session réelle, ce qui est pire que de ne rien proposer, puisque le mineur semble configuré tout en tournant discrètement en V1. Et Bitaxe et NerdQAxe prennent bien en charge V2 nativement, depuis juin 2026 — les guides écrits avant, celui-ci compris, disaient le contraire.

Pour la configuration pas à pas de chacun d’eux — y compris les détails de l’authority key qui déterminent si votre session est seulement chiffrée ou réellement authentifiée — voyez notre guide du minage solo en Stratum V2.

Le pont du Translator Proxy

Pour le matériel ancien incapable de parler V2 nativement, SRI fournit un Translator Proxy. Votre ASIC V1 se connecte au proxy sur votre réseau local ; le proxy parle V1 au mineur et V2 au pool, vous apportant les bénéfices de chiffrement et de bande passante sans changer de firmware. La job negotiation exige toujours un V2 natif, mais le proxy couvre la couche de chiffrement pour n’importe quelle machine.

Combien de profit V2 ajoute-t-il vraiment ?

Vous verrez souvent citée la formule « V2 augmente le profit jusqu’à ~7% ». C’est une borne haute en conditions idéales, et elle se décompose à peu près ainsi :

• ~1-2% grâce au chiffrement — en supprimant le détournement silencieux qui frappe V1 non chiffré sur des réseaux non fiables
• Quelques points grâce à la sélection des transactions — faire tourner son propre mempool pour capter les transactions les mieux rémunérées, surtout en période de congestion
• ~1-2% grâce à moins de shares périmées — la latence réduite et l’efficacité binaire de V2 signifient moins de travail rejeté

En pratique, la plupart des mineurs verront quelques pour cent tout au plus — et la part liée au chiffrement ne se matérialise que si vous étiez réellement exposé au détournement. Traitez le chiffre annoncé comme un plafond, pas comme une promesse.

Ce que cela signifie pour les mineurs SoloFury

SoloFury sert Stratum V2 en production depuis août 2026, sur neuf régions réparties sur cinq continents. V1 et V2 tournent sur le même port — le pool détecte quel protocole parle votre mineur et répond en conséquence — si bien qu’un parc mixte pointe vers une seule adresse et qu’il n’y a rien à reconfigurer. V2 est disponible pour BTC ; BCH, BC2, BCH2 et XEC restent en V1 avec version-rolling complet, de sorte que tout ASIC moderne conserve son gain AsicBoost quelle que soit la chaîne visée.

Voici le point clé pour les mineurs solo : en minage solo, le pool ne contrôle pas vos fonds et ne s’interpose pas entre vous et votre récompense. Vous mettez votre adresse de portefeuille comme nom d’utilisateur stratum, le pool assemble un bloc, vous le trouvez, et la coinbase du réseau vous paie directement. Aucune garde à compromettre, aucun solde à geler. Le minage solo était déjà structurellement aligné sur les objectifs de décentralisation de V2 — c’est pourquoi, pour les mineurs solo, les gains de V2 sont le chiffrement, la latence et une capacité que le protocole rend possible de façon unique : avec un canal extended et le décodage de la coinbase, votre propre mineur affiche les sorties du bloc avant que vous ne les hachiez, ce qui vous permet de vérifier que la récompense vous est adressée plutôt que de croire le pool sur parole. (Sur pourquoi AsicBoost est du hashrate gratuit quelle que soit la version du protocole, voyez notre analyse approfondie d’AsicBoost.)

Annexe : la menace quantique pour Bitcoin

Fin mars 2026, Google Quantum AI — avec le cryptographe de Stanford Dan Boneh et Justin Drake de l’Ethereum Foundation — a publié un whitepaper, The Quantum Threat to Elliptic Curve Cryptocurrencies, qui a relancé le débat. Les modèles antérieurs supposaient des millions de qubits pour casser les signatures de Bitcoin. La nouvelle estimation de Google : moins de 500 000 qubits physiques — environ 20 fois moins que le chiffre de 2019 de ~20 millions — pourraient casser une clé privée Bitcoin en neuf minutes environ, dès qu’une transaction expose la clé publique. (Cette annexe est un contexte technique, pas un conseil en investissement ou en sécurité. La menace est réelle mais pas imminente — voir les sceptiques plus bas.)

En quoi consiste réellement la menace

Bitcoin repose sur deux primitives cryptographiques. SHA-256 (preuve de travail et arbres de Merkle) résiste au quantique à toutes fins pratiques — le casser est astronomiquement lointain, et vos ASIC ne sont pas concernés. secp256k1 ECDSA et Schnorr (les signatures numériques qui sécurisent les transactions) constituent la partie vulnérable : l’algorithme de Shor, sur un ordinateur quantique suffisamment grand, peut dériver une clé privée à partir d’une clé publique exposée.

La nuance que la plupart des articles manquent : une clé publique n’est exposée que lorsque vous dépensez depuis une adresse (ou utilisez un format ancien qui la stocke directement). En mars 2026, plus d’un tiers de tous les bitcoins — environ 6,9 millions de BTC — se trouvent dans des adresses dont les clés publiques sont déjà révélées on-chain. Environ 1,7 million sont dans d’anciennes sorties pay-to-public-key (P2PK), dont près d’un million attribué à Satoshi. Les pièces dans des adresses modernes jamais réutilisées gardent leur clé publique hachée et cachée jusqu’à la dépense.

« Récolter maintenant, déchiffrer plus tard »

Si les développeurs disent que le compte à rebours a commencé, alors qu’aucun ordinateur quantique capable n’existe, c’est que les clés publiques exposées sont permanentes et publiques. Un adversaire peut les archiver aujourd’hui et les casser dès que le matériel arrivera — et un attaquant patient pourrait calculer les clés discrètement puis siphonner les fonds des mois plus tard, si bien que le « Q-Day » ne serait reconnu qu’a posteriori. Chaque clé exposée aujourd’hui est une cible future permanente.

BIP-360 : un type d’adresse résistant au quantique

BIP-360 introduit un nouveau type de sortie — décrit comme Pay-to-Quantum-Resistant-Hash (P2QRH) ou Pay-to-Merkle-Root, avec un nouveau préfixe d’adresse bc1z. Il se comporte à peu près comme Taproot mais remplace l’élément à courbe elliptique exploitable par des signatures post-quantiques approuvées par le NIST (comme SPHINCS+, fondée sur le hachage, et CRYSTALS-Dilithium, fondée sur les réseaux euclidiens). Le compromis est la taille : les signatures post-quantiques vont de quelques kilo-octets (Dilithium) à bien davantage (SPHINCS+), contre 64-72 octets environ pour ECDSA — les blocs s’alourdissent donc et la capacité se resserre pendant toute migration. BIP-360 a été intégré au dépôt BIP de Bitcoin en février 2026, avec des implémentations déjà actives sur testnet, mais il n’est pas encore activé en soft fork.

BIP-361 : le crépuscule controversé

BIP-361, « Post Quantum Migration and Legacy Signature Sunset », rédigé par le CTO de Casa Jameson Lopp et cinq coauteurs (brouillon publié en avril 2026), propose un plan par phases pour forcer la migration hors des signatures vulnérables :

• Phase A (environ trois ans après l’activation d’un type d’adresse post-quantique) : bloquer l’envoi de fonds vers des types d’adresse vulnérables au quantique, poussant tout le monde vers des formats sûrs.
• Phase B (environ cinq ans après l’activation) : un soft fork à date fixe invalide totalement les dépenses ECDSA/Schnorr. Tout UTXO non migré devient alors indépensable.
• Phase C (optionnelle, à l’étude) : une voie de récupération permettant aux détenteurs de prouver la propriété via une preuve à divulgation nulle de leur graine BIP-39 — sans exposer de clés.

La phase B gèle de fait les ~1,7 million de BTC anciens dont les propriétaires ne peuvent migrer, ceux de Satoshi compris. Les critiques qualifient le gel de pièces — même pour les protéger — d’atteinte au droit de propriété et de précédent dangereux. Les partisans répondent que l’alternative est pire : laisser ces pièces à un futur voleur quantique qui les ramasserait et les déverserait, effondrant la confiance et le prix. Lopp présente cela comme de la théorie des jeux ; le brouillon n’est explicitement pas positionné pour une activation, et Bitcoin Core reste prudent. C’est la proposition la plus contestée de l’ensemble.

Hourglass et les alternatives

Une approche de type Hourglass en est le cousin plus doux : plutôt que de geler purement et simplement les pièces vulnérables, elle limiterait la vitesse à laquelle elles peuvent être dépensées, bridant la rapidité avec laquelle un voleur quantique pourrait les vider et les déverser, sans exclure définitivement les propriétaires honnêtes. Par ailleurs, un chercheur de StarkWare a publié un schéma rendant les nouvelles transactions résistantes au quantique dès aujourd’hui via des preuves fondées sur le hachage, optionnel et sans soft fork. Et il existe des chaînes conçues résistantes au quantique (QRL utilise des signatures XMSS fondées sur le hachage, par exemple), même si aucune n’a de part significative face à Bitcoin. Le pari dominant est que Bitcoin se mettra à jour à temps.

À quel point la menace est-elle proche, vraiment ?

Pas proche en termes de matériel. Les ordinateurs quantiques actuels fonctionnent avec des centaines de qubits logiques ; casser secp256k1 en exige des milliers de logiques (et des centaines de milliers de physiques) avec des taux d’erreur que personne n’a encore atteints à grande échelle. Les estimations supposent en outre des prouesses d’ingénierie qui peuvent prendre de longues années. Les voix appelant au calme sont notables : Adam Back, de Blockstream, soutenait en 2026 que la menace est probablement à des décennies et que la migration devrait être progressive, tandis que le cabinet McKinsey a évoqué une fenêtre 2027-2030 pour une viabilité possible, et un coauteur de BIP-360 estime qu’une migration complète pourrait elle-même prendre environ sept ans. Le résumé honnête : réelle, prise au sérieux, et pas un problème de 2026 — mais un problème que Bitcoin a choisi de commencer à résoudre tôt, parce que la migration est lente et l’offre exposée énorme.

Ce que les mineurs devraient faire aujourd’hui

1. Utilisez des formats d’adresse modernes (bech32 bc1q ou Taproot bc1p) pour tous les paiements de minage ; évitez les formats anciens quand c’est possible.
2. Ne réutilisez pas les adresses. Générez-en une par paiement — les portefeuilles modernes le font automatiquement.
3. Conservez dans des portefeuilles matériels qui se sont engagés à prendre en charge les types d’adresse post-quantiques une fois activés.
4. Suivez BIP-360 / BIP-361 / Hourglass via Bitcoin Core et les auteurs des propositions.
5. Pas de panique. La preuve de travail SHA-256 est sûre ; vos machines continuent de fonctionner à l’identique quelle que soit l’issue du débat sur les signatures.

En conclusion : les protocoles évoluent, les mineurs s’adaptent

L’histoire de Bitcoin est une suite de mises à jour qui semblaient controversées sur le moment et inévitables avec le recul. SegWit a divisé la communauté, puis s’est activé et a permis Lightning. Taproot a demandé des années de débat, puis a débloqué un scripting plus riche. Stratum V2 mettra pareillement du temps à se déployer pleinement — et nous nous demanderons ensuite comment nous avons pu tolérer un minage en clair non chiffré. La migration post-quantique sera plus longue et plus disputée, mais les incitations économiques s’alignent : protéger la valeur du réseau, protéger les pièces des utilisateurs, et commencer tant qu’il reste de la marge. Votre matériel de minage n’a besoin de changer pour rien de tout cela. Vos habitudes de portefeuille comptent plus que votre algorithme de hachage : utilisez des adresses modernes, ne les réutilisez pas, conservez sur portefeuille matériel et restez informé.