Solo Mining Bitcoin en 2026 : Config Node & Rentrée de Bloc

En 2026, la commu du mining fait face à des maths impitoyables. Le hashrate global de Bitcoin vient de péter un record historique en franchissant la barre des 1 exahash (1024 EH/s). La difficulté tourne autour des 139T. Autant dire que choper un bloc en solo à la maison est devenu statistiquement impossible. Pourtant, des mecs tombent dessus. Régulièrement.

Le mining reste un processus de Poisson. Un pur hasard informatique. Le réseau n'a aucune mémoire des tentatives passées. Chaque hash généré a exactement la même probabilité de valider le bloc. Ça vaut pour un datacenter géant au Texas comme pour un vieil asic qui tourne au fond d'un garage. Une loterie, mais avec des règles immuables.

Chroniques d'une moule de cocu : Les braquages de 2026

La théorie, c'est bien, mais les faits parlent d'eux-mêmes. L'année a déjà cumulé une sacrée série d'upstreaks totalement lunaires pour des solo miners.

• Le coup de la loc (Février 2026) : Un mineur anonyme lâche à peine 119 000 satoshis (environ 75 $) sur NiceHash pour louer 1 PH/s de puissance. Il pointe son hash vers un solo pool. Résultat : bloc 938 092 validé. Le type repart avec plus de 200 000 $ net en poche. Rentabilité multipliée par des milliers. Une pure fluctuation statistique.
• L'exploit de l'ancêtre (Avril 2026) : Un solo miner avec seulement 70 TH/s au compteur décroche le bloc 944 306 via eusolo.ckpool.org. C'est la puissance d'un simple Antminer S17+ sorti en 2019. La bécane tournait avec une proba d'une chance sur 100 000 par jour. L'espérance mathématique était de 300 ans. Le gars a plié l'affaire en quelques mois.
• Hold-up à 230 TH/s (Début avril 2026) : Le bloc 943 411 tombe pour un mineur isolé sur Antminer S21. Il avait une chance sur 28 000 par jour. Il encaisse 3.139 BTC après déduction des frais de mempool.

Sur les 12 derniers mois, les solo miners ont arraché plus de 20 blocs au réseau. Les stats de Bennet confirment la tendance : les indépendants braquent le jackpot en moyenne tous les 18 jours.

Analyse des stratégies en solo mining

Infra du solo miner : Monter son mini-node

Pour éviter de dépendre de pools tiers et viser la souveraineté totale, il faut faire tourner son propre node. Un serveur Stratum maison.

On part sur un mini-PC équipé d'un Intel N100 ou un serveur d'occasion. La condition sine qua non, c'est un SSD NVMe rapide d'au moins 2 To. Sur un vieux HDD, la synchro va sauter à cause des timeouts d'écriture. Le réseau n'attend pas les traînards.

Étape 1. Config de bitcoin.conf

Le fichier bitcoin.conf doit être aux petits oignons. La moindre erreur de config va provoquer des rejets de parts en cascade (stale shares).

# Mode démon
daemon=1
# Serveur RPC actif pour requêtes externes
server=1
# Allocation RAM pour le cache de la chaîne (min 4 Go)
dbcache=4096
# Indexation complète des transactions pour getblocktemplate
txindex=1
# Connexions restreintes au localhost ou proxy
rpcbind=127.0.0.1
rpcallowip=127.0.0.1
# Auth RPC, pas de mdp bidon
rpcuser=core_operator
rpcpassword=X9_f28_Klsda__m192

Étape 2. Build du proxy Stratum V2 en Rust

Les ASICs ne savent pas causer directement avec les commandes RPC de Bitcoin Core. Il leur faut le protocole Stratum. En 2026, tourner encore sur Stratum V1 est une hérésie : ça gaspille de la bande passante et fait grimper le ping. On compile le proxy officiel en Rust.

Commandes de build et d'exécution dans le terminal Linux :

# Maj des paquets
sudo apt update && sudo apt upgrade -y
# Setup du compilateur Rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
source $HOME/.cargo/env
# Clone du dépôt du proxy
git clone https://github.com/stratum-mining/stratum-v2-proxy.git
cd stratum-v2-proxy
# Build du binaire de prod optimisé
cargo build --release

