Blokkheader og Merkle-trær

80 byte som sikrer alt.

Hver blokk starter med en 80-byte header. Utvinnere hasher bare denne headeren, om og om igjen, så den må forplikte seg til alt i blokken.

De seks feltene

  1. Version (4 byte): brukes også til soft fork-signalering via version bits (BIP9).
  2. Previous block hash (32 byte): lenker til forelderen og danner kjeden.
  3. Merkle-rot (32 byte): forplikter seg til hver transaksjon.
  4. Time (4 byte): Unix-tidsstempel. Det må være større enn medianen av de 11 forrige blokkene, og noder avviser blokker mer enn 2 timer foran egen klokke.
  5. nBits (4 byte): vanskelighets-målet i kompakt form.
  6. Nonce (4 byte): tallet utvinnere endrer.

Hashet

Blokkhashet er SHA-256 brukt to ganger på headeren. En blokk er gyldig bare hvis det hashet, lest som et tall, er på eller under målet. Derfor starter blokkhasher med mange nuller.

Ikke nok nonce

Noncen har bare omkring 4,3 milliarder verdier, og moderne ASIC-er tømmer det på en brøkdel av et sekund. Utvinnere endrer også tidsstemplet, version bits, og extraNonce i coinbase-transaksjonen. Å endre coinbase endrer Merkle-roten og gir et nytt søkerom.

Merkle-treet

Transaksjons-txid-ene hashes i par, deretter resultatene i par, opp til én rot. Hvis et nivå har et oddetall elementer, dupliseres det siste. Et bevis for at en transaksjon er i en blokk trenger bare omkring log2(n) hasher. Det er det lette (SPV)-lommebøker bruker.

Dupliseringsregelen forårsaket CVE-2012-2459: to ulike transaksjonslister kunne gi samme rot. Bitcoin Core håndterer dette ved å oppdage slike blokker.

SegWits andre tre

Witness-data er ikke i txid-treet. I stedet inkluderer coinbase en OP_RETURN-utdata som forplikter seg til en andre Merkle-rot av wtxid-er (BIP141). Så witness er også dekket av arbeidsbevis.

Headers først

Fordi headere er små, kan en node laste ned alle (nesten en million headere, godt under 100 MB) og sjekke arbeidsbeviset før den laster ned blokker.