Solo mining pour flottes hébergées : à quoi s'attendre

Ce guide s’adresse à deux types de lecteurs : les hébergeurs et gestionnaires de flottes qui exploitent les machines d’autrui et doivent décider s’ils proposent le solo mining, et comment, et les opérateurs de leurs propres flottes qui comparent le solo à un pool proportionnel. Les mineurs à domicile avec un ou deux appareils trouveront les mathématiques générales dans Mining Variance & Poisson Math ; ici, l’accent est mis sur les flottes, la trésorerie, les règles clients, le suivi et le choix entre Bitcoin et Bitcoin Cash.

La première moitié porte sur les chiffres : ce qu’une flotte doit attendre sur chaque chaîne et pourquoi la moyenne trompe. La seconde moitié, à partir de la section sur l’offre du solo aux clients, est opérationnelle : règles, tarification, suivi, le jour où un bloc arrive et trois profils de flotte chiffrés.

Points clés

• Le revenu attendu par térahash est presque le même sur BTC et BCH. Dans l’instantané ci-dessous, 1 PH/s valait environ 39,7 USD par jour sur BTC et 39,5 USD par jour sur BCH.
• La distribution, non. Un bloc BCH demande environ 269 fois moins de travail qu’un bloc BTC et vaut environ 269 fois moins, donc la même flotte trouve des blocs BCH environ 269 fois plus souvent.
• Le temps attendu est une moyenne, pas un calendrier. Après un temps attendu, il reste environ 37 % de probabilité de n’avoir aucun bloc ; après trois temps attendus, environ 5 %.
• Solo contre FPPS change le calendrier, pas la moyenne. La différence de revenu attendu est l’écart de commission : 1 % en solo contre des commissions FPPS situées entre environ 2 % et 4 % sur la plupart des grands pools.
• C’est la trésorerie qui fixe la taille de la part. Pour être sûre à 95 % d’obtenir au moins un bloc, une flotte doit pouvoir tenir environ trois temps attendus.
• Ce sont les shares acceptés, pas les blocs, qui prouvent que la flotte fonctionne. Des semaines sans bloc sont normales ; des semaines de shares acceptés en baisse ne le sont pas.
• Pour les hébergeurs, le problème des tickets se règle avant le basculement. Une attestation écrite et un tableau de bord affichant les blocs attendus à côté des blocs trouvés transforment un risque de support en produit.

L’instantané utilisé dans ce guide

Tous les chiffres qui suivent proviennent de cet instantané. Les données réseau changent chaque jour ; pour les valeurs actuelles, utilisez le calculateur en direct et le rapport mensuel des probabilités.

La difficulté est la donnée la plus importante, et elle est lue directement sur la chaîne. Les hashrates réseau publiés par les explorateurs sont des estimations tirées des temps de bloc, et les sources divergent de plusieurs pour cent ; le temps attendu de votre propre flotte n’en dépend pas.

La seule formule derrière tout le reste

Le temps attendu pour qu’une flotte trouve un bloc est :

Temps attendu = difficulté × 2³² ÷ votre hashrate

Deux détails comptent pour les flottes :

• Utilisez le hashrate effectif, pas le hashrate nominal. Les arrêts, les shares stale et la latence réseau réduisent le travail qui atteint réellement le pool. Une flotte avec 97 % d’uptime a 97 % de sa chance nominale, et son temps attendu est environ 3 % plus long.
• La difficulté et le hashrate réseau sont des mesures différentes. La difficulté est fixée par le protocole à partir des temps de bloc passés ; le hashrate réseau est une estimation du travail effectué en ce moment. Des chaînes utilisant le même algorithme peuvent avoir des difficultés très différentes, c’est précisément le cas de BTC et BCH.

Pour approfondir le modèle de probabilité, simulations comprises, voir Mining Variance & Poisson Math.

Même revenu attendu, distribution très différente

Voici 1 PH/s de hashrate effectif sur chaque chaîne, au moment de l’instantané :

Les deux revenus attendus sont à environ un demi pour cent l’un de l’autre. Ce n’est ni une coïncidence ni une loi : les mêmes machines SHA-256 peuvent miner l’une ou l’autre chaîne, et les opérateurs ont tendance à passer de l’une à l’autre jusqu’à ce que le revenu par hash s’égalise à peu près. Quand les prix ou la difficulté bougent, l’écart se rouvre pendant un temps.

