Mining Target

Imagina, solo como ejemplo, un límite de 20: los resultados 19 y 20 serían válidos, pero 21 no. En la minería real los números son mucho mayores, aunque la relación es la misma: hash ≤ target. El símbolo significa menor o igual, no estrictamente menor. Bitcoin Core es un programa con el que los participantes de la red verifican bloques y transacciones. La versión v29.0 enlazada aquí compara así el hash de toda la cabecera. El nonce, un valor que el minero modifica durante la búsqueda, es uno de los datos de entrada. Lo que se compara con el objetivo es el hash resultante. [1]

Jana ve una imagen de un hash válido que comienza con muchos ceros. Es una ayuda visual útil: con representaciones de igual longitud, más ceros iniciales significan un número menor. Pero dos hashes con la misma cantidad de ceros pueden estar a lados distintos del objetivo. También importan las demás cifras. Los ceros no sustituyen la comparación completa hash ≤ target. La regla no busca un patrón bonito de caracteres, sino una condición numérica exacta. [1]

Un bit almacena un cero o un uno; ocho bits forman un byte. Para no guardar todo el número en la cabecera, Bitcoin utiliza el campo nBits de 32 bits. Codifica un objetivo en el espacio de números de 256 bits mediante un coeficiente, un exponente que determina el desplazamiento y un bit de signo. Por ejemplo, 0x04123456 se decodifica como 0x12345600; el prefijo 0x indica notación hexadecimal, que también usa letras. Es un ejemplo de codificación, no el objetivo actual de la red. Para entender lo esencial basta con distinguir el número de su representación compacta. [3] [5]

Al leer datos sin procesar, un mismo número puede parecer invertido. En la cabecera de 80 bytes, nBits ocupa cuatro bytes almacenados en little-endian: primero va el byte menos significativo. Por eso el número 0x1d00ffff aparece en los datos como ff ff 00 1d. El orden de los bytes no cambia el objetivo, solo describe cómo se guarda. Este detalle importa al trabajar con datos sin procesar; quien consulta normalmente un explorador de bloques no debe invertir los números de la pantalla. [2]

Jana podría proponer guardar un número mayor para facilitar la búsqueda. Pero el software no solo comprueba si puede leer nBits. DeriveTarget en Bitcoin Core v29.0 rechaza objetivos negativos, cero, desbordamientos del rango numérico y valores superiores a powLimit, el mayor objetivo permitido para esa red. Decodificar correctamente solo establece qué número representa la codificación; no autoriza por sí mismo a utilizarlo. [1]

Incluso un objetivo dentro del rango permitido puede ser incorrecto para un bloque concreto. Bitcoin Core compara nBits con GetNextWorkRequired, un cálculo basado en el bloque anterior y las reglas de la red. Si no coinciden, devuelve bad-diffbits. Un hash bajo un objetivo propio más fácil no justifica un valor incorrecto en la cabecera. Jana no puede conseguir un bloque aceptado rebajando la exigencia: los demás nodos, los ordenadores que verifican las reglas, rechazarán el intento. [4]

En un modelo de hashes de 256 bits distribuidos uniformemente, cada resultado posible tiene la misma probabilidad. Para un objetivo permitido T, se aceptan los valores desde cero hasta T inclusive. De ahí sale p = (T + 1) / 2^256 por intento; p representa la probabilidad de éxito. La unidad añadida incluye el cero. Esta relación explica por qué un objetivo menor dificulta la búsqueda. No dice cuántos intentos hace una máquina por segundo ni cuándo llegará exactamente el siguiente bloque. [1]

Cuando Jana cumple la condición, demuestra el trabajo de cálculo exigido, no la validez de todo el contenido. Bitcoin Core comprueba además la huella conjunta de las transacciones, la transacción especial de recompensa llamada coinbase, los límites del bloque y la validez de las transacciones. Aquí coinbase es el nombre técnico de la primera transacción del bloque, no la plataforma de intercambio. Un hash bajo no corrige contenidos inválidos. El objetivo forma parte de las reglas, pero no permite saltarse las demás. [4]