On crée le fichier de configuration config.toml dans le même dossier que le binaire :

[node]
rpc_url = "http://127.0.0.1:8332"
rpc_user = "core_operator"
rpc_pass = "X9_f28_Klsda__m192"
[proxy]
listen_address = "0.0.0.0:3333"
# Rafraîchissement du template de bloc en ms (au plus court, au mieux)
block_poll_interval_ms = 200

Y a plus qu'à lancer le démon : ./target/release/stratum-v2-proxy --config config.toml. Le port 3333 est maintenant à l'écoute de l'ASIC.

Script d'automatisation et de monitoring du node

Un mineur doit checker l'état de son node à la seconde près. Voici un script Python 3 de prod prêt à l'emploi. Il surveille l'accès RPC, le ping blockchain et le temps de réponse de getblocktemplate.

import http.client
import json
import time
import sys
class NodeMonitor:
    def __init__(self, host, port, user, passwd):
        self.host = host
        self.port = port
        # Encodage direct des id en Basic Auth
        import base64
        auth_str = f"{user}:{passwd}"
        self.auth_header = base64.b64encode(auth_str.encode()).decode()
    def send_rpc(self, method, params=[]):
        payload = json.dumps({"jsonrpc": "2.0", "id": "monitor", "method": method, "params": params})
        headers = {"Authorization": f"Basic {self.auth_header}", "Content-Type": "application/json"}
        
        start_time = time.perf_counter()
        try:
            conn = http.client.HTTPConnection(self.host, self.port, timeout=3)
            conn.request("POST", "/", payload, headers)
            res = conn.getresponse()
            data = res.read()
            conn.close()
            latency = (time.perf_counter() - start_time) * 1000
            return json.loads(data.decode()), latency
        except Exception:
            return None, 0
    def check_health(self):
        # Statut général du node
        blockchain_info, _ = self.send_rpc("getblockchaininfo")
        if not blockchain_info or "result" not in blockchain_info:
            print("CRITICAL: Node aux fraises ou RPC inaccessible.")
            sys.exit(1)
            
        # Vitesse de génération du template de bloc (la métrique reine en solo)
        template, latency = self.send_rpc("getblocktemplate", [{"rules": ["segwit"]}])
        if not template or "result" not in template:
            print("WARNING: Le node ne crache pas de template ! Risque de stale shares.")
            return
        blocks = blockchain_info["result"]["blocks"]
        headers = blockchain_info["result"]["headers"]
        
        print(f"[OK] Height: {blocks}/{headers} | Latency GBT: {latency:.2f}ms")
        
        # Si la latence dépasse 100ms, le disque est à la traîne
        if latency > 100:
            print("ALERT: Latence getblocktemplate critique ! Disque trop lent.")
if __name__ == "__main__":
    # Paramètres de connexion locale
    monitor = NodeMonitor("127.0.0.1", 8332, "core_operator", "X9_f28_Klsda__m192")
    # Boucle infinie, check toutes les 10 secondes
    while True:
        monitor.check_health()
        time.sleep(10)

Script écrit sans lib tierce, en Python pur. Aucun risque de crash lié à des dépendances pétées.

Anatomie de la stratégie NiceHash : L'achat de térahashs

Si l'idée de faire tourner un radiateur vrombissant de 3,5 kW chez toi ne t'enchante pas, il existe une alternative : la location. NiceHash est le plus gros courtier de puissance de calcul du marché. Tu n'achètes pas de matos, tu loues la puissance de calcul d'autres mineurs pour une durée bien précise.

Le principe est ultra simple. Des mineurs du monde entier louent leurs ASICs à NiceHash. Tu te connectes sur la plateforme, tu crées un ordre, et tu fixes le prix que tu es prêt à mettre pour un pack de puissance. Ensuite, tu diriges ce flux de hashs directement vers un pool qui prend en charge le minage solo.

C'est là que se trouve le principal piège pour les débutants. Si tu achètes de la puissance au hasard pour la balancer sur un pool classique, tu vas cramer ton dépôt. Ton seul but est de choper un bloc avant que les frais de location ne bouffent entièrement ton ordre.

**Configuration étape par étape d'un ordre pour chasser le bloc :**