Ce qui ne s’égalise pas, c’est la forme du revenu. Dans cet instantané, un bloc BTC demande environ 269 fois plus de travail qu’un bloc BCH et vaut environ 269 fois plus. Même moyenne, expérience opposée : sur BTC, une flotte de taille moyenne attend des années un paiement très important ; sur BCH, la même flotte en encaisse beaucoup de petits.

Ce qu’une flotte doit attendre

Le tableau montre le temps attendu par bloc, l’attente médiane, le délai dans lequel un bloc arrive dans 95 % des cas et la probabilité d’au moins un bloc en 30 jours et en un an.

Bitcoin (BTC), difficulté 132,76 T

Bitcoin Cash (BCH), difficulté 494,00 G

Deux lectures en découlent directement. Sur BTC, en dessous d’environ 50 PH/s, le solo reste un pari à long terme même pour une flotte professionnelle : à 10 PH/s, la probabilité de ne trouver aucun bloc en une année entière est encore d’environ 57 %. Sur BCH, à partir d’environ 1 PH/s, le solo cesse d’être une loterie et devient un revenu irrégulier.

Pourquoi la moyenne trompe

Le temps d’attente d’un bloc suit une distribution exponentielle, ce qui a des conséquences qui surprennent presque tout le monde la première fois.

La médiane est plus courte que la moyenne. La moitié des attentes se termine avant environ 0,69 fois le temps attendu. Quelques attentes très longues tirent la moyenne vers le haut.

Les longues périodes sèches sont normales. Voici la probabilité de ne toujours pas avoir de bloc après un multiple donné du temps attendu :

Une flotte de 1 PH/s sur BCH a un temps attendu de 24,6 jours. Passer 50 jours sans bloc, deux fois le temps attendu, arrive dans environ un cas sur sept. Ce n’est pas le signe que quelque chose ne va pas.

Le minage n’a pas de mémoire. Chaque hash est un essai indépendant. Après trois mois sans bloc, la probabilité d’en trouver un demain est exactement la même que le premier jour. Personne n’a jamais droit à un bloc, et une série chanceuse n’épuise pas la chance future.

Combien de blocs par mois : flottes sur BCH

Pour les flottes assez grandes pour trouver plusieurs blocs BCH par mois, la question utile devient l’ampleur des variations du nombre mensuel. Le nombre de blocs sur une période suit une loi de Poisson, dont la dispersion relative diminue quand le nombre attendu augmente.

À 1 PH/s, environ trois mois sur dix se terminent sans aucun bloc. À 10 PH/s, un mois à seulement sept blocs et un mois à dix-huit sont tous deux ordinaires. À 100 PH/s, le résultat mensuel reste à environ 15 % de la moyenne neuf mois sur dix.

La trésorerie : la vraie limite du solo

L’hébergement et l’électricité sont facturés chaque mois en monnaie fiduciaire. Les revenus du solo arrivent par à-coups. L’écart entre les deux est le risque pratique du solo pour une flotte, et il se dimensionne.

Règle pratique tirée de la distribution exponentielle : pour être sûre à 95 % d’obtenir au moins un bloc, une flotte doit pouvoir fonctionner pendant environ trois temps attendus sans revenu de la part solo. Pour 99 %, environ 4,6 temps attendus.

Deux exemples avec l’instantané :

• 1 PH/s sur BCH : temps attendu de 24,6 jours, donc environ 2,4 mois de réserve pour 95 % de certitude. Gérable pour la plupart des opérateurs.
• 10 PH/s sur BTC : temps attendu de 21,7 mois, donc environ 5,4 ans de réserve pour 95 % de certitude. Irréaliste comme plan de revenus ; seulement comme allocation délibérée à long terme.

Une illustration avec des hypothèses explicites : une flotte à 15 J/TH consomme environ 15 kW par PH/s, soit 360 kWh par jour. À 0,07 USD le kWh, cela fait environ 25 USD par jour, soit à peu près 770 USD par mois, par PH/s. Face aux quelque 39,5 USD de revenu attendu par jour dans l’instantané, la marge moyenne est positive, mais sur BCH à 1 PH/s environ trois mois sur dix n’apportent aucun bloc, et sur BTC presque tous. Remplacez l’efficacité et le tarif par les vôtres ; la structure du raisonnement reste la même.

Solo contre FPPS : ce que la commission achète

En valeur attendue, le solo et un pool Full Pay Per Share paient presque la même chose, car tous deux versent la subvention du bloc plus les frais de transaction en proportion de votre travail. Les différences sont :

