Hash del bloque anterior

Cada bloque apunta hacia atrás, nunca hacia delante. Como el puntero está dentro de los 80 bytes de los que se calcula el hash, editar cualquier cosa de un bloque antiguo cambia su hash y rompe todos los bloques construidos encima, así que deshacer un pago de hace un año significa rehacer aproximadamente 52.000 bloques de prueba de trabajo. Eso, y no una regla sobre borrar datos, es lo que la gente quiere decir cuando llama inmutable a bitcoin.

Cómo funciona

El hash del bloque anterior se obtiene aplicando SHA-256 dos veces al encabezado de 80 bytes del bloque padre, y es la única referencia que un bloque guarda a algo que esté fuera de él.

Como el encabezado del bloque padre contiene el hash de su propio bloque padre, y así sucesivamente hasta el principio, un solo campo de 32 bytes fija todo el historial que tiene detrás. Un nodo que ha verificado la punta de la cadena ha verificado implícitamente que la cadena que lleva hasta ella es internamente coherente. Si se altera una transacción de un bloque minado el verano pasado, cambia el hash del encabezado de ese bloque, lo que significa que la copia que guarda el bloque hijo ya no coincide, lo que significa que el bloque hijo es inválido, y también todo lo que viene después. Reparar el daño significa volver a minar cada uno de esos bloques, a razón de aproximadamente 144 bloques al día, o 52.560 al año.

El bloque génesis es la excepción, y tiene que serlo: no hay nada antes de él, así que el campo está formado por 32 bytes cero.

Nada en un bloque apunta hacia delante. Cuando Bitcoin Core devuelve un campo nextblockhash, está leyendo su propio índice, no el bloque, y precisamente por eso ese valor puede cambiar durante una reorganización de la cadena mientras que el hash del bloque anterior nunca cambia. Que dos bloques identifiquen al mismo bloque padre tampoco es un error. Así es como se ve una bifurcación desde el punto de vista de los datos, y la red la resuelve prefiriendo la rama con más trabajo acumulado, no declarando erróneo ninguno de los dos punteros.

Dónde aparece

El hash del bloque anterior aparece con nombres ligeramente distintos según lo que se esté mirando.

Bitcoin Core lo devuelve como el campo previousblockhash en las llamadas RPC getblockheader y getblock. Para el bloque 0, el campo simplemente no aparece en la respuesta, porque no hay ningún bloque padre que identificar. Los exploradores de bloques suelen etiquetarlo como Previous Block (bloque anterior) y convertirlo en un enlace, que es lo que permite retroceder por el historial haciendo clic.

También es toda la sustancia de una sincronización de la cadena de encabezados. Un nodo que descarga encabezados comprueba dos cosas en cada uno: que identifica al anterior y que su hash cumple el objetivo. Solo cuando esa cadena se sostiene empieza a pedir los cuerpos de los bloques. Las billeteras ligeras nunca van más allá: conservan los eslabones y el trabajo, y nada más.

Si alguna vez construye el campo a mano, prepárese para discutir con sus propios ojos, porque los bytes del encabezado no están escritos en el orden en que se suele citar el hash.

Hash del bloque anterior frente a orden de bytes interno

El hash del bloque anterior se guarda en el orden de bytes contrario al que cita todo el mundo, y eso confunde a casi todos los que intentan verificar un encabezado a mano. El bloque 1 lleva el hash de su bloque padre como 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000. Ese es el hash del bloque génesis, 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, invertido byte a byte. Los ceros a la izquierda que produce la prueba de trabajo acaban a la derecha en el campo en bruto. Que los dos no coincidan a simple vista no significa que algo vaya mal: invierta los bytes y coincidirán.