Aller au contenu
Financial Context Wiki

Minage de Bitcoin : modèles de bloc, preuve de travail, pools et économie

Le minage de Bitcoin construit des blocs candidats et explore les en-têtes SHA-256d pour trouver une preuve sous la cible du réseau. Distinguez identité du modèle, validité des transactions et coinbase, recherche nonce et extranonce, validation des nœuds, propagation, blocs périmés, shares du pool, paiements, difficulté, énergie et économie.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Le minage de Bitcoin construit des blocs candidats valides et hache à répétition leurs en-têtes de 80 octets avec SHA-256d jusqu’à trouver un résultat numérique au plus égal à la cible de consensus. Le mineur gagnant ne fait que proposer le bloc. Il ne peut valider une transaction invalide, décider de faits externes ni contrôler les pièces d’autrui : chaque nœud complet vérifie indépendamment preuve, en-tête, transactions, scripts, sorties dépensées, limites et valeur coinbase autorisée.

Un nœud mineur ou pool obtient les candidats par des interfaces comme getblocktemplate. Les champs utiles comprennent version, previousblockhash, transactions, coinbasevalue, target, bits, height, weightlimit et sigoplimit. Le modèle est un point de départ choisi par politique ; il ne promet ni d’inclure chaque transaction ni d’accepter un bloc modifié. Validité de consensus, politique mempool, sélection des frais et règles du pool sont des couches distinctes.

Le matériel cherche des variantes d’en-tête. Après le nonce 32 bits, le logiciel change l’extranonce coinbase, reconstruit la racine de Merkle et peut mettre à jour heure ou version permises pour créer un nouvel espace. Chaque hachage est un essai indépendant. Plus de puissance compatible augmente la fréquence attendue, sans programmer un bloc ni garantir un délai.

Le minage solo reçoit toute la sortie coinbase autorisée, avec forte variance. Un pool agrège le travail et mesure les contributions par des cibles de share plus faciles ; seule une share atteignant aussi la cible réseau peut devenir un bloc. Le pool réduit la variance, pas l’émission attendue. Garde, contrôle des modèles, validation des shares et engagements PPS, PPLNS ou autres ajoutent des risques de contrepartie et concentration.

Comment analyser le minage

  1. Fixez identité et autorité. Notez chain, network, client version, règles, bestblockhash, fournisseur du modèle, endpoint du pool, bénéficiaire et heure. Séparez nœud, constructeur, opérateur, micrologiciel, installation et propriétaire.
  2. Reproduisez la sélection. Capturez mempool et UTXO set ; vérifiez validité, dépendances, frais, poids, opérations de signature, locktime et engagements witness. Reconstruisez le candidat et expliquez la politique ; le taux de frais n’est pas le consensus.
  3. Rapprochez coinbase et en-tête. Vérifiez subvention par hauteur, frais inclus, sorties, engagements, hachage précédent et arbre de Merkle. Suivez nonce, extranonce coinbase, Merkle root, time et version bits ; rejetez les modèles hors limites.
  4. Vérifiez recherche et soumission. Décodez la cible compacte et testez block_hash <= target selon l’ordre des octets et le hachage du réseau. Une solution trouvée, reconstruisez le bloc, envoyez-le par submitblock ou protocole déployé et conservez la réponse.
  5. Suivez validation et propagation indépendantes. Comparez plusieurs nœuds sur en-tête, transactions, scripts, coinbase et chainwork. Mesurez propagation, pointes rivales, résultats périmés ou orphelins et réorganisations ; trouver une preuve ne garantit pas de rester canonique.
  6. Rapprochez récompense et comptabilité du pool. Séparez coinbase, subsidy + transaction fees, frais et réserves, pool target, network target, share acceptée, shares périmées, méthode, maturité, minimum, garde et contrepartie.
  7. Testez économie et sécurité. Indiquez taux effectif, disponibilité, efficacité, électricité, refroidissement, personnel, hébergement, maintenance, amortissement, financement, impôts, bridage, subvention, frais, prix et difficulté. Testez variance, panne, chocs, retard, défaut, censure, concentration et réorganisation.

Le produit est une proposition de bloc et la preuve d’une recherche informatique. Les nœuds décident la validité ; la règle de fork choisit la branche valide active ; la difficulté ne change la cible qu’à sa frontière ; les applications fixent les confirmations. Le minage participe sans remplacer ces fonctions.

Exemples calculés

1. Le nonce n’est pas tout l’espace

L’en-tête de 80 octets a un nonce 32 bits, soit 2^32 = 4,294,967,296 valeurs. À 200 TH/s, les tester prend environ :

4,294,967,296 / 200,000,000,000,000 = 0.0000214748 seconds

Le travail continue : changer l’extranonce coinbase, dériver une nouvelle racine de Merkle et actualiser les champs permis ouvre un autre espace nonce. Prendre le nonce pour toute la capacité est une erreur de catégorie.

2. Variance solo et électricité

