Cada bloco começa com um cabeçalho de 80 bytes. Mineradores hasheiam só este cabeçalho, repetidamente, então ele precisa se comprometer com tudo no bloco.
Os seis campos
- Version (4 bytes): também usado para sinalização de soft fork via version bits (BIP9).
- Previous block hash (32 bytes): liga ao pai, formando a cadeia.
- raiz Merkle (32 bytes): compromete-se com cada transação.
- Time (4 bytes): timestamp Unix. Deve ser maior que a mediana dos 11 blocos anteriores, e nós rejeitam blocos com mais de 2 horas de adiantamento em relação ao próprio relógio.
- nBits (4 bytes): o alvo de dificuldade em forma compacta.
- Nonce (4 bytes): o número que os mineradores mudam.
O hash
O hash do bloco é SHA-256 aplicado duas vezes ao cabeçalho. Um bloco só é válido se esse hash, lido como número, estiver no ou abaixo do alvo. Por isso hashes de bloco começam com muitos zeros.
Nonce insuficiente
O nonce só tem cerca de 4,3 bilhões de valores, e ASICs modernos esgotam isso numa fração de segundo. Mineradores também mudam o timestamp, os version bits e o extraNonce na transação coinbase. Mudar a coinbase muda a raiz Merkle, dando um novo espaço de busca.
A árvore Merkle
Os txids das transações são hasheados em pares, depois os resultados em pares, até uma raiz. Se um nível tem número ímpar de itens, o último é duplicado. Uma prova de que uma transação está num bloco precisa só de cerca de log2(n) hashes. É o que carteiras leves (SPV) usam.
A regra de duplicação causou CVE-2012-2459: duas listas diferentes de transações podiam dar a mesma raiz. O Bitcoin Core lida com isso detectando tais blocos.
A segunda árvore do SegWit
Dados de witness não estão na árvore de txid. Em vez disso a coinbase inclui uma saída OP_RETURN que se compromete com uma segunda raiz Merkle de wtxids (BIP141). Assim o witness também é coberto pela prova de trabalho.
Cabeçalhos primeiro
Como cabeçalhos são pequenos, um nó pode baixar todos (quase um milhão de cabeçalhos, bem abaixo de 100 MB) e checar a prova de trabalho antes de baixar blocos.