Block Template est un ensemble de données permettant de construire un bloc dont on cherche un proof of work sur l’en-tête. Il relie bloc précédent, transactions, coinbase et contraintes de minage ; il ne prouve ni la découverte ni l’acceptation d’un bloc.
Les champs previousblockhash et height situent le candidat dans la chaîne. Il comprend aussi version, bits et des données temporelles. Le modèle sert à assembler un bloc ; ce n’est pas simplement un en-tête terminé pour répéter aveuglément le même calcul. [BIP 22 — Block template structure]
Dans BIP 22, depends référence à partir de un les entrées antérieures de transactions, liste qui exclut la coinbase. Si une transaction enfant dépense une sortie d’un parent inclus dans le même bloc, ce parent doit la précéder. L’absence de depends signifie des dépendances inconnues, pas inexistantes. [BIP 22 — Block template structure]
Bitcoin Core v29.0 construit la coinbase avec la subvention à cette hauteur et les frais réels des transactions incluses. Après en avoir retiré, on ne peut pas conserver automatiquement l’ancien coinbasevalue comme récompense légitime. Modifier la sélection impose de recalculer les frais disponibles. [Bitcoin Core v29.0 — Block assembler]
Selon BIP 141, le witness commitment engage les données witness via wtxid. Bitcoin Core 29 fournit default_witness_commitment pour le modèle inchangé. Après modification des transactions concernées ou de leur ordre, il faut vérifier ou recalculer l’engagement et intégrer les TXID résultants à la Merkle root de l’en-tête. [BIP 141 — Witness commitment] [Bitcoin Core 29 — getblocktemplate RPC]
Bitcoin Core v29.0 sélectionne des paquets avec leurs dépendances et respecte le poids et les sigops. blockmaxweight et blockmintxfee influencent l’assemblage. L’omission selon cette politique ne prouve pas à elle seule qu’une transaction viole le consensus ; la configuration du mineur ne relève pas les limites du réseau. [Bitcoin Core v29.0 — Block assembler]
BIP 23 décrit avec mutable les modifications permises, par exemple le temps ou les transactions. L’autorisation du serveur n’abolit pas le consensus : prédécesseur, temps, difficulté et transactions doivent rester corrects. L’accès au modèle ne garantit pas non plus au dispositif final un choix de contenu illimité. [BIP 23 — Mutations and proposals]
BIP 23 peut limiter le travail par expires et préciser le droit de changer prevblock. Quand la tête de chaîne change, remplacer seulement le hachage du prédécesseur ne garantit pas la validité du reste. Hauteur, transactions, récompense et autres conditions contextuelles doivent être réexaminées. [BIP 23 — Mutations and proposals]
Le mode proposal de BIP 23 vérifie un candidat sans exiger de proof of work valide. Une réponse positive ne signifie donc ni bloc trouvé ou publié, ni place permanente dans la chaîne. Le bloc terminé doit subir la validation appropriée lors de sa soumission. [BIP 23 — Mutations and proposals]
Pour une vision complète, lisez aussi Mining Pool, En-tête de bloc, Extranonce, Arbre de Merkle. Cette entrée est également citée par Transaction coinbase, ASIC Miner, Mining Pool, Nonce.