Un cliente o nodo de la red de Bitcoin determina que está conectado a la cadena que más trabajo tiene y por lo tanto a la red de consenso realizando un proceso de consulta y verificación de los bloques.

Vamos a ejemplificarlo suponiendo que tenemos un nuevo nodo que se va a unir a la red.

De las primeras cosas que el nodo hará será el buscar a otros nodos para conectarse, esto lo hace a través de un proceso establecido en el código de Bitcoin Core, el cual busca DNS seeds (o nodos seeds), estos nodos seeds, están en el código de Bitcoin (ver chainparams.cpp) y lo que harán, será regresar un lista de direcciones IP a las que nuestro nodo intentará conectarse.

Una vez que nuestro nodo se empieza a conectarse a otros nodos de la red les irá pidiendo a su vez más pares a los cuales poder conectarse.

Conforme nuestro nodo va contactando con otros pares, también les irá pidiendo que le indiquen cuál es su mejor chaintip (chaintip sería como preguntar cual es el bloque más nuevo y valido que el nodo al que se le esta preguntando conoce). Una vez que nuestro nodo determine cual de los pares es el que le ha proporcionado la mejor chaintip, nuestro nodo le pedirá además que le proporcione la cadena completa de cabeceras (headers) de los bloques para empezar a validarlos. Después de validar las cabeceras, el nodo almacenara en su base de datos los bloques validados, desde el bloque génesis hasta el chaintip.

Nota: La cabecera de un bloque solo pesa 80 bytes (un peso muy pequeño en comparación con lo que sería un bloque completo) pero es la forma que permite ir verificando que todos los bloques de la cadena están conectados entre sí y que los bloques cumplen con los criterios de dificultad establecidos.

Nuestro nodo verificará cada bloque, para validar que se siguieron las reglas de consenso.

Si descubre que dentro de la cadena existe algún bloque que no cumple con las reglas de consenso, el primer bloque que no sea válido será descartado y los pares o nodos que siguen esa cadena (la que estaba compartiendo el nodo «tramposo») serán desconectados de nuestro nodo.

A partir de este punto, nuestro nodo vuelve a preguntar por la mejor chaintip a los pares restantes (que cumplen con las reglas) y continua con el proceso de sincronizar cabeceras y validar bloques. Así hasta que finalmente, nuestro nodo descubre la cadena válida con la dificultad más acumulada, esto sucede porque al preguntar a sus pares sobre la chaintip, se da cuenta que es casi equivalente a la de nuestro propio nodo, digo casi porque la red nunca está sincronizada al 100%, la red está continuamente generando nuevos bloques y nuestro nodo esta continuamente sincronizando y solo tiene los bloques que conoce, por lo que el proceso en el código de Bitcoin Core tiene implementado un método heurístico para realizar esta afirmación (que esta trabajando con la cadena de mayor trabajo) pero no es menester de este artículo entrar a tanto detalle.

Para facilitar un poco el proceso de validación de la cadena, en cada versión de Bitcoin Core se establece un valor por default (assumevalid), el cual le indica al nodo, en este ejemplo a nuestro nodo recién conectado a la red, que si en la cadena que esta revisando, el valor por defecto está, asuma que ese bloque y todos sus predecesores son bloques válidos y que omita la verificación de sus script’s. Así nuestro nodo asumirá que el historial hasta ese bloque es válido. Esto no significa que por asumir como válidos los bloques, Bitcoin acepta ciegamente los bloques, Bitcoin validará la mayoría de las partes del bloque, incluyendo la Proof of Work, los UTXOs, las cantidades, etc.

Lo único que no estará validando serán los scripts porque los scripts requieren mucho esfuerzo de procesamiento, por lo que asumir como bloques válidos al bloque seteado por defecto y a todos sus predecesores solo significa que se asume que todos los scripts de esos bloques son válidos.

Ya para finalizar, comentar que si bien, nuestro nodo descargará y verificará todos los bloques desde el bloque de génesis, no lo hace en cada inicio o re-inicio del nodo, el estado de los bloques es almacenado de manera eficiente en la base de datos y se vuelve a leer durante el re-inicio de nuestro nodo (verificando algunos de los últimos X bloques, solo para comprobar que no existen datos corruptos en la base de datos).