¿Por qué el encabezado del bloque tiene 80 bytes, no 128 bytes (= dos bloques SHA-256)?

De acuerdo con la Referencia del desarrollador de Bitcoin , el encabezado del bloque tiene un total de 80 bytes:

NOMBRE DE BYTES
4 versión
32 hash de encabezado de bloque anterior
32 hachís de raíz de merkle
4 veces
4 veces

Según tengo entendido, el estado medio (primer bloque SHA) contiene 64 bytes del encabezado del bloque (qué campos en particular no sé, pero sé que no contiene el nonce), y el segundo bloque SHA contiene el resto , solo 80-64 = 16 bytes. ¿Significa esto que el segundo bloque SHA se rellena con 64 - 16 = 48 bytes? Si es así, ¿por qué no hacer que el campo nonce, por ejemplo, 48 - 4 = 42 bytes sea más grande (es decir, 52 bytes en lugar de 4 bytes)?

De esa manera, extranonce no tiene que estar en la transacción de generación, lo que acelera el hash, ¿no?

Lo que está sugiriendo se ha propuesto en bitcointalk (parece que no puede encontrar el enlace). Creo que el problema con esto es que causaría una leve renuncia de ASICS, sería una bifurcación dura, y actualizar la extranonce una vez cada 2^32 hashes es extremadamente insignificante de todos modos.
@ StephenM347 Hashing tendrá que ser lo suficientemente rápido como para volver a calcular la raíz de Merkle para un cambio en extranonce sería un cuello de botella, entonces, ¿por qué no simplemente poner extranonce directamente en el bloque SHA de estado medio en primer lugar, por ejemplo?
Recalcular la raíz de merkle nunca será el cuello de botella. Calcula los números, lo he hecho antes. Tenga en cuenta que volver a calcular la raíz merkle requiere hashes Log(N) (N = # de transacciones en el bloque), no N. Incluso si una CPU no pudiera generar suficiente trabajo para una granja ASIC, solo tendría que obtener un procesador con más núcleos. De todos modos, debe volver a calcular la raíz de Merkle periódicamente para nuevas transacciones.
@ StephenM347 ¿Por qué se actualiza extranonce cada 2³² hashes?
el nonce es un número entero de 32 bits, por lo que hay 2 ^ 32 valores que puede probar antes de que se agote y necesite cambiar algo más.
@ StephenM347 Oh, sí, por supuesto. Por alguna razón estaba pensando en extranonce, no nonce. Gracias
@Geremia A su encabezado de bloque le falta el campo <nBits> 4-bytes denoting the target threshold.

Respuestas (1)

Podría haberse hecho de esa manera, a costa de aumentar la cantidad de espacio que se necesita para almacenar y enviar encabezados de bloque. Parece que el almacenamiento de encabezados de bloques era una gran preocupación para Satoshi (incluso hay una sección en el documento técnico al respecto), pero resultó que no importaba mucho.

¿Significa esto que el segundo bloque SHA se rellena con 64 - 16 = 48 bytes?

Sí, (fuente) pero su razonamiento es defectuoso. Incluso si el espacio de nonce fuera tan grande que se extendiera a otro bloque, eso solo significaría que midstate representaría el estado después de hacer hash de todo menos el último bloque (bloque en el sentido de criptografía, no en el sentido de Bitcoin).

Además, si el encabezado del bloque tuviera exactamente 128 bytes, el relleno lo extendería a un tercer bloque. Solo tienes 119 bytes antes de que eso suceda.

De esa manera, extranonce no tiene que estar en la transacción de generación, lo que acelera el hash, ¿no?

Realmente no. Puede verificar 2 ^ 32 hashes antes de incrementar la extranoncia, después de lo cual solo necesita hacer diez o más hashes antes de volver a la minería.

Generalmente, en los ASIC modernos, incluso esa parte se ha descargado. Habrá algún tipo de pequeño procesador dentro del ASIC, como un núcleo ARM, que toma una plantilla de bloque como encabezados de bloque de entrada y salida para que funcionen los núcleos SHA256.

Entonces, el costo no es de velocidad, sino de complejidad.

Como muchas cosas en Bitcoin, creo que esta es una decisión técnica que tenía sentido en ese momento, pero que envejeció mal.

El tamaño de los encabezados de los bloques importará más cuando reduzcamos el tiempo entre bloques.
@MeniRosenfeld ¿Lo hace? Quiero decir, estamos hablando de 4-8 bytes adicionales por cada 80 bytes. Eso no parece una diferencia significativa.
Correcto, si es solo un pequeño cambio, no importará mucho. Pero si, por ejemplo, duplicara el tamaño del encabezado, duplicaría el requisito de recursos para los clientes SPV, lo que puede ser significativo cuando tiene bloques acelerados por GHOST y SPV en teléfonos celulares o incluso en dispositivos más pequeños. Sin embargo, los esquemas de verificación probabilística podrían resolver eso.
@MeniRosenfeld, ¿crees que se cambiará el tiempo de bloque objetivo? Dado lo difícil que es lograr que todos acepten cambiar un parámetro simple de tamaño máximo de bloque, soy escéptico. A menos que lo haga todo el mundo moviéndose a una cadena lateral o algo así.
@StephenM347: Ciertamente eso espero. Es solo una de las muchas cosas que deberán resolverse eventualmente.
¿Por qué el encabezado del bloque tiene 80 bytes, no 128 bytes (= dos bloques SHA-256)?
RespuestasAquíPolítica de privacidad1y, 0v