¿Cuál era el beneficio previsto de truncar el destino?

Estoy pensando en cómo se trunca el valor de destino y luego se compara con el hash SHA-256 del encabezado de bloque.

Dado que

The maximum target (lowest possible difficulty) is
0x00000000FFFF0000000000000000000000000000000000000000000000000000
and the current target is
0x00000000000004985C0000000000000000000000000000000000000000000000
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (4bits * 32 = 128)  
                                  This part is always zero due to truncation                              

Pregunta:

  • ¿Está ahí simplemente para facilitar la codificación y la evaluación?
  • ¿Hace esto que la operación minera sea más rápida (comparaciones más eficientes)?
  • ¿Las eficiencias de la viñeta anterior son específicas de endian?
  • ¿Existen beneficios estadísticos o inconvenientes en hacerlo distinto de cero? (¿fraccionalmente más fácil encontrar un bloque?)

No he visto una explicación detallada de por qué se tomó la decisión, y no quiero inferir nada por mi cuenta.

Respuestas (1)

Sospecho que el objetivo está truncado para que no consuma demasiado espacio en la cadena de bloques.

La cadena de bloques almacena una forma compacta del objetivo en un campo de "bits" que tiene 4 bytes de ancho. Esto es (significativamente) menos de 32 bytes (256 bits) que representan un hash SHA256.

Por contexto:

  • El ahorro de espacio es exactamente de 28 bytes por bloque.

  • A partir del 28/02/13, un recuento de bloques de 223693, eso es 6,263,404 bytes o aproximadamente 6 MB que se guardaron con esta optimización. Esta optimización de datos se aplica a los datos en disco y a lo que se envía a los mineros desde los operadores de grupos.