• La commission. La plupart des commissions FPPS publiées par les grands pools se situent entre environ 2 % et 4 %, au moins un pool lié à une plateforme d’échange annonçant moins (source : comparatif des pools de Simple Mining, mis à jour le 23 sept. 2026). Face à une commission FPPS de 2 à 4 %, une commission solo de 1 % conserve environ 1 à 3 points de pourcentage de plus du revenu attendu.
• Ce que paie la commission plus élevée. Un pool FPPS prend la variance à votre place et paie chaque jour, bloc ou pas. C’est une assurance, et pour beaucoup d’opérateurs elle vaut son prix.
• Les frais de transaction. Le FPPS verse une estimation des frais moyens ; le solo encaisse les frais réels des blocs trouvés. Sur de nombreux blocs, les deux convergent ; bloc par bloc, ils diffèrent.

Le solo a un sens économique lorsqu’une flotte peut absorber la variance à la taille qu’elle choisit, et lorsque les points de pourcentage supplémentaires, ou la préférence pour être payé directement par la blockchain, comptent pour l’opérateur.

La stratégie de la part

Une façon pratique d’utiliser le solo n’est pas de basculer une flotte entière, mais de réserver une part, dimensionnée pour atteindre seule un rythme prévisible, et de garder le reste sur un pool proportionnel.

Un exemple chiffré. Une flotte de 10 PH/s met 1 PH/s en solo sur BCH et 9 PH/s en FPPS. La part a un temps attendu d’environ 25 jours et trouve en moyenne environ 15 blocs par an. Environ 90 % des revenus de la flotte restent quotidiens et prévisibles ; la part ajoute un revenu BCH irrégulier avec un rendement attendu légèrement meilleur.

Comment dimensionner la part. Partez de la règle de la réserve : choisissez la plus grande part dont vous pouvez financer confortablement trois temps attendus sans revenu du solo, et pour laquelle un mauvais trimestre ne change pas vos décisions.

N’y touchez plus. Augmenter la part après une semaine chanceuse, ou la retirer après un mois sec, ne change pas les probabilités, car le minage n’a pas de mémoire. Cela ne change que le temps que la part passe à miner. Décidez une fois, écrivez la décision et révisez-la à dates fixes, pas après chaque résultat.

La difficulté bouge : BTC et BCH se comportent différemment

• Bitcoin recalcule la difficulté tous les 2 016 blocs, environ toutes les deux semaines, et la maintient fixe entre-temps. Entre deux ajustements, votre temps attendu est stable.
• Bitcoin Cash utilise ASERT (aserti3-2d), qui recalcule la difficulté à chaque bloc avec une demi-vie de deux jours (spécification ; notre explication : ASERT explained). Quand du hashrate arrive ou part, la difficulté de BCH suit en quelques jours.

Pour les grandes flottes sur BCH, une conséquence mérite d’être anticipée : votre propre hashrate fait partie du réseau. Dans l’instantané, 100 PH/s représenteraient environ 3 % du hashrate réseau estimé de BCH ; les basculer sur BCH ferait monter la difficulté à peu près de la même proportion en quelques jours, et allongerait d’autant votre propre temps attendu. Sur BTC, les mêmes 100 PH/s représentent environ 0,01 % du réseau et n’ont aucun effet visible.

Cinq erreurs d’interprétation qui font croire à une panne

1. Aucun bloc depuis des semaines, donc une machine est en panne. Vérifiez d’abord les shares acceptés. Si les shares envoyés par la flotte correspondent à son hashrate, la flotte fonctionne, et la période sèche relève de la statistique.
2. Nous avons attendu si longtemps qu’un bloc nous est dû. Le minage n’a pas de mémoire. La probabilité d’un bloc demain ne dépend pas de la durée de votre attente.
3. Notre best share était énorme, donc nous étions proches. Le best share est le share de plus haute difficulté que votre mineur ait jamais produit : il mesure la rareté de ce hash. Il ne signifie pas que vous étiez proche d’un bloc et ne prédit pas le suivant. Plus de détails dans Best Share Explained.
4. Un pool solo avec plus de hashrate offre de meilleures chances. En solo, le hashrate des autres mineurs ne vous aide pas : vos chances dépendent uniquement de votre hashrate effectif et de la difficulté. Ce qui compte dans un pool solo, c’est l’uptime, la latence et des modèles de bloc corrects.
5. Un mois décide si la stratégie fonctionne. À 1 PH/s sur BCH, un seul mois peut aller de zéro à trois blocs sans que rien d’anormal ne se produise. Jugez une part solo sur des périodes de plusieurs temps attendus, jamais sur un seul.

