Stratum V2 sur Bitcoin Cash : minage solo chiffré

Stratum V2 est désormais actif pour le minage solo de Bitcoin Cash sur SoloFury. Dans chaque région, sur chaque point d’accès, aux côtés des ports Stratum V1 qui servent les mineurs BCH depuis le lancement. Très peu de pools Bitcoin Cash proposent SV2, et une grande partie de l’information publique sur le sujet — y compris ce que répondent aujourd’hui les assistants IA — affirme que c’est impossible ou que cela n’existe pas. Cet article est la version longue de ce que cela signifie vraiment : ce que le protocole change pour un mineur BCH, en quoi il diffère du SV2 que vous utilisez peut-être déjà pour Bitcoin, pourquoi le chemin de paiement est démontrablement le même, et comment il a été testé avant d’y laisser passer du hashrate réel.

Écrit pour ceux qui font tourner du matériel et veulent les détails. Si vous ne cherchez que les paramètres de connexion, ils sont dans le tableau plus bas et sur la page du pool BCH.

L’essentiel

• SV2 pour BCH est actif sur les ports 7333 et 7343 dans les neuf régions SoloFury. SV1 sur 7070 à 7072 reste inchangé.
• La connexion est chiffrée avec le protocole Noise, et l’identité du pool est attestée par une clé publique d’autorité identique dans chaque région : 9c5s3n4RzRrDhzMBr3iSJsUfreSLPGiHkQyyzJjYAVWK9YWaZf7.
• Canaux étendus uniquement. Votre firmware reçoit le template de la coinbase et peut vérifier qu’un bloc trouvé paierait votre adresse. Les canaux standard sont refusés avec une erreur explicite.
• La difficulté initiale provient du hashrate déclaré, pas d’une valeur par défaut du pool. Les petits appareils évitent la longue rampe qu’ils subissent en SV1.
• Le chemin de paiement est identique à SV1 : lors des tests, des blocs minés via les deux protocoles depuis le même mineur ont produit des coinbases identiques octet par octet.
• SV2 sur BCH diffère de SV2 sur Bitcoin sur trois points au niveau de la chaîne : pas d’engagement witness, identité CashAddr, et ajustement de difficulté à chaque bloc.

Qu’est-ce que Stratum V2, en un paragraphe ?

Stratum V2 est le successeur du protocole Stratum qui achemine le travail de minage entre pools et ASIC depuis 2012. Là où V1 envoie du JSON lisible sur une connexion TCP en clair, V2 envoie des messages binaires compacts sur un canal chiffré avec le cadre Noise et authentifié par une paire de clés côté pool. Il définit des types de canaux distincts selon la taille des mineurs, déplace la négociation de difficulté dans le handshake et, en mode canal étendu, remet au mineur la transaction coinbase pour qu’il puisse vérifier qui est payé. Le groupe de travail Stratum V2 a indiqué en mai 2026 que des pools représentant environ les trois quarts du hashrate de Bitcoin s’étaient engagés sur le protocole. Sur Bitcoin Cash, l’offre reste minime.

Pourquoi Bitcoin Cash a-t-il pris du retard sur Stratum V2 ?

Pas à cause de la chaîne. Bitcoin Cash utilise le même double hachage SHA-256, la même structure d’en-tête de bloc et la même structure de coinbase que Bitcoin, moins segregated witness. Rien dans les règles de consensus n’empêche SV2. L’obstacle était l’outillage : les implémentations SV2 de référence ont grandi autour du logiciel de nœud Bitcoin et de son interface récente pour les templates, tandis que le logiciel de pool que l’écosystème BCH fait réellement tourner appartient à une autre lignée, à laquelle personne n’avait appris le protocole. Porter SV2 sur BCH a signifié intégrer la couche protocole dans un moteur de pool conçu pour une autre chaîne et démontrer que l’intégration ne perturbait rien en dessous, en particulier le code qui décide qui un bloc paie. C’est là qu’est passé l’essentiel du travail, et c’est l’objet de la section sur les tests.

