Block Template is a set of data for assembling a block whose header will be searched for proof of work. It links the previous block, transactions, coinbase and mining constraints; it does not prove that a block has been found or accepted.
The previousblockhash and height fields locate the candidate within the chain. It also includes version, bits and time information. A template is input for assembling a block, rather than merely a finished header for blindly repeating the same calculation. [BIP 22 — Block template structure]
In BIP 22, depends uses one-based references to earlier entries in transactions, whose list excludes coinbase. If a child spends an output of a parent included in the same block, that parent must remain before it. Missing depends means unknown dependencies, not their absence. [BIP 22 — Block template structure]
Bitcoin Core v29.0 constructs coinbase from the subsidy at that height and actual fees of included transactions. After removing transactions, the old coinbasevalue cannot automatically remain an entitled reward. Changing selection requires recalculating available fees. [Bitcoin Core v29.0 — Block assembler]
Under BIP 141, witness commitment commits to witness data through wtxid. Bitcoin Core 29 provides default_witness_commitment for the unmodified template. After changing relevant transactions or their order, verify or recompute the commitment and reflect the resulting TXID values in the header Merkle root. [BIP 141 — Witness commitment] [Bitcoin Core 29 — getblocktemplate RPC]
Bitcoin Core v29.0 selects packages with dependencies and respects weight and sigops. The blockmaxweight and blockmintxfee settings affect assembly. Omission under this policy alone does not prove a transaction is consensus-invalid, and miner configuration cannot raise network limits. [Bitcoin Core v29.0 — Block assembler]
BIP 23 uses mutable to describe allowed changes, such as time or transactions. Server permission does not repeal consensus: predecessor, time, difficulty and transactions must still be correct. Access to a template also does not guarantee an end device unrestricted content selection. [BIP 23 — Mutations and proposals]
BIP 23 can limit work through expires and specify permission to change prevblock. When the chain tip changes, simply replacing the predecessor hash does not ensure everything else remains valid. Height, transactions, reward and other contextual conditions must be reassessed. [BIP 23 — Mutations and proposals]
BIP 23 proposal mode checks a candidate without requiring valid proof of work. A positive result therefore does not mean a block was found, published or permanently included in the chain. The completed block must undergo the appropriate validation when submitted. [BIP 23 — Mutations and proposals]
For the clearest picture, read this entry together with Mining Pool, Block header, Extranonce, Merkle tree. The reverse links also lead from Coinbase transaction, Stratum V1, Stratum V2, Extranonce.