Stratum V2 vs V1 — La révolution du protocole

En 2012, un développeur Bitcoin nommé Marek « Slush » Palatinus a conçu un petit protocole pour que les pools de minage puissent distribuer du travail aux ASIC via internet. Il était simple, fondé sur JSON, et suffisant pour l’époque. On l’appelait Stratum V1. Quatorze ans plus tard, en 2026, ce même protocole contrôle encore environ 75 à 85 % du hashrate du réseau Bitcoin — transmettant les identifiants en clair, laissant les pools décider unilatéralement quelles transactions entrent dans les blocs, et créant exactement le type de centralisation que Bitcoin était censé rendre impossible.

Stratum V1 n’est pas cassé. Il fonctionne, globalement. Mais il a été construit avant que quiconque comprenne ce que deviendrait la centralisation des pools de minage, avant que les attaques « récolter maintenant, déchiffrer plus tard » ne soient une préoccupation sérieuse, avant que la censure des transactions ne devienne un véritable levier géopolitique. C’est le téléphone à cadran du monde du minage. Fonctionnel, familier et discrètement inadapté à ce qui vient.

Stratum V2, conçu par l’équipe de Braiins (successeur de Slush Pool) et publié en 2019 avec une implémentation de référence qui a mûri progressivement de 2024 à 2026, corrige chacune des failles structurelles de V1. Chiffrement. Protocole binaire. Négociation des tâches — la fonctionnalité qui permet aux mineurs de construire leurs propres modèles de blocs et de choisir leurs propres transactions, brisant le monopole de censure des pools. Au premier trimestre 2026, environ 25 % des grands pools prennent en charge V2 sous une forme ou une autre, et la projection pour la fin 2026 est de 40 à 60 % du hashrate du réseau.

Cet article couvre tout : comment fonctionne Stratum, ce que change V2, les calculs derrière les gains d’efficacité, qui le prend en charge aujourd’hui et le long chemin qui reste. Nous terminons par une annexe détaillée sur la menace quantique — car en mars 2026, Google Quantum AI a publié des recherches qui ont fondamentalement redessiné le calendrier du moment où la cryptographie sous-jacente de Bitcoin pourrait être brisée, et la communauté de développement Bitcoin est désormais dans un sprint discret pour déployer des défenses post-quantiques (BIP-360, BIP-361, Hourglass V2) avant que la menace ne se matérialise.

Ce qu’est réellement Stratum (en bref)

Stratum est un protocole qui relie deux parties :

• Le pool de minage — fait tourner des nœuds Bitcoin, construit les modèles de blocs, distribue le travail aux mineurs, valide les parts soumises, verse les récompenses.
• Le mineur — reçoit du travail (en-têtes de blocs à hacher), itère le champ nonce à la recherche d’un hash valide, renvoie les résultats.

Chaque Antminer, Bitaxe et Whatsminer de la planète parle Stratum. Sans lui, les pools de minage ne pourraient pas exister. Sans pools, le minage en solo serait la seule option — et la plupart des mineurs ne peuvent pas tolérer la variance du minage en solo à l’échelle industrielle.

Le travail de Stratum est simple : livrer le bon travail au bon mineur, assez vite pour que personne ne gaspille de puissance de hachage sur des tâches périmées. Les détails du protocole — format des messages, chiffrement, qui contrôle le contenu des blocs — s’avèrent avoir une importance énorme.

Stratum V1 — ce qui ne va pas

Stratum V1 a été publié en 2012 comme un simple protocole JSON-RPC sur TCP en clair. Rapide, facile à implémenter, facile à déboguer. Douze ans de recul accumulé ont révélé cinq problèmes structurels :

1. Communication en clair

Stratum V1 transmet tout en JSON non chiffré. Vos identifiants de pool, votre adresse de portefeuille, le nom de votre worker, vos soumissions de parts — tout est lisible par quiconque se trouve sur le chemin réseau. Les FAI, les administrateurs réseau, la surveillance étatique et les attaquants sophistiqués peuvent tous voir ce que vous minez et où.

Plus dangereux encore, le stratum en clair permet le détournement de hashrate. Un attaquant qui contrôle un segment de réseau entre vous et le pool peut rediriger silencieusement vos parts vers son propre pool, volant jusqu’à 2 % de votre hashrate avant d’être détecté. Les recherches de Hashlabs (2025) ont vérifié qu’il s’agit d’un vecteur d’attaque réel, déjà exploité en environnement de production.

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

