Le minage associe sélection des transactions et recherche d’un en-tête satisfaisant Proof of Work. Les mineurs proposent ; les autres nœuds vérifient indépendamment validité et appartenance à la branche ayant le plus de travail cumulé.
Il n’existe pas de file centrale unique. Le nœud du mineur a son mempool ; getblocktemplate fournit transactions, dépendances et paramètres. Un enfant dépensant une sortie non confirmée nécessite son parent plus tôt dans le même bloc. Poids du bloc et coût des vérifications de signatures bornent le choix. [Bitcoin Core v29.0: block assembler]
La première transaction peut attribuer au maximum la subvention autorisée plus les frais inclus. Les frais sont la différence entrées-sorties, pas des bitcoins nouvellement créés. Une récompense excessive invalide le bloc malgré Proof of Work. Une sortie coinbase devient dépensable au plus tôt 100 hauteurs plus tard. [Bitcoin Core v29.0: block validation]
Le matériel applique le double SHA-256 aux variantes de l’en-tête de 80 octets. Après épuisement du nonce de quatre octets, modifier l’extra nonce coinbase change Merkle Root et ouvre un nouvel espace. Les échecs passés ne rapprochent pas d’un succès certain ; dix minutes sont une moyenne réseau cible, pas un délai machine. [Bitcoin Developer Guide: Mining]
Un pool distribue le travail et peut estimer les contributions avec une cible share plus facile. Seuls certains shares respectent la cible réseau. Les paiements suivent le modèle convenu et les frais du pool, pas directement le consensus. La part des blocs trouvés ne prouve pas la propriété des machines raccordées. [Bitcoin Developer Guide: Mining]
Les nœuds reçoivent et valident le bloc diffusé. Un bloc concurrent valide peut provoquer une bifurcation temporaire ; une branche abandonnée ne contribue pas sa récompense à l’historique actif. Propagation et actualisation du travail au nouveau sommet influencent donc le résultat autant que la découverte du hash. [Bitcoin whitepaper]
Part de hashrate et rythme réseau ne donnent qu’une fréquence de succès attendue. Le bénéfice dépend aussi d’électricité, efficacité, refroidissement, arrêts, achat et conditions du pool. TH/s n’est pas une puissance en watts ; un succès isolé ne prouve pas la rentabilité durable. [Bitcoin Developer Guide: Mining]
Comparez getblocktemplate avec en-tête, coinbase et transactions du bloc réellement trouvé. submitblock soumet le bloc à la validation locale ; l’acceptation ne garantit pas son maintien dans le réseau. Distinguez shares soumis, blocs acceptés et montant réellement versé. [BIP 22: getblocktemplate]
Pour une vision complète, lisez aussi Proof of Work, Ajustement de difficulté, Récompense de création monétaire, Frais de transaction, Mempool. Cette entrée est également citée par Proof of Work, Ajustement de difficulté, Récompense de création monétaire, Halving.
01Que calculent réellement les mineurs de Bitcoin ?+
Ils calculent de façon répétée le hash obtenu par double SHA-256 de l’en-tête de 80 octets d’un bloc candidat. Ils modifient le nonce et les autres données qui influencent cet en-tête afin de trouver un hash dont la valeur numérique est inférieure ou égale au target valide du réseau.
02Les mineurs vérifient-ils les règles de Bitcoin à la place des utilisateurs ?+
Les transactions sont vérifiées lors de la préparation d’un bloc, mais ce travail ne remplace pas la vérification propre à l’utilisateur. Chaque Full Node contrôle indépendamment le bloc obtenu et le rejette s’il enfreint les règles de consensus, indépendamment de son Proof of Work.