Comment vérifier que la flotte fonctionne sans attendre les blocs

• Shares acceptés comparés aux shares attendus. Le travail accepté doit suivre le hashrate de la flotte sur des heures et des jours. Un écart persistant est un problème de configuration ou de matériel ; l’absence de blocs, non.
• Shares rejetés et stale. Quelques pour cent sont courants ; une hausse soudaine indique généralement de la latence réseau, un mauvais port ou une machine instable. Le seuil exact est une règle pratique qui dépend du matériel et de la connexion, pas une constante du protocole.
• Uptime par machine. C’est le hashrate effectif, pas le nominal, qui fixe les chances. Une machine arrêtée un jour par semaine perd environ 14 % de sa chance.
• Statistiques côté pool via une API. Les flottes devraient lire hashrate, workers et blocs trouvés de manière programmatique plutôt qu’à l’œil. Pour SoloFury, les points d’accès publics sont documentés sur solofury.com/api-docs.

Proposer le solo aux clients hébergés : le point de vue de l’hébergeur

Les hébergeurs qui ont étudié le solo et ont dit non donnent généralement la même raison : un client débutant pourrait choisir le solo sans comprendre la variance, ne voir aucun paiement pendant des semaines et ouvrir un ticket, persuadé que les machines sont en panne. L’inquiétude est fondée, et elle a aussi une solution, car tout ce que le client interpréterait mal est prévisible et peut être expliqué avant le basculement plutôt qu’après.

À qui s’adresse le solo, et à qui non. Le solo convient aux clients qui comprennent que la récompense arrive par à-coups, qui peuvent financer la réserve et qui sont soit assez grands sur BCH pour voir des blocs régulièrement, soit volontairement engagés dans un pari à long terme sur BTC. Il ne convient pas à un client novice dont le plan dépend d’un paiement quotidien. La règle la plus propre consiste à laisser le solo hors de la liste par défaut et à en faire une option sur demande, pour les clients qui la demandent ou qui dépassent un seuil de taille.

L’attestation qui évite les tickets. Avant de pointer la première machine vers le solo, le client confirme par écrit une courte liste de faits, en langage simple :

• le temps attendu par bloc pour son hashrate sur la chaîne choisie, et la date de l’instantané qui a servi au calcul ;
• qu’après un temps attendu, il reste environ 37 % de probabilité de n’avoir aucun bloc, et après trois environ 5 % ;
• que l’indicateur qui prouve que les machines fonctionnent est celui des shares acceptés, pas celui des blocs trouvés ;
• qu’il a mis de côté les coûts d’exploitation pour au moins trois temps attendus ;
• comment la date de révision est fixée, et que les résultats récents ne justifient pas de modifier la part.

Le but est de donner au client un chiffre de référence plutôt qu’une impression, avant la première période sèche et non pendant.

Rendre la période sèche visible. Un client qui voit, sur un tableau de bord, les shares acceptés suivre son hashrate, le nombre de blocs attendus jusqu’ici et les blocs effectivement trouvés, peut répondre lui-même à la question de savoir si quelque chose ne va pas. Cette vue est la mesure anti-tickets la plus efficace qu’un hébergeur puisse ajouter, et elle se construit à partir de l’API publique du pool.

Modèles de tarification et place du solo

Tarif d’hébergement fixe par kilowattheure. Le client paie l’énergie et l’exploitation, conserve toute la récompense et choisit le pool. Le solo s’intègre sans aucun changement : le revenu de l’hébergeur ne dépend pas du moment où arrivent les blocs.

Partage des revenus. L’hébergeur conserve un pourcentage de ce que minent les machines. Certains hébergeurs le perçoivent au niveau du pool, via une intégration avec un pool proportionnel qui répartit les paiements quotidiens. Avec un pool solo, ce mécanisme n’existe pas aujourd’hui : la coinbase paie le mineur et la commission du pool, et il n’y a pas de troisième sortie pour l’hébergeur. Un hébergeur à partage de revenus peut tout de même proposer le solo de deux façons : en facturant sa part à partir des blocs trouvés, publics on-chain et dans l’API du pool, ou en appliquant un tarif fixe à la part solo. Dans les deux cas, l’accord doit figurer dans le contrat avant le premier bloc, et non être discuté après.