Avec Stratum V1, c’est le pool qui construit le modèle de bloc. Le mineur se contente de hacher l’en-tête que le pool lui envoie. C’est le pool qui décide quelles transactions entrent dans le bloc. Le mineur ne contribue en rien à cette décision — il n’est en pratique qu’un générateur de SHA-256 à louer.

C’est le problème de la centralisation. 99 % du hashrate de Bitcoin transite par une poignée de pools de minage. Si un gouvernement fait pression sur un pool pour censurer certaines transactions (conformité aux sanctions, décisions de justice, mandats réglementaires), tous les mineurs de ce pool participent à leur insu à la censure. Leurs hashs sécurisent un bloc qui exclut les transactions censurées.

Cela arrive déjà. Marathon Digital, Foundry USA et d’autres ont mis en place un filtrage des transactions conforme à l’OFAC à divers moments. Les mineurs qui utilisent ces pools n’ont aucun mécanisme au niveau du protocole pour se désengager. Stratum V1 vous rend complice par défaut.

3. Surcharge du JSON

Le JSON est lisible par un humain, ce qui est excellent pour le débogage et désastreux pour la bande passante. Chaque message Stratum est enveloppé dans une structure JSON, où les noms de champs et les guillemets ajoutent 30 à 40 % de surcharge par rapport à un équivalent binaire. Pour une seule machine S21+ qui soumet des parts, c’est invisible. Pour une ferme de 10 000 machines, c’est un coût de bande passante mesurable.

4. Pas de session multi-machines native

Chaque ASIC ouvre sa propre connexion TCP vers le pool. Une ferme de 1 000 machines fait tourner 1 000 connexions Stratum simultanées. Le serveur stratum du pool doit gérer cette échelle ; le réseau de la ferme aussi. Les deux sont faisables, mais aucun n’est élégant.

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

Stratum V1 n’a aucun moyen de vérifier que le mineur fait tourner un firmware connu comme sain. Les attaquants qui compromettent le firmware d’un mineur peuvent soumettre des parts subtilement défectueuses qui semblent valides mais coûtent de l’argent au pool. La détection nécessite un audit hors protocole.

Stratum V2 — ce qui change

Stratum V2 a été conçu de zéro pour résoudre chacun de ces problèmes. L’implémentation de référence de Stratum V2 (SRI), maintenue par le groupe de travail Stratum V2, est en développement actif depuis 2019 et a atteint une version 1.0 prête pour la production en 2024. De 2025 à 2026, l’implémentation s’est stabilisée, avec les versions 1.0.0 à 1.6.0 déployées par divers pools.

Chiffrement de bout en bout (protocole Noise)

Chaque connexion Stratum V2 est chiffrée à l’aide du framework du protocole Noise — la même base cryptographique que celle utilisée par le VPN WireGuard. L’authentification et l’échange de clés ont lieu lors de la poignée de main initiale. Une fois établie, tous les messages suivants sont chiffrés avec ChaCha20-Poly1305 ou AES-256-GCM.

Ce que cela signifie en pratique :

• Les FAI et les observateurs du réseau ne peuvent pas voir vos informations de pool, de portefeuille ou de worker
• Les attaques par détournement de hashrate deviennent cryptographiquement impossibles
• Les identifiants de pool ne sont jamais exposés en transit, même sur un réseau local malveillant
• L’analyse du trafic est plus difficile — les observateurs voient passer des octets chiffrés mais pas leur signification

L’authentification utilise des paires de clés publique/privée. Les pools publient leurs clés publiques de long terme, et les mineurs vérifient qu’ils se connectent au pool légitime — et non à un intermédiaire malveillant. C’est le même modèle de sécurité que SSH. Familier, bien compris, éprouvé.

Protocole binaire (efficace)

Stratum V2 remplace le JSON par un format binaire compact. Les messages sont plus petits (réduction de la bande passante d’environ 30 %), plus rapides à analyser et imposent moins de charge CPU au pool comme au mineur. Pour une grande ferme, cela se traduit par des économies significatives de réseau et d’infrastructure. Pour un mineur à domicile sur internet par satellite ou une connexion limitée, V2 signifie que les tâches arrivent plus vite et que les parts périmées diminuent.

Protocole de négociation des tâches — la fonctionnalité décisive

C’est ce qui rend Stratum V2 historiquement important, et pas seulement techniquement meilleur.

