Confirmer que l'adresse Public Pool est en ligne ne se résume pas à vérifier si la page web s'affiche. Il faut valider côté nœud. L'affichage "Worker Active" sur le frontend signifie simplement que le serveur de la pool déclare avoir reçu des soumissions de parts (shares) depuis cette adresse — mais il s'agit de statistiques que le navigateur récupère depuis le serveur ; vous ne pouvez pas vérifier l'authenticité de cette déclaration depuis le navigateur lui-même. La véritable poignée de main Stratum V1 s'effectue entre votre mineur TCH et stratum+tcp://public-pool.io:3333 (ou le port correspondant au mode choisi), le frontend ne participant pas à ce processus.
1、Vérification légère : Connexion via votre adresse BTC sur Public Pool
L'essence de la vérification légère est une confirmation rapide de l'état applicatif. Lorsque vous saisissez votre adresse BTC dans le frontend de Public Pool.io, celui-ci récupère les statistiques associées à cette adresse depuis le serveur de la pool. La véritable poignée de main Stratum V1 s'opère entre votre mineur et le service Stratum de public-pool.io — le mineur initie activement la connexion, s'abonne aux tâches et soumet les parts (shares).
Une erreur courante consiste à ne vérifier que le chargement de la page web, négligeant la connectivité des ports TCP sous-jacents, ce qui peut mener à des heures de fonctionnement à vide du mineur sans que vous ne vous en rendiez compte.
Selon les informations d'accès fournies par Public Pool, les paramètres de connexion pour chaque mode sont les suivants :
| Mode de minage | Adresse de connexion | Port | Type de protocole |
|---|---|---|---|
| Mode Solo | stratum+tcp://public-pool.io | 3333 | TCP |
| Solo + Chiffrement TLS | stratum+tls://public-pool.io | 4333 | TLS Chiffré |
| Mode PPLNS | stratum+tcp://public-pool.io | 13333 | TCP |
| PPLNS + TLS | stratum+tls://public-pool.io | 14333 | TLS Chiffré |
📌 Petit conseil : L'ancien port non chiffré de Public Pool était le 21496. L'officiel a depuis migré vers le port 3333. Les deux ports ont coexisté un temps. Utilisez désormais le 3333/13333 comme référence.
- Nom d'utilisateur = Votre adresse BTC : Public Pool accepte les adresses BTC standards comme nom d'utilisateur. Selon les tests communautaires et logiciels de minage, les adresses Bech32 (SegWit v0) commençant par
bc1qoffrent la meilleure compatibilité ; les adresses Taproot commençant parbc1ppeuvent poser des problèmes de parsing sur certains anciens firmwares (comme les premières versions de Nerd Miner). Il est recommandé d'utiliser le firmware le plus récent. Les adresses P2PKH (commençant par1) et P2SH (commençant par3) fonctionnent également. - Champ mot de passe libre : Remplissez le champ mot de passe Stratum avec
xou123. Il s'agit d'un simple placeholder de protocole, sans impact sur la vérification. - Suffixe Worker optionnel : Vous pouvez utiliser
.nomdumineurpour distinguer plusieurs appareils, facilitant leur identification en cas de flotte multiple. Si omis, le nom par défaut est "default".
⚠️ L'affichage "Worker Active" sur le frontend ne prouve pas à lui seul que les récompenses de bloc vous seront attribuées — si l'adresse saisie dans la configuration du mineur comporte une faute de frappe, la pool refusera généralement la connexion (aucune donnée frontend). Mais dans des cas extrêmement rares (si la chaîne erronée passe accidentellement la somme de contrôle Bech32, probabilité d'environ un sur neuf mille milliards), les parts seront enregistrées silencieusement sous une adresse valide qui n'est pas la vôtre. Le frontend affichera toujours "Worker Active", et toute récompense de bloc sera perdue définitivement.
2、Vérification indépendante : Consultation des logs Public-Pool via SSH sur le nœud
Le cœur de la vérification indépendante réside dans l'observation directe de l'état d'exécution du service public-pool sur votre propre nœud. En vous connectant en SSH et en exécutant docker logs, vous accédez aux logs bruts du conteneur — ceux-ci confirment si le service Stratum écoute correctement, si votre mineur s'est réellement connecté, et si le Bitcoin Core sous-jacent est synchronisé et capable de fournir des getblocktemplate.
Prérequis :
- Le Bitcoin Core sous-jacent doit être entièrement synchronisé (
verificationprogressproche de 1.0). - Le conteneur public-pool doit être dans l'état "Up".
1、🔥 Établissez la connexion avec ssh umbrel@IP_Locale_de_votre_nœud.
2、➡️ Exécutez sudo docker ps | grep public-pool pour confirmer que l'état du conteneur est "Up".
3、🏃 Saisissez sudo docker logs ID_du_conteneur --tail 200 pour limiter la sortie aux 200 dernières lignes et éviter une surcharge d'informations.
4、❓ Filtrez les informations clés avec grep, en recherchant prioritairement deux types de lignes :
Stratum server is listening on port 3333— prouve que le service Stratum est opérationnel ;New client ID: xxx, ip:xxx— prouve que votre mineur s'est bien connecté.
Si votre instance public-pool utilise votre propre adresse BTC comme nom d'utilisateur pour recevoir les tâches, l'adresse bc1 complète ne sera pas forcément affichée explicitement dans les lignes de log concernant les modèles de blocs (block templates) ; ce qui peut être confirmé de manière certaine est : "votre client est connecté + le service Stratum fonctionne + Bitcoin Core est synchronisé et peut générer de nouveaux modèles de blocs". En fin de compte, la correction de l'adresse de récompense dépend essentiellement de l'exactitude de l'adresse BTC (nom d'utilisateur) saisie dans la configuration du mineur et de sa propriété réelle — vérifiez cela directement côté portefeuille.
Vérification de l'état de synchronisation :
Avant de consulter les logs, exécutez impérativement sudo docker exec bitcoind bitcoin-cli getblockchaininfo et vérifiez que verificationprogress est proche de 1.0. Si le nœud complet sous-jacent est encore en cours de synchronisation, public-pool ne pourra pas appeler l'interface RPC getblocktemplate pour générer de nouvelles unités de travail, ce qui se traduira par un comportement où le mineur semble connecté mais ne parvient jamais à soumettre de parts valides.
3、Relation entre les deux niveaux de vérification
Ces deux niveaux de vérification constituent une chaîne de compréhension complète, allant du phénomène à l'essence. La vérification légère capture l'état de connexion applicatif, tandis que la vérification indépendante touche à la réalité de l'état d'exécution du nœud. La première dépend de l'honnêteté des données du fournisseur de la pool, la seconde repose sur votre contrôle total de votre propre nœud. Pour les mineurs exigeant une certitude absolue, la seconde élimine toute dépendance de confiance envers des sources de données tierces.
| Dimensions de comparaison | Vérification légère (Connexion frontend) | Vérification indépendante (Logs du nœud) |
|---|---|---|
| Objet de vérification | Statistiques de parts enregistrées par le serveur de la pool | État d'exécution du conteneur public-pool + connexion client + état de synchronisation de la chaîne |
| Permissions requises | Accès en lecture seule via navigateur | Droits SSH root sur le nœud |
| Résistance à la tromperie | Faible (Les données serveur peuvent être falsifiées) | Élevée (Basée sur le contrôle total de votre machine locale) |
| Temps typique | Moins de 30 secondes | 5 à 10 minutes |
Pourquoi cette architecture en couches est-elle si importante ?
Dans les réseaux TCP/IP, le protocole Stratum (en texte clair ou chiffré TLS) présente un risque théorique d'interception par un attaquant de l'homme du milieu (MITM). Un attaquant pourrait intercepter vos requêtes au niveau de la couche transport, renvoyer une réponse "Accepted" falsifiée, tout en redirigeant votre puissance de calcul vers l'adresse d'autrui. Confirmer via une vérification indépendante que votre service Stratum fonctionne normalement sur votre nœud et que votre mineur y est bien connecté réduit considérablement votre exposition à ce risque.
Comme les mineurs standard Stratum V1 ne peuvent pas vérifier automatiquement l'adresse de sortie de la coinbase, il convient de s'appuyer sur la confiance accordée au code open-source de Public Pool. Pour éliminer totalement toute altération par un MITM, assurez-vous que votre mineur (conçu par TinyChipHub, Zyber Blanc OC) et votre nœud résident sur le même réseau local, ou utilisez les ports chiffrés TLS (4333/14333). Par ailleurs, vérifiez méticuleusement caractère par caractère l'adresse de portefeuille dans la configuration du mineur pour éviter toute erreur de saisie.
D'un point de vue ingénierie, les deux niveaux de vérification résolvent également le problème de "l'incohérence asynchrone". En raison des latences de propagation des blocs sur le réseau Bitcoin, les informations statistiques affichées sur le frontend de la pool peuvent être en retard de plusieurs blocs par rapport à l'état réel du nœud. Normalement, chaque fois qu'un nouveau bloc apparaît sur le réseau ou que le mempool subit des changements significatifs, un nouveau modèle de bloc (block template) est généré. Si vous constatez une fréquence anormalement élevée de mise à jour des modèles de blocs, cela peut indiquer que votre nœud traverse une réorganisation de chaîne, ou que l'activité des transactions dans le mempool a fortement augmenté.
4、Quelques pièges fréquents
Dans l'univers du minage Bitcoin, le diable se cache souvent dans les détails binaires. Voici les pièges les plus fréquents identifiés par le studio TinyChipHub et de nombreux mineurs domestiques en Amérique du Nord et en Europe lors d'échanges communautaires. Chaque point est issu d'un cas réel de dysfonctionnement.
- 💣 Piège de compatibilité des formats d'adresse : Bien que Public Pool prenne en charge tous les types d'adresses standards, les adresses Taproot commençant par
bc1ppeuvent rencontrer des problèmes de compatibilité de parsing sur certains anciens logiciels de minage (comme les premiers firmwares de Nerd Miner). Il est recommandé d'utiliser les logiciels de minage officiels les plus récents et de s'assurer que le firmware est à jour ; privilégiez l'usage debc1qlors de la configuration initiale. - 💣 Conflit d'occupation de port : Vérifiez si le port est déjà utilisé par un autre processus (
sudo lsof -i :3333), ce qui empêcherait le service Stratum de démarrer. Les logs afficheraient alors l'erreur récurrente bind: address already in use. La solution consiste à modifier le mappage des ports dans le fichier docker-compose.yml ou à ajuster la configuration des services cachés Tor pour libérer le port. - 💣 Interception par pare-feu : En cas d'impossibilité de connexion, vérifiez les paramètres du pare-feu local ou de votre routeur. Pour une instance publique, utilisez les ports 4333 (TLS) ou 14333 (PPLNS TLS) pour contourner d'éventuels blocages par l'opérateur ; s'il s'agit d'un problème de pare-feu sur l'Umbrel local, ouvrez le port avec
sudo ufw allow 3333. - 💣 Dérive de l'horloge système : L'heure système doit être synchronisée via NTP. Bitcoin Core tolère un décalage maximal de 4200 secondes, mais un écart trop important perturbe gravement les connexions pair-à-pair ; il est conseillé de maintenir l'écart à quelques secondes près. Cela empêcherait la pool de générer de nouvelles unités de travail, le mineur affichant un "statut connecté" mais étant incapable de soumettre des parts valides.
🔥 Le piège le plus critique : Le phénomène du mineur fantôme.
Lorsque l'adresse BTC saisie dans la configuration du mineur contient une erreur, le résultat dépend de la somme de contrôle Bech32 et se divise en deux cas :
Dans la grande majorité des cas, une faute de frappe aléatoire corrompt la somme de contrôle Bech32, produisant une adresse invalide. La pool rejettera alors l'abonnement ou fermera la connexion face à ce nom d'utilisateur invalide, et les parts ne seront pas enregistrées — vous remarquerez rapidement l'absence de statistiques sur le frontend, signalant une erreur de configuration.
Dans des cas extrêmes, la chaîne erronée correspond par hasard à une adresse valide selon la somme de contrôle (probabilité d'environ un sur neuf mille milliards). Dans ce scénario, la pool acceptera normalement les parts et les enregistrera sous cette adresse étrangère, le frontend affichant comme prévu "Worker Active". Si cet appareil trouve un bloc, la récompense sera envoyée à cette adresse qui ne vous appartient pas, les fonds seront perdus définitivement, car le réseau Bitcoin ne dispose d'aucun mécanisme de "récupération".
Meilleure pratique : Après configuration, vérifiez méticuleusement caractère par caractère la propriété de l'adresse côté portefeuille. Observez ensuite si les statistiques de parts apparaissent dans un délai raisonnable sur le frontend comme validation croisée. Mais notez bien qu'"avoir des données sur le frontend" ne prouve que l'acceptation de votre connexion par la pool, pas que les récompenses vous reviendront — la certitude finale repose sur votre vérification minutieuse de la chaîne de caractères de l'adresse dans la configuration du mineur.