Sélection du pool gérée. Certains hébergeurs choisissent le pool pour le client. Dans ce modèle, le solo peut être proposé comme une option explicite avec sa propre attestation, ou exclu ; ce qui ne fonctionne pas, c’est de basculer un client vers le solo sans l’explication ci-dessus.

Configuration de la flotte pour le solo

• Une adresse de paiement par client, des workers nommés par machine. Dans la plupart des pools solo, le nom d’utilisateur est l’adresse de paiement et un suffixe identifie le worker. Les statistiques par client viennent alors d’elles-mêmes, et un bloc trouvé par n’importe quelle machine de ce client paie ce client.
• Ports haute difficulté pour les machines industrielles. Le trafic de shares d’un rack de mineurs de classe S21/S23 est bien supérieur à celui des appareils domestiques. Utilisez les ports haute difficulté ou Stratum V2 du pool quand ils existent, et une difficulté de départ fixe pour l’installation ; cela réduit le trafic réseau sans changer les chances.
• Région la plus proche. Les shares stale sont du travail arrivé trop tard pour compter. Pointez les machines vers la région du pool la moins latente depuis le site et mesurez le taux de stale après le basculement.
• Pool de secours. La plupart des firmwares prennent en charge un pool secondaire. Configurer comme secours le compte du client sur un pool proportionnel maintient le hashrate productif en cas d’indisponibilité du pool solo, et tient le client informé de l’utilisation du secours.
• Formats de connexion propres à chaque firmware. Les firmwares Stratum V2 diffèrent selon qu’ils attendent un hôte et un port ou une URL complète avec la clé d’autorité du pool. Consultez la documentation du pool pour chaque firmware avant de déployer un rack entier.

Ce qu’il faut suivre, par client

L’indicateur de chance affiché par de nombreux pools compare le travail effectué depuis le dernier bloc au travail attendu par bloc. Une valeur inférieure à 100 % signifie que l’attente en cours est plus longue que la moyenne ; elle décrit le passé, ce n’est pas une prévision, et les définitions varient d’un pool à l’autre.

Le jour où un bloc arrive

1. Confirmez on-chain, pas seulement dans le pool. Vérifiez la hauteur du bloc sur un explorateur indépendant et contrôlez que la coinbase paie l’adresse du client.
2. Attendez la maturité. Les récompenses de la coinbase deviennent dépensables après 100 confirmations, une règle de consensus sur BTC comme sur BCH, soit environ 17 heures à dix minutes par bloc.
3. Surveillez les orphelins. Rarement, un bloc trouvé perd la course face à un autre bloc à la même hauteur et ne fait pas partie de la chaîne définitive. Si la hauteur n’est plus dans la chaîne principale après quelques confirmations, la récompense n’est pas dépensable ; c’est une propriété du protocole, pas du pool.
4. Enregistrez-le. Hauteur, hash, horodatage, adresse, récompense et sortie de commission, pour la comptabilité du client et pour une éventuelle facture de partage des revenus.
5. Expliquez au client la suite, y compris que le prochain bloc n’est ni plus ni moins probable qu’avant. Notre guide des étapes après une victoire se trouve dans You Found a Block, Now What?.

Trois profils de flotte chiffrés

Tous les chiffres utilisent l’instantané du début de ce guide.

Profil A : un client à 2 PH/s qui veut essayer le solo. L’hébergeur recommande BCH pour toute l’allocation ou, plus prudemment, une part de 500 TH/s. À 2 PH/s sur BCH, le temps attendu est d’environ 12 jours, soit environ 30 blocs par an, et une fenêtre de 30 jours apporte de zéro à cinq blocs dans neuf cas sur dix ; un mois sans bloc arrive environ une fois sur onze. À 500 TH/s, le temps attendu est d’environ 49 jours et un mois sans bloc arrive plus d’une fois sur deux : c’est le chiffre à inscrire dans l’attestation.

Profil B : un opérateur à 30 PH/s qui veut le solo comme seconde source de revenus. Dix pour cent de la flotte, 3 PH/s, passent en solo sur BCH : temps attendu d’environ 8 jours, environ 45 blocs par an, de un à sept blocs dans un mois typique, et une fenêtre de 90 jours sans bloc est pratiquement impossible si les machines fonctionnent. Les 27 PH/s restants demeurent en FPPS. Si l’hébergeur facture un partage des revenus, la part de 3 PH/s est facturée à partir des blocs enregistrés on-chain.