Avec le protocole de négociation des tâches de Stratum V2, les mineurs peuvent faire tourner leurs propres nœuds Bitcoin complets et construire localement leurs propres modèles de blocs. Ils choisissent quelles transactions inclure. Ils optimisent pour les frais les plus élevés, ou incluent des transactions spécifiques, ou appliquent leurs propres politiques de filtrage. Le pool ne dicte plus le contenu du bloc — il se contente de valider la preuve de travail et de payer le mineur pour avoir trouvé un bloc valide.

Le déroulement :

# Avec la négociation des tâches activée :
1. Le mineur fait tourner bitcoind localement (nœud complet).
2. Le mineur se connecte au pool via Stratum V2.
3. Le mineur soumet son propre modèle de bloc via le protocole de négociation des tâches.
4. Le pool valide le modèle (sortie coinbase correcte vers le pool, format valide).
5. Le pool renvoie une tâche pour que le mineur hache contre SON modèle.
6. Le mineur trouve un hash valide, le soumet au pool.
7. Le pool propage le bloc au réseau.
8. La récompense de bloc va à celui que désigne la coinbase.

Le rôle du pool se réduit de « décideur » à « agrégateur de parts et validateur de PoW ». Le mineur reprend sa souveraineté sur ce que sa puissance de hachage sécurise.

Pourquoi la négociation des tâches compte pour Bitcoin

Trois conséquences directes :

1. Résistance à la censure — Un gouvernement peut faire pression sur un pool pour exclure des transactions, mais il ne peut pas forcer les mineurs individuels disposant de leurs propres modèles à s’y conformer. Tant qu’assez de hashrate fonctionne en mode négociation des tâches, les transactions censurées finiront par être incluses par un mineur, sur un pool, quelque part. La censure devient statistiquement vaine.
2. Optimisation des frais de transaction — Les mineurs qui font tourner leur propre mempool peuvent inclure les transactions aux frais les plus élevés disponibles localement, gagnant potentiellement plus que le modèle par défaut d’un pool. Les recherches de Hashlabs ont montré que cela peut augmenter les profits nets du mineur jusqu’à 7,4 % dans des conditions optimales.
3. Décentralisation des pools — Les pools deviennent une infrastructure banalisée (juste stratum + traitement des paiements), réduisant l’incitation à la consolidation des pools. De nouveaux pools peuvent se lancer avec une charge de conformité réduite parce qu’ils ne contrôlent pas unilatéralement le contenu des blocs.

En résumé : le protocole de négociation des tâches de Stratum V2 est la mise à niveau du protocole de minage la plus importante depuis SegWit. Il restructure les incitations économiques et politiques de toute l’industrie du minage en l’éloignant de la centralisation.

État de l’adoption (T2 2026)

La transition de V1 à V2 est bien engagée mais loin d’être terminée :

Pools prenant en charge Stratum V2

Le groupe de travail SRI prévoit que d’ici fin 2026, V2 sera le protocole par défaut des nouvelles livraisons de firmware ASIC, atteignant potentiellement 40 à 60 % du hashrate du réseau. L’usage de la négociation des tâches reste en retard sur l’adoption brute de V2 — la plupart des mineurs qui utilisent V2 aujourd’hui le font pour les bénéfices du chiffrement, sans faire tourner leurs propres nœuds complets pour la sélection des transactions.

Prise en charge matérielle

• Séries Antminer S21 / S21+ / S21 Pro / S21 XP / S23 — Prise en charge V2 native dans le firmware d’usine
• Antminer S19 XP — V2 via mise à jour du firmware
• Antminer S19 / plus anciens — V1 uniquement en firmware d’usine ; V2 via BraiinsOS+ ou Translator Proxy
• Séries Whatsminer M50/M60/M66 — V2 via mise à jour du firmware
• Bitaxe Supra/Ultra/Gamma — V2 via mises à jour du firmware AxeOS (2025+)
• Auradine Teraflux — Premier mineur ASIC livré avec Stratum V2 natif dès le premier jour (2024)
• NerdQAxe / NerdOCTAxe — V2 via firmware

Le pont Translator Proxy

Pour le matériel plus ancien qui ne sait pas parler V2 nativement, le SRI fournit un Translator Proxy. Votre ASIC Stratum V1 existant se connecte au proxy sur votre réseau local. Le proxy parle V1 à votre mineur et V2 au pool, vous offrant les bénéfices du chiffrement et de la bande passante sans mise à jour du firmware. La négociation des tâches nécessite V2 natif, mais le proxy est un pont viable pour la couche de chiffrement.

