Block Template es un conjunto de datos para construir un bloque cuya cabecera se someterá a la búsqueda de proof of work. Vincula el bloque anterior, las transacciones, la coinbase y las restricciones de minería; no demuestra que se haya encontrado o aceptado un bloque.
Los campos previousblockhash y height sitúan al candidato en la cadena. También incluye version, bits e información temporal. La plantilla sirve para construir el bloque, no es simplemente una cabecera terminada para repetir ciegamente el mismo cálculo. [BIP 22 — Block template structure]
En BIP 22, depends referencia desde uno las entradas anteriores de transactions, cuya lista excluye la coinbase. Si una transacción hija gasta una salida de otra incluida en el mismo bloque, la madre debe precederla. La ausencia de depends indica dependencias desconocidas, no inexistentes. [BIP 22 — Block template structure]
Bitcoin Core v29.0 construye la coinbase con el subsidio de esa altura y las comisiones reales de las transacciones incluidas. Tras retirar transacciones, no se puede conservar automáticamente el antiguo coinbasevalue como recompensa legítima. Cambiar la selección exige recalcular las comisiones disponibles. [Bitcoin Core v29.0 — Block assembler]
Según BIP 141, witness commitment vincula los datos witness mediante wtxid. Bitcoin Core 29 ofrece default_witness_commitment para la plantilla sin modificar. Tras cambiar las transacciones pertinentes o su orden, hay que verificar o recalcular el compromiso y reflejar los TXID resultantes en la Merkle root de la cabecera. [BIP 141 — Witness commitment] [Bitcoin Core 29 — getblocktemplate RPC]
Bitcoin Core v29.0 selecciona paquetes con dependencias y respeta el peso y sigops. blockmaxweight y blockmintxfee influyen en la construcción. Que esta política omita una transacción no demuestra por sí solo su invalidez según el consenso; la configuración del minero tampoco eleva los límites de la red. [Bitcoin Core v29.0 — Block assembler]
BIP 23 usa mutable para describir cambios permitidos, como el tiempo o las transacciones. El permiso del servidor no elimina el consenso: predecesor, tiempo, dificultad y transacciones deben seguir siendo correctos. Acceder a una plantilla tampoco garantiza al dispositivo final una selección de contenido sin restricciones. [BIP 23 — Mutations and proposals]
BIP 23 puede limitar el trabajo mediante expires y especificar permisos para cambiar prevblock. Si cambia la punta de la cadena, sustituir el hash del predecesor no garantiza que todo lo demás siga siendo válido. Deben revisarse altura, transacciones, recompensa y otras condiciones contextuales. [BIP 23 — Mutations and proposals]
El modo proposal de BIP 23 comprueba un candidato sin exigir proof of work válido. Un resultado positivo no significa que se haya encontrado o publicado un bloque, ni que ocupe un lugar permanente en la cadena. El bloque terminado debe superar la validación correspondiente al enviarlo. [BIP 23 — Mutations and proposals]
Para obtener la imagen más completa, lee esta entrada junto con Mining Pool, Cabecera de bloque, Extranonce, Árbol de Merkle. También enlazan con esta entrada Transacción coinbase, Stratum V1, Stratum V2, Extranonce.