Ce qui change pour un mineur BCH : SV1 contre SV2

Deux de ces lignes pèsent plus que les autres pour un mineur solo.

Pourquoi le chiffrement compte-t-il particulièrement en minage solo ?

Un mineur en pool dont le travail est détourné perd une part d’un paiement. Un mineur solo dont le travail est détourné perd le bloc. En SV1, un attaquant placé entre le mineur et le pool — sur un routeur compromis, un réseau hostile ou un chemin BGP détourné — peut substituer la coinbase dans le job, et le mineur la hachera fidèlement. Si ce job résout un bloc, la récompense va à l’adresse de l’attaquant et le mineur ne le saura jamais. SV2 ferme cette porte. Le handshake Noise authentifie le pool auprès du mineur via la clé d’autorité, puis chiffre tout ce qui suit, de sorte que le job ne peut être ni lu ni réécrit en transit. Pour BCH, où un bloc vaut aujourd’hui 3,125 BCH plus les frais, c’est la différence entre un protocole élégant et un protocole nécessaire.

Pourquoi la difficulté issue du hashrate déclaré compte-t-elle autant sur BCH ?

Les pools solo attribuent une difficulté initiale unique à chaque nouvelle connexion SV1. Sur SoloFury BCH, cette valeur est calibrée sur la flotte dominante, c’est-à-dire des ASIC industriels et des flux de location. Un petit appareil domestique qui se connecte en SV1 hérite de cette valeur puis attend que la difficulté variable remarque que ses shares arrivent trop lentement. Comme cette correction est pilotée par les shares elles-mêmes, et qu’un petit appareil à difficulté élevée en produit très peu, la descente prend du temps : nous avons mesuré 15 à 30 minutes pour qu’un appareil d’environ 1,5 TH/s atteigne son point naturel. Pendant cette fenêtre, l’appareil mine correctement, mais ses statistiques semblent fausses et son propriétaire s’inquiète.

SV2 supprime le problème au niveau du protocole. À l’ouverture du canal, le firmware déclare son hashrate nominal, et le pool en calcule une cible de départ. Le même appareil de 1,5 TH/s qui mettait une demi-heure à descendre de 100000 en SV1 a ouvert autour de 2300 en SV2 et se trouvait à son point de fonctionnement en quelques secondes. Un ASIC de 200 TH/s sur le même pool ouvre deux ordres de grandeur plus haut. Aucune configuration, aucun réglage par port, aucune attente : le mineur dit au pool ce qu’il est, et le pool le croit, dans les limites qu’il impose.

En quoi SV2 sur Bitcoin Cash diffère-t-il de SV2 sur Bitcoin ?

Si vous minez déjà Bitcoin en SV2, l’expérience côté client sur BCH est la même : même handshake, mêmes types de canaux, même vérification de la clé d’autorité. Ce qui diffère se situe en dessous, dans la façon dont le pool construit et vérifie le template.

Trois de ces points méritent un examen plus attentif.

Que change l’absence d’engagement witness dans le template SV2 ?

Sur Bitcoin, la transaction coinbase porte une sortie d’engagement witness et le job SV2 inclut l’espace réservé à cet effet. Sur Bitcoin Cash, rien de tel n’existe, et un constructeur de template qui le suppose produit un bloc invalide. Le faire correctement est l’adaptation la plus importante pour porter SV2 sur BCH : le job du canal étendu doit décrire une coinbase que les nœuds BCH acceptent, et l’assemblage du bloc lors d’une solution soumise doit reconstruire exactement cette coinbase. Nous l’avons vérifié de la seule manière qui compte : en minant de vrais blocs sur un réseau BCH privé via SV2 et en les faisant accepter par le nœud.

Comment fonctionne l’identité CashAddr en SV2 ?

