Faut-il un Pool pour le Solo Mining ?

On ne peut pas pointer un dispositif de minage sur un nœud Bitcoin et miner. Un ASIC parle Stratum, un nœud parle RPC, et quelque chose doit se trouver entre les deux pour construire des templates de blocs et distribuer le travail. Solo CKPool le dit sur sa propre page d’accueil. La vraie question n’est donc pas pool ou pas pool. C’est quel logiciel de pool, sur quel matériel, maintenu par qui.

Ce recadrage est important car il transforme une question de loyauté en une question technique. Voici les trois architectures réelles, ce que chacune apporte vraiment, et les modes d’échec que les guides de configuration mentionnent généralement en bas de page.

Points clés

• Il n’existe pas de configuration sans logiciel de pool. L’auto-hébergement signifie le gérer soi-même, pas s’en passer.
• Son propre nœud n’améliore pas les chances. Les chances ne dépendent que du hashrate et de la difficulté. Le self-hosting peut réduire les chances effectives via les temps d’arrêt et le travail périmé.
• Ce qu’il apporte c’est le contrôle du template — décider quelles transactions entrent dans le bloc. C’est quelque chose de réel et de significatif.
• Le travail périmé est le principal risque technique, et la documentation DATUM le signale explicitement : sans notifications rapides de nouveau bloc, le matériel hache pour rien.
• Les pools hébergés gèrent plusieurs points de terminaison géographiques avec basculement automatique. Le nœud domestique a un point de terminaison : la connexion internet domestique.
• DATUM est la voie médiane : ses propres templates, la comptabilité des partages par quelqu’un d’autre. Logiciel bêta, Linux uniquement, Bitcoin uniquement.

Pourquoi on ne peut pas miner directement sur un nœud

C’est la partie qui surprend les gens, et il vaut la peine d’être précis car tout le reste en découle.

Le travail d’un nœud Bitcoin est de valider et de relayer. Il expose une interface RPC, et l’un de ses appels est getblocktemplate, qui retourne un bloc candidat. Il ne distribue pas de travail aux mineurs, ne suit pas qui a soumis quoi, n’ajuste pas la difficulté par dispositif.

L’ASIC, lui, parle Stratum. Il s’attend à ce qu’un serveur lui envoie un job, lui indique la difficulté de partage, accepte ses soumissions et le notifie quand le job change.

Entre les deux se trouve un serveur stratum. Solo CKPool se décrit ainsi sur son propre site : pas un pool malgré le nom, mais un service qui existe parce qu’on ne peut pas miner directement sur un nœud Bitcoin Core. C’est la description précise de chaque option sur cette page, y compris celles qu’on gère chez soi.

Les trois architectures

Aucune de ces options n’est la « vraie » façon de miner en solo. Ce sont différentes distributions de contrôle et de responsabilité, et la bonne dépend de laquelle on veut davantage.

Ce que le self-hosting apporte vraiment

Si ce sont ces choses qu’on veut, le self-hosting est la bonne réponse et rien de ce qui suit ne devrait en dissuader.

Ce que ça coûte — d’après la documentation

Chaque élément ici provient des exigences propres aux projets ou du comportement dont ils avertissent, pas de la spéculation.

1. Le travail périmé est le vrai risque

Quand un nouveau bloc est trouvé n’importe où sur le réseau, chaque template construit sur le précédent devient instantanément inutile. Le serveur stratum doit l’apprendre en millisecondes et pousser du nouveau travail, sinon le matériel continue à hacher contre un job mort.

La documentation DATUM Gateway l’aborde directement, instruisant les opérateurs de configurer leur nœud pour envoyer des notifications de bloc au gateway. Une mauvaise configuration ne casse rien de visible : le tableau de bord montre un hashrate sain, les températures semblent correctes, et on ne produit rien.

2. Le basculement n’est pas gratuit

Solo CKPool gère des endpoints aux USA, en Europe, en Asie et en Océanie, sélectionne automatiquement celui à la latence la plus faible et bascule si cet endpoint tombe. Cette redondance est invisible quand elle fonctionne.