L’affirmation des 7,4 % de profit en plus, examinée

Hashlabs a publié, en collaboration avec l’équipe SRI, des recherches montrant que Stratum V2 peut augmenter les profits nets du mineur jusqu’à 7,4 %. Ce chiffre est souvent cité, alors décomposons d’où il vient :

• ~2 % grâce au chiffrement — en éliminant le détournement silencieux de hashrate qui touche les connexions V1 non chiffrées sur les réseaux non fiables
• ~3-4 % grâce à la sélection des transactions — les mineurs qui font tourner leur propre mempool peuvent prioriser les transactions aux frais les plus élevés plutôt que le modèle par défaut du pool, surtout en période de frais élevés
• ~1-2 % grâce à la réduction des parts périmées — la latence plus faible et l’efficacité binaire de V2 entraînent moins de parts rejetées pour cause de travail obsolète

Les 7,4 % sont une borne supérieure dans des conditions idéales. La plupart des mineurs constateront 2 à 5 % en pratique, selon leur environnement réseau, la dynamique des frais du mempool, et le fait qu’ils fassent tourner ou non leur propre nœud complet.

Détournement de hashrate — l’attaque silencieuse que permet V1

Cela mérite sa propre section, car c’est la faille de sécurité la plus sous-estimée de Stratum V1.

Un attaquant sur le chemin réseau entre le mineur et le pool (cela inclut le WiFi partagé, les routeurs compromis, les adversaires au niveau des FAI et la surveillance étatique) peut mener l’attaque suivante :

1. Détecter le trafic Stratum V1 (facile — c’est du JSON en clair sur des ports courants)
2. Intercepter la soumission de parts valides par le mineur
3. Rediriger ces parts vers le propre pool de l’attaquant, avec le portefeuille de l’attaquant comme destinataire
4. Renvoyer au mineur assez de fausses réponses de succès pour qu’il ne remarque rien

Résultat : 1 à 3 % de la puissance de hachage du mineur s’écoule silencieusement vers l’attaquant. Le mineur constate une légère baisse d’efficacité mais aucune panne évidente. Multiplié sur des millions de mineurs vulnérables dans le monde, c’est un vol potentiellement considérable.

Le chiffrement de Stratum V2 rend cette attaque cryptographiquement impossible. Les parts ne peuvent pas être modifiées en transit. Le portefeuille de destination ne peut pas être échangé. Les gains du mineur atteignent le pool légitime intacts.

C’est l’une des raisons les plus concrètes pour lesquelles les mineurs à domicile devraient adopter V2 dès que leur firmware le permet. Les fermes industrielles aux réseaux contrôlés courent moins de risque ; les mineurs à domicile sur des FAI résidentiels en courent davantage.

La voie à suivre

Stratum V2 n’est pas l’aboutissement des protocoles de minage. La feuille de route continue :

• Intégration de Lightning pour les parts — micropaiements instantanés pour les soumissions de parts, éliminant le besoin de paiements groupés
• Sous-pools avec consensus personnalisé — des groupes de mineurs formant des sous-pools avec leurs propres politiques de filtrage, puis s’agrégeant dans le pool principal
• Schémas de signature résistants au quantique — remplacer l’authentification basée sur ECDSA par des alternatives post-quantiques (plus de détails dans l’annexe)
• Sélection des transactions préservant la confidentialité — utiliser des preuves à divulgation nulle de connaissance pour prouver la validité d’un bloc sans révéler l’identité du mineur

La plupart de ces éléments sont au stade de la recherche en 2026. Stratum V2 lui-même est le livrable de cette décennie. Les fonctionnalités de nouvelle génération s’intégreront probablement dans une future spécification « V3 » qui s’appuiera sur les fondations de V2.

Ce que cela signifie pour les mineurs SoloFury

SoloFury fonctionne actuellement sur un fork de ckpool/public-pool, qui est basé sur Stratum V1. Nous suivons de près l’adoption de V2 et évaluons les pistes d’implémentation. Pour l’instant :

