Comment fonctionne réellement un pool de minage Bitcoin : du share au paiement

L'explication standard est la suivante : les mineurs combinent leur hashrate, trouvent un bloc ensemble et se partagent la récompense. Rien dans cette phrase n'est faux, et rien d'utile n'en découle non plus. Elle n'explique pas pourquoi vous êtes payé les jours où le pool ne trouve aucun bloc. Elle n'explique pas pourquoi le tableau de bord affiche un hashrate différent de celui de votre machine. Elle n'explique pas d'où vient une chance de 78%, ni pourquoi ce chiffre n'a parfois rien à voir avec votre portefeuille.

Ce qui suit est la chaîne complète : ce qui sort physiquement de votre machine, comment c'est comptabilisé, en quoi cela se transforme, et à quel moment cela devient une transaction sur votre adresse. Pas de métaphores de billet de loterie.

POOL BTC n'est pas un pool. Nous comparons les conditions d'autres opérateurs et calculons ce qu'elles coûtent à un mineur, il n'y a donc ici aucun opérateur vendu ni accusé. Seulement de la mécanique, et de l'arithmétique que vous pouvez refaire vous-même.

Six éléments qui comptent

1. Un share et un bloc sont le même objet. Seule la hauteur de la barre diffère.
2. Le pool vous attribue une barre personnelle et facile à franchir, afin de pouvoir observer votre travail toutes les quelques secondes plutôt qu'une fois par siècle.
3. C'est le pool qui construit le bloc, pas vous. Votre matériel itère des nombres à l'intérieur d'un header qui lui arrive déjà construit.
4. Un schéma de paiement est une règle définissant qui porte le risque de malchance : vous ou l'opérateur.
5. Les frais sont prélevés sur la récompense brute, donc en valeur absolue ils augmentent avec le prix et avec votre hashrate.
6. La chance est une statistique, pas un comportement de l'opérateur. En FPPS, elle ne touche jamais votre paiement.

Qu'est-ce qu'un share, et en quoi diffère-t-il d'un bloc valide ?

Un share est un header de bloc dont le hash est tombé en dessous d'une cible facile que le pool vous a attribuée personnellement. Un bloc est ce même header dont le hash est tombé en dessous de la cible de l'ensemble du réseau. Seule la hauteur de la barre diffère : le travail, le format des données et la validation sont identiques. Tout share qui franchit la cible du réseau devient automatiquement un bloc valide.

Un header de bloc Bitcoin fait 80 bytes et contient six champs : version, hash du bloc précédent, racine de Merkle, horodatage, nBits et nonce. nBits est un encodage compact de la cible actuelle du réseau, et il se développe en un nombre de 256 bits sous lequel le double SHA-256 du header doit se situer.

Votre ASIC prend ce header et modifie ce qu'il est autorisé à modifier : le nonce (4 bytes), l'extranonce2 (le pool fixe sa longueur au moment de la connexion, et il entre dans la racine de Merkle via la transaction coinbase) et, si le pool et le firmware prennent tous deux en charge le version rolling, certains bits du champ version. Chaque header candidat est haché deux fois et comparé à la cible.

Le pool vérifie deux cibles à chaque soumission. Le share entrant est comparé à votre cible personnelle (il la franchit : il est compté dans votre comptabilité) et à la cible du réseau (il la franchit aussi : le pool publie immédiatement un bloc). Il n'existe pas d'acte distinct de « recherche d'un bloc ». Un bloc est un sous-produit du flux ordinaire de shares.

Une conséquence non évidente : un pool ne peut pas cacher un bloc qu'il a trouvé sans écarter le share lui-même. La transaction coinbase de son template porte les propres adresses et le tag du pool, et tout bloc construit à partir de ce template apparaît dans les explorateurs sous le même marqueur. La procédure pratique pour vérifier cela figure dans notre article sur la vérification qu'un pool paie équitablement.

Selon le calcul de POOL BTC, à une difficulté réseau de 127,450,789,715,843 et une difficulté de share de 65,536, un bloc nécessite en moyenne environ 1.94 milliard de shares. Ce n'est pas une estimation d'ordre de grandeur mais une simple division : la difficulté réseau divisée par la difficulté de share, car les deux sont exprimées dans la même unité de travail attendu.

Qu'est-ce que la difficulté de share, et pourquoi le pool l'ajuste-t-il à la machine (vardiff) ?