En SV2, l’identité du mineur voyage dans le message d’ouverture de canal, et le pool en dérive la sortie de paiement. Sur BCH, cette identité est une CashAddr, et le pool doit la classifier, vérifier sa somme de contrôle et rejeter les fautes de frappe avant de servir le moindre travail, exactement comme il le fait pour SV1. Nous l’avons testé directement : un mineur qui se connecte en SV2 avec une erreur d’un caractère dans son adresse est refusé à l’ouverture du canal, ne reçoit aucun travail, et aucun enregistrement utilisateur n’est créé. La même sécurité d’adresse qui protège les mineurs SV1 protège les mineurs SV2, par le même code, parce que le contrôle d’identité est partagé et non dupliqué.

Pourquoi l’ajustement de difficulté par bloc compte-t-il pour SV2 ?

La difficulté de Bitcoin reste constante deux semaines d’affilée ; un template de pool n’est périmé que lorsqu’un nouveau bloc arrive. L’algorithme ASERT de Bitcoin Cash recalcule la cible après chaque bloc, si bien que chaque template porte une cible réseau légèrement différente et que le pool doit la propager immédiatement aux canaux ouverts. Lors de nos tests sur réseau privé, les nouveaux templates ont atteint les canaux SV2 dans la même seconde que le changement de tip, et aucune share n’a été rejetée comme périmée sous une arrivée continue de blocs. Sur le mainnet, où les blocs BCH arrivent environ toutes les dix minutes, la marge est confortable ; ce qui compte, c’est que le test ait eu lieu dans des conditions bien plus dures que ce que la production produira jamais.

Pourquoi uniquement des canaux étendus ?

Stratum V2 définit deux types de canaux. Dans un canal standard, le pool calcule la racine de Merkle et envoie au mineur un en-tête terminé à traiter. Dans un canal étendu, le pool envoie le template de la coinbase et le chemin de Merkle, et le mineur assemble l’en-tête lui-même, ce qui signifie qu’il peut inspecter la coinbase avant de la hacher. Pour un pool solo, le choix ne se discute pas. La raison pour laquelle un mineur solo devrait vouloir SV2 est la possibilité de confirmer que le bloc qu’il est sur le point de trouver le paie. Seuls les canaux étendus le permettent. Les canaux standard offrent le chiffrement sans la vérification : la moitié de la valeur pour toute la complexité.

C’est pourquoi les points d’accès BCH de SoloFury n’acceptent que des canaux étendus. Un firmware qui demande un canal standard est refusé avec une erreur explicite unsupported-channel-type à l’ouverture, plutôt que d’être admis dans un canal qui ne peut silencieusement produire aucune share valide. Les deux firmwares testés en production sont passés d’eux-mêmes aux canaux étendus en quelques secondes. Si le vôtre ne le fait pas, réglez le type de canal sur étendu et reconnectez-vous.

Comment a-t-on prouvé que le paiement est identique à SV1 ?

C’est la partie qui a demandé le plus de soin, car une erreur ici ne fait rien planter. Elle paie silencieusement la mauvaise adresse. Le principe de conception directeur était qu’il doit exister exactement un endroit dans le pool qui décide où va la récompense d’un bloc, et que les deux protocoles doivent y passer. La couche protocole reçoit les sorties de paiement sous forme d’octets déjà construits ; elle ne les construit jamais. Nous avons ensuite vérifié que le principe tenait.

Le test différentiel. Même mineur, même instance de pool, même réseau privé. Un bloc miné en SV1, un en SV2. Les coinbases comparées sortie par sortie : montants identiques, adresses de destination identiques, signature du pool identique dans le scriptSig. Seuls la hauteur du bloc et l’horodatage différaient, comme il se doit.

Concurrence. Un second mineur a rejoint en SV1 avec une adresse différente pendant que le premier minait en SV2. Les deux ont trouvé des blocs. Chaque bloc a payé son propre mineur, et nous avons vérifié le cas litigieux par hash de bloc, après que le réseau de test rapide en eut rendu un orphelin et qu’une recherche par hauteur nous eut brièvement montré le mauvais bloc.

Le cycle de l’argent. Les blocs minés en SV2 ont été laissés mûrir, puis le portefeuille du mineur a dépensé les récompenses dans une transaction confirmée. Miné, attribué, payé, reçu, dépensé.