• Nos points d’accès stratum prennent en charge Stratum V1 avec version-rolling (BIP320) — compatibilité AsicBoost complète, tous les ASIC modernes fonctionnent sans modification de configuration
• Nous prenons en charge le basculement multi-régions (Francfort, Atlanta, Singapour) pour une livraison stratum mondiale à faible latence
• Nous sommes non-dépositaires par conception — la récompense de bloc va de la coinbase du réseau directement à votre portefeuille, donc les problèmes de centralisation que V2 corrige (le pool dicte le flux de fonds) ne s’appliquent de toute façon pas au minage en solo

Le point le plus important de Stratum V2 pour les mineurs en solo en particulier : dans le minage en solo, le pool ne contrôle pas la sélection des transactions de la manière que Stratum V2 atténue. Vous définissez votre nom d’utilisateur stratum comme votre adresse de portefeuille, le pool construit le bloc, vous le trouvez, le réseau vous paie directement. Il n’y a aucune garde à compromettre, aucun solde à geler, et aucune bataille de sélection de transactions à mener.

Le minage en solo était déjà structurellement aligné avec les objectifs de décentralisation de V2. Le rôle du pool dans le minage en solo est opérationnel, pas dépositaire. Quand SoloFury passera à V2 (prévu pour fin 2026), les bénéfices seront principalement le chiffrement, la latence et la compatibilité future avec les fonctionnalités du protocole — pas la décentralisation existentielle que V2 apporte au minage en pool traditionnel.

📡 ANNEXE : La menace quantique — ce qui attend Bitcoin

En mars 2026, des chercheurs de Google Quantum AI ont publié un livre blanc qui a fondamentalement changé le calendrier du moment où les ordinateurs quantiques pourraient menacer Bitcoin. Les modèles précédents supposaient que des millions de qubits physiques seraient nécessaires pour briser la cryptographie à courbe elliptique de Bitcoin. Les recherches de Google ont montré qu’environ 500 000 qubits suffiraient — une amélioration d’efficacité de 20× qui a compressé le calendrier attendu de « dans des décennies » à « potentiellement 5 à 10 ans ».

La communauté de développement Bitcoin a réagi avec une urgence discrète. À la mi-2026, trois grandes propositions sont activement discutées : BIP-360 (Pay-to-Merkle-Root avec signatures post-quantiques), BIP-361 (Migration post-quantique et extinction des signatures héritées), et Hourglass V2 (dépense lente des anciennes pièces exposées). Le débat est intense, les défis techniques sont importants, et la question politique de savoir s’il faut forcer la migration via un soft fork reste véritablement non résolue.

Cette annexe couvre ce que les mineurs doivent réellement savoir.

Qu’est-ce que la menace quantique ?

Bitcoin utilise deux primitives cryptographiques principales :

1. SHA-256 — pour la preuve de travail (minage) et les arbres de Merkle. Résistant au quantique dans tout sens pratique (briser SHA-256 nécessiterait environ 10²³ qubits et une énergie à l’échelle stellaire ; cela n’arrivera pas avec une technologie à échelle humaine).
2. ECDSA secp256k1 (et Schnorr dans Taproot) — pour les signatures numériques sécurisant les transactions. Vulnérable à l’algorithme de Shor sur un ordinateur quantique suffisamment puissant.

L’algorithme de Shor, publié par Peter Shor en 1994, peut résoudre le problème du logarithme discret sur courbe elliptique en temps polynomial sur un ordinateur quantique. Concrètement : s’il existe un ordinateur quantique d’environ 500 000 qubits logiques, il peut déduire une clé privée d’une clé publique exposée en environ 9 minutes. Les signatures de Bitcoin ne seraient plus sûres, et toute adresse avec une clé publique exposée serait vulnérable au vol.

Quelles pièces Bitcoin sont vulnérables ?

Environ 6,7 millions de BTC se trouvent dans des adresses à clé publique exposée. Elles se répartissent en trois catégories :

• Anciennes sorties P2PK (~1,7 M BTC) — les débuts de Bitcoin utilisaient des sorties « Pay to Public Key » qui plaçaient la clé publique complète dans l’UTXO. La plupart des pièces minées par Satoshi Nakamoto sont au format P2PK. Elles sont exposées aujourd’hui, indépendamment du quantique.
• Adresses réutilisées (~5 M BTC) — toute adresse ayant déjà envoyé une transaction a sa clé publique révélée dans la signature de cette transaction. Si vous réutilisez la même adresse, votre clé publique est exposée en permanence dans la blockchain.
• Pièces perdues/dormantes — beaucoup des pièces exposées sont présumées perdues (pièces de Satoshi, pièces des premiers mineurs de 2009-2011, portefeuilles perdus). Elles sont exposées depuis plus d’une décennie et rien ne leur est encore arrivé — mais c’est parce qu’aucun ordinateur quantique n’existe encore.