• Choix du pool. Inscris-toi sur un pool solo comme Solo CKPool ou Poolin Solo. Pas besoin de node local ici. Le pool gère toute la partie technique et prend une commission de 1 % en cas de succès. Tu récupères ton adresse stratum dédiée (du style stratum+tcp://solo.ckpool.org:3333) et tu y colles ton adresse Bitcoin en guise de nom de worker.
• Choix de l'algorithme. Sur NiceHash, sélectionne l'algo SHA-256 (dédié au Bitcoin).
• Type d'ordre. Deux options s'offrent à toi. L'ordre Standard (moins cher, mais la puissance monte doucement) et l'ordre Fixed (plus cher, mais tu disposes d'un mur de hashrate instantanément). Les pros privilégient les ordres Fixed de courte durée. Tu loues par exemple 10 PH/s pendant 3 heures. Cela génère un pic de calcul massif. Les chances de valider un bloc sur ce créneau augmentent en flèche.
• Suivi. Garde un œil sur le tableau de bord du pool. Si l'ordre expire sans avoir trouvé de bloc, tu encaisses une perte nette. Ton capital est parti chez ceux qui louent leurs ASICs. Tu as simplement payé un ticket de loterie perdant.

Optimisation de la latence réseau : Des microsecondes à des milliers de dollars

Revenons à l'option hardware à la maison. Disons que tu as un ASIC dernier cri et un node parfaitement synchro. Pourtant, il y a une métrique que 99 % des amateurs zappent complètement : l'Orphan Block Rate (le taux de blocs orphelins).

Que se passe-t-il quand ton ASIC trouve une solution ? Le proxy la transmet au node, qui commence à propager ce bloc à ses peers (les nodes voisins sur le réseau). À la même milliseconde, dans un datacenter en Chine, un autre ASIC trouve une autre solution pour ce même bloc. La course est lancée. Le bloc qui se diffuse le plus vite et se fait valider par la majorité des nodes remporte les 3,125 BTC de récompense plus les frais de transaction. Si ton node est à la traîne, ton bloc devient « orphelin ». Tu le verras dans tes logs, tu seras content deux secondes, mais le réseau va le rejeter. Les sous iront au concurrent.

Pour éviter cette douche froide, ton node doit bénéficier d'une connectivité maximale. Oublie les configurations réseau par défaut.

Optimisation manuelle des peers pour accélérer la diffusion :

Ajoute les adresses IP des plus gros pools de minage comme peers permanents (addnode) dans ton bitcoin.conf. Tu dois leur pousser ton bloc directement, sans passer par des tonnes d'intermédiaires.

# Connexion forcée aux nodes des gros pools pour réduire la latence de propagation
addnode=172.65.216.111:8333  # Exemple d'IP de node d'un gros pool (Antpool/F2Pool)
addnode=104.20.55.90:8333    # Node d'un agrégateur de transactions
# Augmentation du nombre max de connexions sortantes
maxoutboundconnections=64

Un bon ping vers les nodes clés du réseau Bitcoin doit être inférieur à 20-30 millisecondes. Si ton fournisseur d'accès te donne un ping de 120 ms vers l'Europe ou les États-Unis, le minage solo sur node local est clairement à proscrire. Tes blocs arriveront systématiquement après la bataille.

Analyse des coûts : Loterie ou gouffre financier ?

Calculons la rentabilité du minage solo à la maison en 2026 avec un Antminer S21 (200 TH/s) sur le long terme, plutôt que de louer de la puissance.

• Consommation : 3500 W/heure.
• Par jour : 84 kWh.
• Par mois : 2520 kWh.

Multiplie ça par le tarif de ton électricité. Avec un kWh résidentiel autour de 0,06 $, tu lâches environ 150 $ par mois d'électricité. Ça fait 1800 $ à l'année, et 5400 $ sur trois ans. Pendant ce temps, l'espérance mathématique pour trouver un bloc avec cette puissance tourne autour de 7 à 9 ans.

En clair, brancher un seul ASIC en solo revient à payer une taxe régulière à ton fournisseur d'énergie pour une chance très hypothétique de décrocher le jackpot. D'un point de vue purement business, c'est absurde. Mais si on regarde les probabilités, chaque jour de fonctionnement t'offre une chance infime, mais bien réelle, de changer de vie. C'est un investissement basé sur la chance pure.