La difficulté de share est un multiplicateur indiquant à quel point la cible qui vous est attribuée est plus facile que la cible de base de Bitcoin. À la difficulté 1, un share nécessite en moyenne 2^32 hachages, soit environ 4.295 milliards. À la difficulté 65,536, il en faut 65,536 fois plus. Le pool fait varier ce nombre pour que votre flux de soumissions reste pratique à comptabiliser.

Ce mécanisme d'ajustement s'appelle vardiff, pour variable difficulty. Le pool observe la fréquence de vos soumissions et augmente ou diminue votre difficulté, en visant un intervalle confortable entre les shares. Trop basse, et une grosse ferme inonde le serveur de trafic. Trop haute, et les statistiques d'une petite machine deviennent bruitées : si un share sort une fois toutes les deux minutes, le graphique de hashrate horaire oscillera de dizaines de pourcents par le seul effet du hasard.

Selon le calcul de POOL BTC, une machine de 100 TH/s à une difficulté de share de 65,536 soumet environ 21.3 shares par minute, soit un share environ toutes les 2.8 secondes. Le calcul : 100 TH/s représente 10^14 hachages par seconde, divisé par 65,536 × 2^32 = 2.815 × 10^14 hachages attendus par share, ce qui donne 0.355 share par seconde.

La même machine à différentes difficultés de share :

Et à une difficulté fixe de 65,536, selon le hashrate :

Ce qu'il faut retenir : la difficulté de share n'affecte pas votre revenu. Elle affecte la vitesse à laquelle l'estimation du pool converge vers votre hashrate réel. Doublez la difficulté et vous envoyez deux fois moins de shares, deux fois plus lourds. Le produit reste inchangé.

Qui construit le template de bloc, et que contient un bloc ?

Sous le Stratum V1 classique, c'est le pool qui construit l'intégralité du template. Il fait tourner son propre nœud Bitcoin, sélectionne des transactions dans la mempool, construit une transaction coinbase payant ses propres adresses, et calcule l'arbre de Merkle. Ce qui parvient au mineur n'est pas une liste de transactions mais un ensemble de branches de Merkle plus les deux moitiés de la coinbase. Le mineur ne peut physiquement ni sélectionner ni refuser une transaction.

Le message mining.notify qui distribue le travail transporte un job id, le hash du bloc précédent, les deux moitiés de la transaction coinbase, la liste des branches de Merkle, la version, nBits, l'heure, et un indicateur clean_jobs. Le mineur insère son extranonce2 entre les deux moitiés de la coinbase, recalcule la racine de Merkle à partir des branches, et assemble le header.

Cet indicateur clean_jobs explique une bonne partie de ce qui paraît étrange dans les logs du mineur. Quand un nouveau bloc apparaît sur le réseau, le pool pousse un nouveau job avec clean_jobs à true, et tout le travail effectué sur le job précédent devient sans valeur à partir de cet instant. Les shares soumis ensuite contre l'ancien job reviennent rejetés comme stale.

Ce qui se trouve réellement dans le bloc : la transaction coinbase (le subside plus la somme des frais de chaque transaction incluse, le subside étant de 3.125 BTC au 24.09.2026) et un ensemble de transactions de la mempool, généralement triées par frais par octet virtuel. La part des frais dans la récompense totale du bloc est faible en ce moment. Selon mempool.space au 08.09.2026, elle était de 0.66% sur les 4,320 derniers blocs et de 0.57% sur les 144 derniers, et sur le mois le chiffre est resté entre 0.66% et 0.73%. D'autres agrégateurs, en regardant des fenêtres d'une seule journée, rapportent de 0.40% à 0.56%, car ils utilisent un dénominateur différent. Il n'existe pas ici un chiffre unique correct, seulement un chiffre accompagné d'une fenêtre et d'une source précisées.

La seule partie du protocole qui retire au pool la construction du template est Job Declaration, un composant de Stratum V2. Elle tourne en production chez une poignée de pools, et il ne faut pas la confondre avec un pool annonçant qu'il « prend en charge Stratum V2 ». Les trois chiffres d'adoption distincts qui se cachent derrière ces annonces sont détaillés dans notre article sur Stratum V2 et qui choisit les transactions.

Comment le pool mesure-t-il la contribution d'un mineur et la transforme-t-il en paiement ?