Le stack auto-hébergé a un seul endpoint. Si le nœud plante, l’alimentation vacille ou le FAI a une mauvaise heure, les mineurs n’ont nulle part où aller à moins d’avoir configuré un repli — et le seul repli sensé est un pool hébergé.

3. La machine est une vraie machine

Les exigences déclarées de DATUM Gateway sont : système Linux, nœud Bitcoin complet entièrement synchronisé (Knots recommandé), stockage rapide, connexion stable, CPU capable de valider les blocs entrants sans délai, et environ 1 Go de RAM en plus des besoins propres du nœud. En dessous se trouve un nœud complet : des centaines de gigaoctets de stockage et une synchronisation initiale mesurée en jours.

Rien de tout cela n’est exotique. C’est aussi un second appareil tournant en continu, consommant de l’électricité, nécessitant des mises à jour. Avec un mineur de 15 W et un nœud de 40 W pour le soutenir, le nœud est désormais la plus grande partie de la facture d’électricité.

4. Les erreurs de configuration sont silencieuses et coûteuses

Le setup DATUM nécessite de réserver de l’espace de bloc pour la transaction de génération, et sa documentation est explicite : sans cette réservation, le travail ne pourra pas intégrer une répartition de récompense. C’est une ligne de configuration dont l’absence se découvrirait au pire moment.

5. Logiciel bêta, plateforme étroite

DATUM Gateway en est à la v0.4.1bêta, ne supporte que Linux et uniquement Bitcoin. Ses propres notes de version indiquent que d’autres systèmes d’exploitation peuvent fonctionner mais à vos risques. C’est un étiquetage honnête du projet.

Pour les quatre chaînes SHA-256 au-delà de Bitcoin, DATUM n’est pas une option. Un stack entièrement auto-hébergé de style ckpool peut les servir, mais on gère alors un nœud par chaîne.

6. On est l’équipe des opérations

C’est ce que personne ne quantifie et que tout le monde finit par ressentir. La disponibilité d’un pool hébergé est le travail de quelqu’un. La disponibilité de son propre nœud est quelque chose dont on se souvient de vérifier, jusqu’à la semaine où on est en voyage.

L’arithmétique du temps de disponibilité

Les chances évoluent linéairement avec le temps passé à hacher sur du travail valide. Un dispositif hors ligne, ou travaillant sur un template périmé, n’achète rien pendant cette période. Le temps d’arrêt est donc une réduction directe en pourcentage du hashrate effectif.

Comme règle empirique c’est utile : si le self-hosting coûte plus d’un ou deux pourcent de disponibilité, les frais évités étaient l’option la moins chère.

Qui devrait auto-héberger

Ces options ne s’excluent pas mutuellement. Le setup domestique le plus robuste est généralement un mélange : primaire auto-hébergé où la souveraineté compte, repli hébergé configuré pour qu’un problème de nœud ne devienne pas du matériel mort. Chaque dispositif de la famille AxeOS supporte un hôte stratum de repli, et le configurer ne coûte rien.

Ce qui compte quoi qu’il arrive

Deux choses survivent à tout l’argument.

Celui qui construit le template décide ce que Bitcoin confirme. Si la décentralisation est la raison du solo mining, c’est le levier, et il est disponible via DATUM sans gérer soi-même l’ensemble du stack.

Celui qui détient la récompense décide si on l’obtient. Un bloc payé directement dans le coinbase à une adresse qu’on contrôle n’a besoin d’aucune demande, retrait ou confiance. C’est vrai d’un setup auto-hébergé comme d’un pool hébergé non-dépositaire. C’est pourquoi notre guide pour choisir un pool solo place le paiement non-dépositaire vérifiable en deuxième position.

Entre ces deux, la question de quelle machine gère le serveur stratum est une question d’opérations, pas de principes. Répondez-y avec l’évaluation honnête de votre propre disponibilité, pas avec celle que vous voudriez vraie.