Granularidad de la dificultad de Bitcoin

La dificultad se ajusta en porcentajes muy granulares al objetivo de bloques de 10 minutos. Pero agregar otro cero al final de la cadena de ceros del requisito de hash de encabezado para un bloque válido aumentaría exponencialmente la dificultad. Entonces, ¿cómo es que el Alogrithm apunta con tanta precisión a la derecha con dificultad solo mediante el uso de "ceros"?

El número de ceros a la izquierda nunca, en ningún momento, se tiene en cuenta.

Respuestas (2)

La dificultad en realidad está representada por el umbral objetivo codificado en el nBitsvalor del encabezado del bloque. Donde la dificultad representa la representación legible por humanos ("con qué frecuencia debemos tratar de encontrar una solución"), el umbral objetivo define el prefijo que un bloque debe superar para ser válido. Esto significa que el hash de bloque de 256 bits interpretado como un número debe ser inferior al umbral de destino. Aunque nBitses solo un valor de 4 bytes, es una representación comprimida de un número de 256 bits (32 bytes). El primer byte define el exponente, los tres bytes restantes dan una mantisa de 24 bits para el objetivo.

Si bien esto deja que la mayor parte de los 32 bytes en el umbral de destino se componga solo de ceros, la dificultad se puede ajustar de una manera mucho más granular que simplemente agregando ceros a la izquierda.

David Harding ha elaborado todos los detalles en ¿ Cómo se calcula la sección de destino de un encabezado de bloque? .

Ok, entiendo que nBits es en realidad el objetivo de dificultad, que es parte del encabezado. Todavía no entiendo qué tiene que ver esto con los ceros iniciales del hash del encabezado: supongo que un nodo completo toma el encabezado, lo duplica y obtiene un hash del encabezado que compara con los nBits para ver si es correcto. ¿Correcto? Mi pregunta es ¿cómo son esos ceros iniciales más granulares para encontrar el hash correcto del encabezado? Creo que me estoy perdiendo algo aquí..
Reemplazar uno inicial con un cero inicial duplica la dificultad, mientras que reducir un prefijo de 24 bits en un conteo solo aumenta la dificultad en un factor de 1.00000006.
@zndtoshi Creo que su confusión se debe al dicho común (pero incorrecto) de que PoW se trata de "la cantidad de ceros iniciales". No lo es, en absoluto. La regla PoW es que el hash del bloque, cuando se interpreta como un número, debe estar por debajo del objetivo. nBitses una codificación compacta del objetivo.
De acuerdo. Entonces, el objetivo está dado por nBits (que es muy granular y eso es perfecto). Pero si esto es cierto, ¿por qué necesita ceros delante del hash del encabezado? ¿No tomaría simplemente el objetivo de nBits y verificaría que el hash del encabezado es correcto? ¿O los ceros iniciales del encabezado hash aumentan exponencialmente la dificultad?
No estoy seguro de entender la pregunta. El objetivo es tan bajo que para que un hash de encabezado lo alcance por debajo, hay una serie de ceros a la izquierda. Si siempre representa sus números con 9 dígitos, pero tiene que elegir uno por debajo de dos mil, siempre tendrá cinco ceros a la izquierda. Pero sigue siendo una diferencia si ha llegado por debajo de 2000 o por debajo de 1999.

Como complemento a la respuesta de @Murch, me gustaría citar un ejemplo de Grokking Bitcoin :

El objetivo se escribe en el encabezado del bloque como 4 bytes, ABCD; el destino de 32 bytes se calcula como BCD× 2^(8*(A-3)). Eso es BCDcon A-3cero bytes después. Es así de incómodo porque debemos poder expresar una amplia gama de objetivos, 1–2^256, con solo 32 bits. El objetivo en el bloque de Qi [un carácter del libro] se escribe como 1c926eb9, es decir, 926eb9con 25 cero bytes después ( 1c–3 = 19, código hexadecimal para 25).

Granularidad de la dificultad de Bitcoin
RespuestasAquíPolítica de privacidad1y, 0v