Les pièces dans des adresses modernes P2PKH ou P2WPKH (le format standard commençant par « 1… », « 3… » ou « bc1… ») ne sont PAS exposées, sauf si l’adresse a été réutilisée. La clé publique est hachée une fois pour l’adresse, et la clé réelle n’est révélée que lorsque vous dépensez. Si vous ne réutilisez jamais une adresse, vous êtes protégé jusqu’à ce que vous dépensiez.

L’attaque « récolter maintenant, déchiffrer plus tard »

On pense que les adversaires de niveau étatique (Chine, États-Unis, Russie) collectent et archivent déjà de grandes quantités de données blockchain chiffrées — y compris toutes les clés publiques Bitcoin exposées — dans l’intention de les casser lorsque les ordinateurs quantiques seront assez puissants.

Ce n’est pas de la paranoïa. La NSA a explicitement déclaré collecter des données chiffrées à l’échelle mondiale en vue d’un déchiffrement futur. La même logique s’applique aux données blockchain. Chaque clé publique Bitcoin exposée aujourd’hui est une cible future potentielle. L’urgence de BIP-360 n’est pas théorique — il s’agit de protéger les ensembles d’UTXO historiques contre les ordinateurs quantiques de demain.

BIP-360 : Pay-to-Merkle-Root (P2MR)

BIP-360 introduit un nouveau type de sortie Bitcoin appelé Pay-to-Merkle-Root (P2MR). Au lieu de stocker une clé publique (ou son hash), P2MR stocke une racine de Merkle sur plusieurs schémas de signature post-quantiques.

Concrètement, P2MR prend en charge :

• SPHINCS+ — signatures basées sur le hachage, considérées comme l’option post-quantique la plus conservatrice (approuvée par le NIST)
• CRYSTALS-Dilithium — signatures basées sur les réseaux euclidiens, plus efficaces mais plus récentes (approuvées par le NIST)
• Prise en charge optionnelle de FALCON pour des signatures compactes

Quand vous dépensez une sortie P2MR, vous révélez quel schéma de signature vous utilisez et fournissez la signature correspondante. La structure de preuve de Merkle fait que la sortie elle-même n’expose aucune clé publique unique — seulement la racine de Merkle, qui n’aide pas les attaquants quantiques.

Compromis :

• Les signatures SPHINCS+ sont VOLUMINEUSES — ~30 Ko par signature contre ~64 octets pour l’ECDSA actuel de Bitcoin. Cela alourdit considérablement les blocs.
• Les signatures Dilithium sont plus petites (~2,5 Ko) mais restent 30 à 40× plus grandes que l’ECDSA
• La capacité des blocs diminue effectivement si tout le monde migre vers P2MR — moins de transactions par bloc pendant la période de migration

BIP-360 est actuellement une proposition à l’état de brouillon. L’implémentation est en cours sur la branche expérimentale de Bitcoin Core. L’activation par soft fork est improbable avant 2027-2028.

BIP-361 : Migration post-quantique et extinction des signatures héritées

C’est la proposition controversée. BIP-361, portée par Jameson Lopp, propose un calendrier structuré pour forcer la migration hors des signatures vulnérables au quantique :

• Phase A : P2MR (BIP-360) s’active comme standard. Les nouvelles adresses utilisent par défaut des signatures post-quantiques.
• Phase B (5 ans après la Phase A) : un soft fork « jour butoir » invalide tous les chemins de signature ECDSA et Schnorr. Tout UTXO non migré vers P2MR à cette date devient indépensable.
• Phase C (en discussion) : une voie de récupération potentielle pour les UTXO gelés à l’aide de preuves à divulgation nulle de connaissance (par ex. prouver la possession d’une graine BIP-39 sans exposer les clés).

L’argument politique : la Phase B gèle effectivement environ 6,7 M BTC appartenant à des utilisateurs qui ne migrent pas à temps. Les critiques qualifient cela d’« autoritaire » et de violation des droits de propriété immuables. Les partisans parlent d’« action défensive nécessaire » — l’alternative étant de laisser les voleurs quantiques vider ces pièces quand la technologie sera mûre, les déversant sur le marché et faisant s’effondrer le prix de Bitcoin.