Profil C : un opérateur à 150 PH/s qui envisage un pari à long terme sur BTC. Sur BTC, les 150 PH/s complets ont un temps attendu d’environ 44 jours et environ huit blocs par an, mais la moitié des mois se termine sans bloc et une période sèche de 90 jours arrive environ une fois sur huit. Une part de 20 PH/s sur BTC a un temps attendu d’environ 11 mois : deux chances sur trois d’au moins un bloc la première année, et une sur trois d’une année entière sans rien. C’est une allocation délibérée pour un opérateur qui peut la porter, pas un plan de revenus. Les mêmes 20 PH/s sur BCH trouveraient au contraire un bloc environ toutes les 30 heures.

Un registre des risques pour le solo à l’échelle d’une flotte

BTC ou BCH pour une part solo ?

La liquidité fait partie de la décision : BTC et BCH sont tous deux cotés sur les grandes plateformes d’échange centralisées, ce qui compte quand une flotte doit convertir ses récompenses pour payer des factures en monnaie fiduciaire.

Avant de pointer une flotte vers le solo : une liste de contrôle

• Écrivez les règles. Taille de la part, chaîne, date de révision, et ce qui ne compte pas comme une raison de la modifier.
• Financez la réserve. Au moins trois temps attendus de coûts d’exploitation pour la part.
• Accordez la lecture avec l’hébergeur ou le client. Toutes les personnes concernées doivent savoir que des périodes sèches de deux temps attendus sont normales, avant que la première n’arrive.
• Utilisez un wallet que vous contrôlez. Les récompenses du solo vont à l’adresse figurant dans la configuration du mineur ; les adresses de dépôt d’une plateforme d’échange peuvent fonctionner mais ajoutent une contrepartie. Les récompenses deviennent dépensables après la maturité de la coinbase prévue par le protocole, 100 blocs.
• Planifiez la comptabilité. Un revenu irrégulier peut changer la façon et le moment où les coins minés sont enregistrés dans votre juridiction. Vérifiez auprès d’un conseiller qualifié.
• Mettez en place le suivi. Shares acceptés, taux de rejetés et de stale, et uptime par machine, lus via une API.

Ce que ces mathématiques ne prennent pas en compte

• Les changements de difficulté. Chaque chiffre suppose que la difficulté de l’instantané se maintient. Sur BTC, elle change toutes les deux semaines ; sur BCH, en continu.
• Les prix. Les valeurs de bloc en USD sont un instantané, pas une prévision.
• Les frais de transaction. Les coins par bloc incluent une moyenne ; les blocs réels varient.
• Les blocs orphelins. Rares, mais un bloc trouvé peut parfois perdre la course face à un autre bloc à la même hauteur. Une faible latence et un nœud bien connecté réduisent le risque.
• Votre propre effet sur la difficulté, pertinent sur BCH pour les flottes au-delà de quelques pour cent du hashrate du réseau.

Comment SoloFury gère le hashrate des flottes

Cette section concerne notre propre service ; tout ce qui précède s’applique à n’importe quel pool solo.

• Paiements non-custodial : quand une machine trouve un bloc, la récompense est payée dans la coinbase directement à l’adresse du mineur. Il n’y a ni solde sur le pool, ni étape de retrait, ni inscription : l’adresse du wallet est le nom d’utilisateur.
• Commission de 1 %, payée comme sortie distincte de la coinbase.
• Ports Stratum V2 haute difficulté pour les machines de classe S21/S23 : 3343 pour BTC et 7343 pour BCH. Stratum V1 sur chaque coin, avec TLS sur chaque port.
• Difficulté de départ fixe pour les installations : définissez le mot de passe sur d=50000 pour réduire le trafic de shares.
• 9 régions de serveurs, et une API publique de statistiques par coin pour le suivi des flottes.

Les détails de configuration se trouvent sur la page de démarrage et dans la documentation de l’API. Les probabilités actuelles pour n’importe quel hashrate sont dans le calculateur.

Lectures associées

• Mining Variance & Poisson Math : le modèle de probabilité complet, avec simulations.
• Solo Mining vs Pool Mining : commissions, méthodes de paiement et comparaison des commissions effectives.
• Solo Mining Odds : probabilités par appareil et par chaîne.
• ASERT explained : comment la difficulté de BCH réagit à chaque bloc.
• You Found a Block, Now What? : ce qui se passe après une victoire, et comment la vérifier on-chain.