getblocktemplate es una interfaz con la que un programa obtiene de un nodo de Bitcoin los datos para montar un bloque candidato. Utiliza JSON-RPC: una solicitud y una respuesta estructurada entre programas. El modo habitual entrega una plantilla; otro modo permite revisar previamente una propuesta propia. Ninguno busca por sí mismo una prueba de trabajo.
En el modo habitual mode=template, el programa de Pedro recibe, por ejemplo, el bloque anterior, las transacciones y la recompensa permitida. Es una propuesta de trabajo, no un bloque ya encontrado. El programa debe construir coinbase, la primera transacción especial que asigna la recompensa, y completar el bloque. La cabecera es un resumen compacto de los datos del bloque. Después, el programa busca un hash, una huella criptográfica numérica de esa cabecera, que cumpla el objetivo minero y constituya Proof of Work, la prueba del trabajo de cálculo. getblocktemplate no recibe una dirección de cobro ni pone a calcular la máquina minera. Una respuesta satisfactoria aún no significa que Pedro esté minando. [1]
Imaginemos que el nodo envía datos en un formato que el programa de Pedro no entiende. Por eso la solicitud declara las reglas admitidas en rules. Bitcoin Core v29.0, la versión comprobada aquí, exige segwit y también signet para la red de pruebas Signet. SegWit modifica, entre otras cosas, cómo se tratan los datos de verificación de las transacciones. No basta con añadir la palabra correcta: el programa debe saber procesarlos. capabilities comunica otras funciones de la interfaz y no sustituye a rules. Los requisitos concretos dependen de la implementación y la versión utilizadas. [2]
El campo data contiene la transacción completa organizada para su transmisión entre programas. Esa organización se llama serialización. Los bytes, las unidades básicas de estos datos, se escriben en hexadecimal con los dígitos 0–9 y las letras a–f. La respuesta también incluye identificadores cortos de las transacciones. Según el documento técnico BIP 145, txid se calcula sin los datos witness, mientras que hash los incluye. Witness contiene, por ejemplo, firmas que demuestran la autorización para gastar. La Merkle root principal, la huella conjunta de las transacciones en la cabecera del bloque, utiliza txid y no el witness hash. Confundir los campos no es solo equivocarse de nombre: puede generar una huella conjunta incorrecta e invalidar el bloque montado. [3]
Pedro no necesita bombardear al nodo preguntando si ha cambiado algo. Long polling permite mantener una solicitud abierta hasta que el servidor quiera reemplazar los datos anteriores. El programa recibe longpollid y lo devuelve sin cambios. El valor permite al servidor saber qué actualización espera el programa. El programa no debe intentar deducir un significado de los caracteres que contiene. BIP 22 contempla un tiempo de espera largo. Si se repiten respuestas incompletas o inválidas, hay que espaciar los intentos, no entrar en un bucle de reintentos inmediatos. Por tanto, esperar en silencio no indica por sí solo una avería. [4]
Tampoco una solicitud ordinaria repetida garantiza un contenido recién seleccionado. Bitcoin Core v29.0 conserva una plantilla preparada en caché. La reconstruye si cambia el bloque anterior, o si ha cambiado el mempool, el conjunto local de transacciones sin confirmar, y han pasado más de cinco segundos desde su preparación. Puede actualizar por separado la hora de la cabecera. Pedro puede recibir otra vez la misma selección de transacciones; eso no significa que el nodo se haya bloqueado. Este comportamiento de una versión concreta tampoco promete un trabajo minero único por cada llamada. [2]
Pedro ha modificado la construcción del bloque y quiere detectar errores antes de una búsqueda costosa. En el modo proposal entrega el bloque completo en hexadecimal mediante data. Bitcoin Core v29.0 comprueba también la Merkle root, pero no exige haber encontrado ya un Proof of Work válido, la prueba del trabajo computacional. Si la propuesta no se apoya en el último bloque de la cadena que sigue el nodo, devuelve inconclusive-not-best-prevblk. Falta una condición previa para esa comprobación; no es una evaluación completa de validez. La revisión tampoco difunde el bloque por la red. [2]
Cuando el programa encuentra la prueba de trabajo necesaria, puede enviar el bloque completo mediante submitblock. hexdata lleva todo el bloque serializado en hexadecimal, no solo su cabecera o huella. La documentación de Bitcoin Core 29 indica null cuando se acepta y, en otros casos, un resultado de texto conforme a la especificación. El segundo parámetro opcional, dummy, se ignora; no fija la recompensa. Que un nodo lo acepte no garantiza una confirmación permanente: la evolución posterior de la cadena puede cambiar qué rama queda como principal. [5]
Un nodo recién iniciado puede no haber descargado y verificado todavía la historia que necesita. En la red principal, mainnet, Bitcoin Core v29.0 se niega a emitir una plantilla si no tiene pares conectados o si está en la sincronización inicial IBD (initial block download). Se trata de su preparación para trabajar con la red actual, no del rechazo de un bloque concreto. Al investigar un problema distinguimos entre un long poll en espera, un nodo aún no preparado y el resultado de revisar una propuesta. Todos pueden parecer “no tengo trabajo nuevo”, pero requieren soluciones diferentes. [2]
Para obtener la imagen más completa, lee esta entrada junto con Block Template, Minería, Stratum V2, Extranonce, Bitcoin, Bitcoin Core. También enlazan con esta entrada ASIC Miner, Solo Mining, Job Negotiation.