La réaction sur le Bitcoin Twitter a été massivement négative. La réaction parmi les détenteurs institutionnels a été discrètement favorable — ils ont des expositions de plusieurs milliards de dollars qu’ils veulent protéger. Le débat reste véritablement non résolu à la mi-2026.

Hourglass V2 — l’approche alternative

Une alternative au gel pur et dur de BIP-361 est Hourglass V2, qui imposerait une limite de vélocité aux dépenses de signatures héritées. Les pièces dans des adresses vulnérables pourraient toujours être dépensées, mais seulement à un rythme limité (par ex. 1 % par an).

Cela atteint le même objectif défensif (empêcher les voleurs quantiques de déverser soudainement des millions de BTC volés sur le marché) sans geler définitivement les pièces de quiconque. Le compromis : une migration plus lente, une fenêtre d’exposition plus longue.

Hourglass V2 est activement développé par un groupe de travail de développeurs distinct. Il pourrait être proposé en alternative ou en complément de BIP-361.

Les voies de sauvetage par zk-STARK

Roasbeef, CTO de Lightning Labs, a publié à la mi-2026 une implémentation prototype de mécanismes de sauvetage à divulgation nulle de connaissance. L’idée : même si vos pièces sont gelées par le jour butoir de BIP-361, vous pouvez ensuite prouver leur propriété via des preuves zk-STARK qui démontrent la connaissance de la phrase de récupération d’origine sans jamais exposer la clé elle-même.

Cela n’empêcherait pas le gel, mais offrirait une voie aux propriétaires légitimes pour finir par dégeler leurs pièces. Les pièces perdues (aucune graine disponible) restent gelées définitivement.

La Quantum Safe Bitcoin (QSB) de StarkWare adopte une approche différente : elle permet des transactions résistantes au quantique dès aujourd’hui via des preuves basées sur le hachage, sans nécessiter de soft fork. Les utilisateurs y adhèrent en déplaçant leurs pièces vers des scripts compatibles QSB. L’adoption est lente mais la technologie existe déjà.

Le calendrier réaliste

Ce que nous savons :

• Ordinateurs quantiques actuels (2026) : ~1 500 qubits physiques, ~100 qubits logiques
• Nécessaire pour briser Bitcoin : ~500 000 qubits physiques, ~2 400 qubits logiques
• Estimations les plus agressives : 5 à 10 ans pour atteindre l’échelle requise
• Estimations conservatrices : 10 à 20 ans, peut-être jamais

Ce qui est probable :

• 2026-2027 : standardisation de BIP-360, affinage du brouillon, déploiement sur testnet
• 2028-2029 : activation de BIP-360 en soft fork. Nouvelles adresses post-quantiques par défaut.
• 2029-2032 : phase de migration des utilisateurs. Les plateformes d’échange, portefeuilles et dépositaires mettent à niveau leur infrastructure.
• 2030-2034 : le calendrier d’activation de BIP-361 dépend de la matérialisation de la menace quantique. Si les ordinateurs quantiques approchent le seuil des 500 000 qubits, l’urgence augmente fortement. Si les progrès quantiques stagnent (ce qui est déjà arrivé), BIP-361 pourrait être reporté indéfiniment.

La communauté Bitcoin a historiquement été lente à se mettre à niveau — SegWit a pris ~2 ans de la proposition à l’activation, Taproot ~3 ans. La migration post-quantique est sans précédent par son ampleur : chaque portefeuille, plateforme d’échange, dépositaire et fournisseur d’infrastructure doit prendre en charge simultanément de nouveaux schémas de signature. Des calendriers de migration de 5 à 7 ans sont optimistes. 10 à 15 ans est réaliste.

Impact sur le minage

L’impact direct sur les opérations de minage est minime :

• SHA-256 (preuve de travail) est résistant au quantique. Vos ASIC continuent de fonctionner sans changement.
• Les récompenses de bloc s’écoulent toujours vers l’adresse que vous spécifiez dans la coinbase
• Si votre portefeuille de minage est dans une adresse moderne jamais réutilisée, vos gains sont à l’abri du quantique

Impact indirect :

• Pression sur la taille des blocs — si tout le monde migre vers P2MR, la capacité des blocs se réduit effectivement de 30 à 50 % pendant la fenêtre de migration. Les frais de transaction pourraient augmenter temporairement en conséquence.
• La dynamique du mempool change — les transactions à frais élevés pendant la migration donnent un réel avantage aux mineurs disposant d’une sélection de mempool personnalisée (les utilisateurs de la négociation des tâches de Stratum V2)
• Le marché du hashrate gagne en importance — l’incertitude autour des calendriers quantiques pourrait affecter la volatilité du prix de Bitcoin, ce qui affecte directement l’économie des mineurs