Avec réseau 600 EH/s et mineur effectif 200 TH/s, la part simplifiée est 200 TH/s / 600 EH/s = 0.0000333333%. Pour 144 blocs quotidiens, l’espérance est lambda = 144 * 0.000000333333 = 0.000048 blocks/day, avec attente moyenne 1 / 0.000048 = 20,833.33 days. Poisson donne P(0) = exp(-0.000048) = 99.9952001152% de zéro bloc par jour.

Une machine de 3,5 kW à 0,06 USD/kWh coûte 3.5 kW * 24 * USD 0.06/kWh = USD 5.04/day en électricité directe. Refroidissement, hébergement, arrêt, réparation, amortissement, financement et impôts manquent. L’espérance n’est pas une date d’encaissement ; un succès rare n’est pas une créance quotidienne.

3. Comptabilité coinbase et maturité

Supposons une subvention de 3.125 BTC et des frais valides de 0.42 BTC. Le maximum créé par coinbase est 3.125 + 0.42 = 3.545 BTC ; davantage invalide le bloc et moins abandonne de la valeur.

La sortie coinbase exige 100 blocks de maturité avant dépense. Le bloc peut devenir périmé ou être réorganisé. Solde du pool, coinbase immature et paiement externe final sont des droits distincts aux risques différents.

4. Shares du pool et hypothèses de paiement

Avec shares acceptées de même difficulté, le pool enregistre 2,000,000 et un mineur 50,000 : sa part est 50,000 / 2,000,000 = 2.5%. Pour un bloc de 3,545 BTC et des frais de 2%, le montant distribuable est 3.545 * (1 - 0.02) = 3.4741 BTC et l’allocation 3.4741 * 2.5% = 0.0868525 BTC.

Si la cible du pool est 1,000 fois plus facile, une share acceptée a une probabilité simplifiée 1 / 1,000 d’atteindre aussi la cible réseau. La comptabilité réelle normalise la difficulté variable, rejette doublons et travail périmé, applique PPS, FPPS, PPLNS ou le contrat et sépare paiement attendu du pool et recette conditionnelle au bloc.

Risques et erreurs de contrôle

Erreurs de protocole et de modèle

  • Dire que les mineurs valident les transactions plutôt que choisir des candidats vérifiés par les nœuds.
  • Mélanger chaîne, réseau, fork, pointe, client, fournisseur ou pool.
  • Traiter mempool ou modèle comme consensus, ensemble complet ou futur bloc garanti.
  • Sélectionner par frais individuels sans ancêtres, descendants, poids, signatures, verrous et engagements.
  • Mal calculer hauteur de subvention, frais, sorties coinbase, witness ou racine de Merkle.
  • Chercher sur ancien hachage, cible, heure ou version après une nouvelle pointe.
  • Comparer hachage et cible avec encodage, endianité ou algorithme erronés.

Erreurs de pool et d’exploitation

  • Assimiler share acceptée à bloc réseau ou compter les shares sans normaliser la difficulté.
  • Transformer part attendue en blocs, revenus ou dates garantis en ignorant la variance.
  • Assimiler part du pool à propriété permanente du matériel ou omettre la concentration.
  • Omettre shares périmées et rejetées, latence, micrologiciel, température, disponibilité, bridage et panne.
  • Ignorer méthode, base des frais, réserves, minimum, maturité, garde, retrait et défaut.
  • Traiter un bloc trouvé comme final avant acceptation, propagation, sélection et réorganisation.
  • Réutiliser identifiants, adresses ou micrologiciel distant sans authentification, contrôle et réponse aux incidents.

Erreurs économiques et de sécurité

  • Appeler bénéfice fiat le BTC brut attendu sans prix, difficulté, frais, énergie, refroidissement, travail, amortissement, financement et impôts.
  • Déduire électricité ou émissions du taux sans efficacité, usage, refroidissement, lieu, heure et mix.
  • Supposer une réponse immédiate de difficulté ou des blocs de dix minutes programmés.
  • Affirmer que le halving garantit prix, capitulation ou dépense de sécurité constante.
  • Affirmer qu’une majorité de hachage falsifie les signatures, vole les pièces ou impose une inflation invalide.
  • Utiliser un taux élevé comme preuve contre la concentration de pool, fabricant, micrologiciel, géographie, énergie, réseau ou logiciel.

Idées reçues

  • Les mineurs peuvent approuver toute transaction. Ils choisissent et ordonnent ; les nœuds honnêtes rejettent les blocs contraires au consensus.
  • Seul le nonce est mutable. Extranonce change coinbase et racine de Merkle ; heure et version permises élargissent aussi l’espace.
  • Une share du pool est une fraction de bloc. Elle prouve du travail sous une cible plus facile ; la plupart n’atteignent pas la cible réseau.
  • Le revenu journalier attendu est garanti. La découverte est aléatoire et le paiement dépend du contrat, de la maturité et de la contrepartie.
  • Plus de puissance signifie automatiquement plus de bénéfice. Part, difficulté, frais, prix, efficacité, énergie et coûts décident du résultat.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...