Le pool tient un registre des shares acceptés avec leur poids, rattaché à votre worker. Au moment du règlement (la fin de la période quotidienne pour la famille PPS, l'instant où un bloc est trouvé pour PPLNS), il calcule votre part selon sa formule, en déduit les frais, crédite un solde interne, et envoie une transaction une fois que ce solde dépasse le seuil de paiement.

Le parcours complet d'un share, de l'ASIC jusqu'aux pièces dans votre portefeuille :

1. Le pool envoie mining.notify avec un job et la difficulté actuelle de votre worker.
2. L'ASIC fait varier le nonce, l'extranonce2 et les bits de version jusqu'à ce que le double SHA-256 du header tombe en dessous de votre cible.
3. L'ASIC envoie mining.submit : job id, extranonce2, heure, nonce.
4. Le pool vérifie que le job est bien à jour, que le share n'est pas un doublon, et que le hash est bien en dessous de votre cible. Il le compare en même temps à la cible du réseau.
5. Le share accepté est inscrit dans le registre avec un poids égal à sa difficulté.
6. Le pool crédite votre part : soit un taux fixe par share, soit une portion de la récompense d'un bloc trouvé, selon le schéma.
7. Les frais du pool sont prélevés sur ce crédit, calculés sur le montant brut.
8. Ce qui reste vient s'ajouter au solde interne, généralement affiché comme « non payé » dans le tableau de bord.
9. Une fois que le solde dépasse le seuil, le pool construit une transaction, déduit les frais réseau selon sa propre politique, et l'envoie à votre adresse.
10. Après les confirmations, le montant vous appartient enfin. Jusqu'à cet instant, c'est une dette de l'opérateur, pas votre argent.

Les étapes neuf et dix méritent qu'on s'y arrête. Entre « crédité » et « arrivé » se trouve le seuil de paiement, et à faible hashrate ce seuil se transforme en période d'attente.

Selon le calcul de POOL BTC, une machine de 100 TH/s, à un hashrate réseau de 930.73 EH/s et un subside de 3.125 BTC, gagne 0.00004835 BTC par jour en subside brut (paramètres réseau : mempool.space, instantané du 08.09.2026). En ajoutant la part de frais de 0.66%, on obtient 0.00004867 BTC, et après des frais de pool de 2% il reste 0.0000477 BTC par jour. Face au seuil de 0.001 BTC publié par F2Pool, AntPool et Luxor, le premier paiement arrive vers le jour 21 de fonctionnement ininterrompu. Face au seuil d'Ocean, indiqué dans des sources secondaires à 0.01048576 BTC, l'attente serait d'environ 220 jours.

Ce n'est pas une critique d'Ocean, qui paie aussi via Lightning sans seuil. Cela illustre simplement qu'un seuil de paiement signifie une chose pour une seule machine et tout autre chose pour une ferme de 10 PH/s. Vous pouvez confronter le seuil à votre propre hashrate et calculer l'intervalle entre paiements dans le calculateur POOL BTC.

En quoi PPS, FPPS, PPLNS et SOLO diffèrent-ils mécaniquement, au-delà du marketing ?

Un schéma de paiement répond à une seule question : qui porte le risque que les blocs arrivent plus tard que prévu. En PPS et FPPS, l'opérateur assume ce risque et vous vend de la prévisibilité via des frais plus élevés. En PPLNS et TIDES, le risque reste chez les mineurs et se répartit sur une fenêtre de shares. En SOLO, il est entièrement à vous, sans aucun lissage.

La différence mécanique se manifeste à deux endroits. D'abord, en FPPS le taux par share est connu à l'avance, donc le crédit quotidien doit être plat à hashrate constant, et toute rupture sur ce graphique signale soit un changement de la difficulté réseau, soit un problème de votre côté. Ensuite, une fenêtre PPLNS est définie en unités de travail plutôt qu'en temps, donc quand la difficulté réseau grimpe, la fenêtre se contracte en heures d'elle-même.

La façon dont les opérateurs formulent réellement leurs fenêtres varie plus qu'on ne le suppose. ViaBTC indique officiellement « les 5 derniers rounds de difficulté ». Ocean documente sa fenêtre comme huit fois la difficulté du bloc en valeur de shares. AntPool et F2Pool parlent des « N derniers rounds de difficulté » sans publier N. Braiins ne fait tourner le BTC en FPPS que depuis décembre 2023 et ne propose aucun schéma de type PPLNS.

Les formules de chaque schéma, ainsi que ce qui arrive à vos shares quand vous quittez un pool, sont détaillées dans notre article dédié sur les schémas de paiement. Ce qui compte ici, c'est la répartition du risque présentée ci-dessus.

D'où viennent les frais du pool, et que couvrent-ils ?

Les frais du pool sont un pourcentage que l'opérateur retient sur la récompense brute avant distribution. Ils financent des nœuds Bitcoin et des serveurs stratum répartis sur plusieurs régions, une équipe d'astreinte, le risque de variance que l'opérateur absorbe sous les schémas PPS, et l'infrastructure de règlement. Chez les grands pools, les taux se situent entre 1% et 4%, et les comparer directement d'un schéma à l'autre ne fonctionne pas.

Le détail que l'on oublie souvent : les frais sont prélevés sur le crédit brut, pas sur le profit ni sur ce qui reste après l'électricité. Le même pourcentage représente donc une somme absolue différente selon le prix et le hashrate, et c'est aussi pourquoi les schémas PPS facturent plus. Ce pourcentage intègre le prix que paie l'opérateur pour garantir votre paiement lors d'une mauvaise semaine.

Ce qui est confirmé sur des pools spécifiques à la date de cet instantané :

Selon le calcul de POOL BTC, l'écart entre des frais de 2% et de 4% sur une machine de 100 TH/s est de 0.00000097 BTC par jour, soit environ 0.000355 BTC sur un an. Ce chiffre paraît insignifiant jusqu'à ce qu'on le multiplie par le nombre de machines : sur une ferme de 100 ASIC identiques, ces mêmes deux points de pourcentage représentent 0.0355 BTC par an.

Pourquoi classer les pools sur un seul pourcentage reste trompeur est détaillé dans notre article sur les frais et un score de pool à quatre facteurs : le seuil de paiement, la politique de frais réseau et l'écart de conversion automatique l'emportent sur l'écart de pourcentage plus souvent que le pourcentage lui-même.

Que sont la chance et la variance, et pourquoi un pool peut-il être en deçà de l'attente sur une semaine ?

La chance est le ratio entre le coût attendu en shares et les shares réellement dépensés sur les blocs trouvés, exprimé en pourcentage. Une valeur de 78% signifie que les blocs ont coûté au pool plus de travail que prévu, 130% qu'ils en ont coûté moins. La variance est la dispersion statistique dont la chance est issue. La découverte des blocs est un processus de Poisson, l'écart est donc inévitable et ne se réduit qu'à mesure que l'échantillon grandit.

Une propriété utile de la distribution de Poisson : l'écart type est égal à la racine carrée de l'espérance. La dispersion relative diminue donc avec la racine carrée du nombre de blocs, et non proportionnellement au hashrate.

Selon le calcul de POOL BTC, à un hashrate réseau de 930.73 EH/s et 1,008 blocs par semaine :

La première ligne correspond à la même machine de 100 TH/s, minant en solo : le temps attendu jusqu'à un bloc, à une difficulté de 127.45 trillions, est d'environ 173 ans, et la probabilité d'en trouver un sur une semaine donnée est d'environ 0.011%.

La dernière ligne correspond à Foundry USA. Selon le tableau de ChainBulletin pour le 08.09.2026 (repris dans l'article de KuCoin du 10.09.2026), le pool détient environ 244.6 EH/s, soit environ 27% du réseau, avec AntPool près de 156 EH/s et F2Pool près de 127 EH/s. Le coefficient de Nakamoto, le nombre de pools produisant plus de la moitié de tous les blocs, s'établit à 3 selon le rapport de D-Central pour le premier semestre 2026.

Deux conclusions se dégagent de ce tableau. Un pool de 10 EH/s parfaitement honnête, sans aucun incident, terminera environ une semaine sur trois en dessous de 70% ou au-dessus de 130% de chance, et c'est un comportement ordinaire pour une variable aléatoire. Dans le même temps, si vous êtes en FPPS, rien de cette ligne ne s'applique à vous, car vous êtes payé à un taux par share, que le pool trouve un bloc ou non. La chance en FPPS est une métrique de l'opérateur, pas la vôtre.

L'inverse est vrai aussi. Une seule semaine de chance ne prouve rien, dans un sens ni dans l'autre. Un échantillon significatif pour juger de l'honnêteté d'un pool PPLNS commence à un trimestre.

Que se passe-t-il en cas de déconnexion : shares stale, taux de rejet, failover ?

Quand la liaison tombe, l'ASIC continue de hacher contre le dernier job reçu, mais il n'y a nulle part où envoyer les résultats, donc ce travail est perdu. Une fois la connexion rétablie, les shares soumis contre le job périmé sont rejetés comme stale. Votre solde accumulé n'est pas touché : il reste sur le compte en attendant le seuil de paiement. Ce que vous perdez, c'est le travail en cours, plus votre position dans la fenêtre si vous êtes en PPLNS.

Les raisons pour lesquelles un pool rejette un share ont des significations différentes et méritent d'être distinguées dans vos logs :

1. Stale, ou job not found : le share est arrivé contre un job qui n'est plus à jour. Généralement dû au réseau, à la latence, ou à un nouveau bloc sur le réseau.
2. Low difficulty share : le hash n'a pas atteint votre cible actuelle. Souvent une désynchronisation juste après un changement de vardiff.
3. Duplicate share : la même combinaison de nonce et d'extranonce2 soumise deux fois. Signe d'un problème de firmware ou d'un bug du contrôleur.
4. Above target : le header échoue franchement à la validation. Généralement du matériel poussé trop loin en overclock ou en température.

Chaque opérateur fixe sa propre norme pour les rejets, et aucun seuil de référence pour le secteur n'existe. AntPool considère comme normal un taux inférieur à 1% et cite par ailleurs un taux moyen de stale de 0.5% ou moins. ViaBTC parle de moins de 3%. F2Pool considère qu'environ 2% est un taux raisonnable de shares en retard. Braiins et Luxor ne publient aucun seuil chiffré.

Selon le calcul de POOL BTC, chaque tranche de 2 points de pourcentage de taux de rejet coûte exactement ce que coûtent 2 points de pourcentage de frais de pool, puisque les deux sont prélevés sur le crédit brut. Pour une machine de 100 TH/s, cela représente les mêmes 0.000355 BTC par an. Un pool à 2% avec une mauvaise route vers son serveur perd face à un pool à 3% avec une route stable.

Ce qui rend le failover moins optionnel qu'il n'y paraît. La configuration stratum d'un ASIC accepte plusieurs adresses de pool, et le firmware passe à la suivante quand la principale tombe. Remplissez chaque emplacement disponible, et gardez au moins une solution de secours chez un opérateur différent, ou au minimum dans une région différente, sinon les deux tomberont au même moment. Le firmware Antminer de série a trois emplacements (Pool 1, 2 et 3, selon le support Bitmain), et Whatsminer en a les mêmes trois.

Un détail spécifique à PPLNS : quitter un pool ne brûle pas vos shares en guise de pénalité. Ils sortent simplement de la fenêtre à mesure que du nouveau travail arrive. Ocean documente cela explicitement, en précisant que les shares ne sont jamais retirés du registre des shares et cessent simplement de compter une fois que le volume de travail les pousse au-delà de la limite de la fenêtre. L'effet pratique est le même, mais dire que « le pool garde vos shares » est une description erronée.

En quoi un pool diffère-t-il de l'hébergement et du cloud mining ?

Un pool est une coordination du travail : le matériel vous appartient, où que vous le gardiez, et le pool distribue les jobs et paie les shares acceptés. L'hébergement est un site : le matériel vous appartient toujours, mais l'électricité, le refroidissement et la connectivité appartiennent à quelqu'un d'autre, et vous continuez de choisir vous-même le pool. Le cloud mining est un contrat : vous ne possédez aucun matériel du tout, seulement la promesse d'une contrepartie de vous verser un flux de paiements.

Hébergement plus pool est un arrangement normal, et les deux ne sont pas en concurrence. Le cloud mining se situe à part car il supprime le seul lien vérifiable de toute la chaîne : la correspondance entre votre matériel, vos shares et les pièces sur la blockchain. Avec un pool et avec l'hébergement, ce lien subsiste, et vous pouvez le recalculer vous-même.

Comment lire les conditions d'un pool au moment de choisir, et ce qu'il faut regarder en plus du pourcentage, est couvert dans notre comparaison de 12 pools.

Questions fréquentes sur la mécanique des pools de minage

Un pool peut-il voler un bloc qu'il a trouvé et ne rien dire ?

Un bloc construit à partir du template d'un pool porte une transaction coinbase avec les adresses et le tag de ce pool, et il apparaît dans n'importe quel explorateur. Le cacher n'est pas possible. Ce qui ne peut réellement pas être vérifié de l'extérieur, c'est la comptabilité interne : la part d'un mineur donné dans une fenêtre PPLNS et le hashrate réel du pool restent son propre reporting.

La difficulté de share affecte-t-elle mon revenu ?

Non. La difficulté de share ne change que la fréquence et le poids des soumissions, et le produit reste identique. Doublez la difficulté et vous envoyez deux fois moins de shares, chacun valant deux fois plus. Elle affecte en revanche la précision statistique : une difficulté trop élevée rend le graphique de hashrate bruité pour une petite machine.

Pourquoi le tableau de bord du pool affiche-t-il moins de hashrate que mon ASIC ?

Votre machine rapporte une vitesse de hachage instantanée, tandis que le pool estime votre hashrate a posteriori, à partir des shares acceptés sur une fenêtre de moyennage. Ils ne peuvent pas coïncider par construction. Les shares rejetés et stale élargissent encore l'écart, tout comme la latence vers le serveur stratum. Comparez un chiffre journalier à un chiffre journalier.

Qu'advient-il de mes shares si je pars avant que le pool ne trouve un bloc ?

En PPS et FPPS, rien : vous avez été crédité d'un taux pour chaque share accepté, et il se trouve déjà sur votre solde. En PPLNS, vos shares restent dans la fenêtre et participent aux blocs trouvés après votre départ, jusqu'à ce que du nouveau travail les pousse au-delà de la limite. Le solde accumulé ne brûle pas, il attend le seuil.

Pourquoi le pool a-t-il besoin de mon hashrate s'il paie pour les shares ?

Il ne connaît pas votre hashrate directement. Le pool le dérive du flux de shares : les shares acceptés multipliés par leur difficulté, divisés par la durée de la fenêtre. C'est une estimation plutôt qu'une mesure, ce qui explique précisément pourquoi un graphique sur cinq minutes saute dans tous les sens alors qu'un graphique journalier paraît lisse.

Ce qui reste non confirmé dans nos données au 24.09.2026

1. Les pourcentages de frais chez Luxor et Foundry USA. Aucun des deux ne publie un chiffre unique : Luxor qualifie ses frais de remise sur le FPPS spot, Foundry tarife par palier de hashrate.
2. Le seuil de paiement d'EMCD : les articles du centre d'aide censés l'indiquer renvoyaient une erreur 404 le 24.09.2026.
3. Les 3% de Kryptex proviennent de notre vérification manuelle du 29.08.2026 ; le 24.09.2026, ce pourcentage n'apparaissait plus dans le texte de ses pages publiques de frais.
4. Les paramètres réseau utilisés dans les calculs ci-dessus correspondent à un instantané du 08.09.2026 (hashrate 930.73 EH/s, difficulté 127,450,789,715,843, mempool.space). Le 24.09.2026, la même API affichait 917.89 EH/s et une difficulté de 132,757,073,449,487, de sorte qu'une machine de 100 TH/s gagne désormais environ 4% de moins de subside par jour que dans les exemples ci-dessus. Le prochain retarget au bloc 969,696 était estimé à environ moins 5.5%.
5. Les valeurs de difficulté de share dans les tableaux ci-dessus sont des puissances de deux arrondies, choisies pour rendre l'arithmétique lisible. F2Pool, AntPool et Braiins ne publient pas de difficulté de share par défaut ou minimale. ViaBTC publie le mécanisme plutôt qu'un chiffre : un paramètre d= dans le mot de passe du worker fixe la difficulté de départ et md= fixe le plancher.

En bref

Un share est un bloc avec une barre abaissée, rien de plus. Le pool choisit la hauteur de cette barre pour l'adapter à votre machine, afin de pouvoir observer votre travail en temps réel, et ce réglage ne touche pas votre revenu.

C'est le pool qui construit le bloc, pas vous. Sous Stratum V1, le mineur reçoit des branches de Merkle et un stub de coinbase, jamais une liste de transactions. Cela ne change que sous Job Declaration, et seule une poignée de pools le font tourner en production.

Un schéma de paiement répond à une seule question : à qui le risque. PPS et FPPS vous vendent de la prévisibilité via le pourcentage, PPLNS laisse la dispersion aux mineurs, SOLO ne lisse rien du tout. La chance est la métrique du pool, et en FPPS elle n'atteint jamais votre paiement.

Le taux de rejet coûte précisément ce que coûtent les frais, car les deux sont prélevés sur le crédit brut. Deux points de pourcentage perdus à cause de la connectivité mangent le même montant que deux points de pourcentage de tarif, ce qui explique pourquoi un pool bien connecté à un tarif plus élevé bat souvent un pool distant et bon marché.

Cet article contient des liens de parrainage vers des pools de minage (signalés comme sponsorisés). Nous pouvons recevoir une récompense si vous vous inscrivez via ces liens. Cela ne modifie ni les chiffres ni l'ordre des lignes dans les tableaux : les conditions proviennent des pages officielles des pools.