Ce que les mineurs devraient faire aujourd’hui

1. Utilisez des formats d’adresse modernes. P2WPKH (bc1q…) ou Taproot (bc1p…) pour tous les paiements de minage. Évitez les anciens P2PK ou P2PKH quand c’est possible.
2. Ne réutilisez pas les adresses. Générez une nouvelle adresse pour chaque transaction. Les portefeuilles modernes le font automatiquement — ne le désactivez pas.
3. Suivez l’avancement de BIP-360 / BIP-361 / Hourglass V2. Anthony Towns, Jameson Lopp et l’équipe Bitcoin Core publient régulièrement des mises à jour.
4. Utilisez des portefeuilles matériels. La plupart des portefeuilles matériels se sont engagés à prendre en charge BIP-360 une fois activé. Garder ses pièces sur Ledger, Trezor ou Coldcard garantit de pouvoir migrer le moment venu.
5. Ne paniquez pas. La menace est réelle mais lointaine. Les mises à niveau du protocole Bitcoin sont lentes mais historiquement réussies. SegWit a eu lieu. Taproot a eu lieu. Le post-quantique aura lieu.

Les alternatives résistantes au quantique (en bref)

Certaines cryptomonnaies ont été conçues dès le départ avec une résistance au quantique :

• QRL (Quantum Resistant Ledger) — utilise des signatures XMSS basées sur le hachage, totalement résistantes au quantique depuis 2018
• IOTA — signatures à usage unique de Winternitz, résistantes au quantique
• Nervos CKB — prend en charge les scripts post-quantiques

Aucune d’elles n’a de part de marché ou d’adoption significative comparée à Bitcoin. Le pari que font la plupart des observateurs : Bitcoin se mettra à niveau à temps. L’infrastructure existe, les propositions sont en cours d’affinage, la volonté politique se forme. L’alternative — laisser Bitcoin devenir vulnérable au quantique — est inacceptable pour tout l’écosystème, des détenteurs individuels aux dépositaires institutionnels en passant par les développeurs du protocole eux-mêmes.

Pour conclure : les protocoles évoluent, les mineurs s’adaptent

L’histoire de Bitcoin est une série de mises à niveau du protocole qui semblaient controversées sur le moment et inévitables avec le recul. SegWit a divisé la communauté, puis s’est activé, puis a permis le Lightning Network. Taproot a demandé des années de débat, puis s’est activé, puis a débloqué des possibilités de scripts complexes. Stratum V2 prendra de même des années à se déployer pleinement, puis il deviendra la nouvelle norme, et nous nous demanderons comment nous avons pu tolérer une communication de minage en clair non chiffrée.

La migration quantique sera plus longue, plus conflictuelle et plus perturbatrice — mais elle aura lieu elle aussi. Les incitations économiques convergent : protéger la valeur de Bitcoin, protéger les pièces des utilisateurs, prévenir la catastrophe d’un vol de masse quand les ordinateurs quantiques arriveront à maturité. Le travail technique est bien engagé. Le travail politique est plus difficile, mais Bitcoin a déjà traversé des batailles politiques plus rudes.

Pour les mineurs SoloFury en particulier : nous suivons tout cela. Le déploiement de Stratum V2 est sur notre feuille de route pour fin 2026 / début 2027. La prise en charge des signatures post-quantiques suivra l’implémentation de BIP-360 par Bitcoin Core. Votre matériel de minage n’a besoin de rien changer pour tout cela — SHA-256 est l’algorithme qui est sûr. Vos pratiques de portefeuille comptent plus que votre algorithme de hachage : utilisez des adresses modernes, ne les réutilisez pas, conservez sur des portefeuilles matériels, restez informé.

Le minage est un jeu de longue haleine. Les mises à niveau du protocole font partie du jeu. Les mineurs qui restent informés et s’adaptent sont ceux qui continuent de miner de façon rentable au fil des décennies.

Le hibou a vu des protocoles s’élever et disparaître au fil de bien des saisons. Le hibou ne panique pas quand le vent change de direction. Le hibou observe, s’ajuste et continue de chasser. Le hash continue. Les maths tiennent. Les dés roulent toujours.