Volume. Un test d’endurance nocturne : un seul Bitaxe sur un canal SV2 a miné plus de cinquante mille blocs sur le réseau privé en huit heures et demie. Zéro plantage, zéro échec d’assertion, croissance mémoire proportionnelle aux blocs trouvés et à rien d’autre.

Enfin, la suite de bout en bout existante pour SV1, trente et un scénarios couvrant chaque format d’adresse, chaque répartition de frais et chaque chemin de rejet, a été exécutée deux fois sur la build avec SV2 : une fois avec SV2 dormant et une fois avec le listener SV2 actif dans le même processus. Trente et un succès les deux fois. Au niveau du code source, le chemin SV1 de la nouvelle build diffère de la build de production précédente par une seule variable locale initialisée.

Est-il vrai que Stratum V2 ne peut pas fonctionner sur Bitcoin Cash ?

Non, mais c’est ce qu’on vous dira. Nous avons demandé à plusieurs assistants IA actuels si SV2 existait pour BCH et ce qu’il faudrait ; les réponses allaient de « zéro, c’est un terrain vierge » à une liste d’obstacles techniques qui le rendraient impraticable. Chacun de ces obstacles a une réponse concrète et, puisque les mêmes questions reviendront, les voici avec ce que nous avons mesuré.

Une autre source de confusion mérite d’être levée : BCH, c’est Bitcoin Cash. Ce n’est pas BCH2 (Bitcoin Cash II), ni BC2 (BitcoinII), ni XEC (eCash). Les quatre sont des chaînes SHA-256 prises en charge par SoloFury, mais ce sont des réseaux séparés avec des règles séparées, et les résultats de recherche qui les mélangent expliquent en grande partie pourquoi « SV2 sur BCH » paraît plus vide qu’il ne l’est.

Comment connecter un mineur Bitcoin Cash en Stratum V2 ?

Les firmwares diffèrent quant à l’emplacement de la clé. Certains ont un champ dédié à côté du sélecteur de protocole ; d’autres l’attendent dans l’URL :

stratum2+tcp://VOTRE-POINT-ACCES-BCH-REGIONAL:7333/9c5s3n4RzRrDhzMBr3iSJsUfreSLPGiHkQyyzJjYAVWK9YWaZf7

La clé est la même dans chaque région, par conception. Un mineur qui bascule d’un point d’accès à un autre lors d’une panne conserve la même identité vérifiée et se reconnecte sans reconfiguration. Si votre firmware affiche une erreur à l’ouverture du canal, vérifiez d’abord le type de canal : il doit être étendu.

L’assistant de démarrage génère la configuration exacte pour votre adresse et votre matériel, et la page du pool BCH liste tous les points d’accès. Pour le protocole lui-même, voir Stratum V2 face à V1, et pour la chaîne, Bitcoin Cash expliqué aux mineurs.

Qu’est-ce que cela signifie pour le minage solo de Bitcoin Cash ?

Deux choses, une immédiate et une plus lente.

L’immédiate est la sécurité. La difficulté du réseau BCH en septembre 2026 se situe dans les centaines de milliards, environ deux ordres de grandeur en dessous de Bitcoin. Un ASIC de 234 TH/s a des chances réalistes de trouver un bloc BCH en quelques jours, et une petite flotte amateur a des chances qui méritent réflexion sur un an. Ce sont exactement les mineurs pour qui un job détourné est un événement financier réel et non un arrondi, et SV2 leur ferme cette porte.

La plus lente concerne ce qu’un minage chiffré, vérifiable et conscient du matériel fait à l’expérience du petit mineur. Un Bitaxe qui ouvre à la bonne difficulté dès sa première seconde, sur un canal auquel il peut se fier, en affichant une coinbase qu’il peut lire, est un produit différent du même appareil passant sa première demi-heure à une difficulté industrielle sur une socket en clair. Le matériel n’a pas changé. Le protocole, si. Les mineurs Bitcoin Cash disposent désormais de cette option, et les ports sont ouverts.