Proof of Work i Bitcoin

Bitcoin-graving i Dale (2018)

Denne veka har eg delteke på eit PhD-seminar i regi av Høgskolen i Molde, som "blokkjede-ekspert". Det har vore ein interessant veke saman med 10 PhD-studentar og 4-5 rettleiarar og forelesarar. Det heile godt leia av førsteamanuensis Bjørn Jæger. 

Dei fleste stipendiatane har ikkje blokkjede som tema for doktorgraden, men Bjørn har likevel tenkt at eit kurs i blokkjedeteknologi (kurset heiter "PhD Seminar on Blockchain Applications in Supply Chain Management"). I løpet av kurset skal stipendiatane læra om blokkjedeteknologi (forelesingar), lesa gjennom ein del artiklar og presentera dei, og begynna arbeidet med ein publikasjon innan emnet. Det er ganske intensivt og krev mykje av deltakarane, men dei ser ut til å klara det fint.

Misforståelsar om blokkjedesikkerheit
Eg har følgt kurset, gitt innspel og delteke i diskusjonane og også halde eit lite innlegg basert på ei undersøking eg gjorde av 100 blokkjede-relaterte artiklar henta frå Web of Science. Eg undersøkte korleis artiklane omtalar sikkerheit i blokkjedeteknologien, og då basert på konsensus-metoden proof of work (PoW). Resultatet var ganske nedslåande: av dei 100 artiklane fann eg at heile 30 hadde ei feilaktig framstilling av sikkerheitsmekansimane i PoW-styrte blokkjeder. Den vanlegaste feilen var samanblanding av endrings-synleg (tamper evident) og endrings-sikker (tamper resistant). Meir om dette seinare.

For liten 'nonce'?
I samband med presentasjonen begynte eg å fundera på PoW-prosessen i Bitcoin. I omtalen av denne prosessen heiter det at felta i blokk-hovudet (block header) blir hasha med SHA-256-metoden for å komma fram til ein verdi som er mindre enn oppgitt størrelse (difficulty target). Det er ein prøving og feiling-metode der verdiar må endrast for å rekna ut nye hash-verdiar. Feltet 'nonce' blir brukt til å endra ein teljar for å få nye verdiar. Feltet er 4 bytes heiltal (2³²), noko som gir 4.294.967.296 mulege kombinasjonar (vel 4 milliardar). Ei vanleg Bitcoin-maskin i dag klarer fort 100 Th/s (100 tera-hash/sek.), noko som betyr at å rasa gjennom nonce-rommet tek mindre enn 1 millisekund. Kva skal gravarane då gjera? Eg spurde studentane om det, men kunne ikkje godt forventa at dei skulle klara å svara på det.

Svaret ligg i coinbase-transaksjonen, den første transaksjonen i alle nye blokker. Feltet for coinbase-skriptet har frå 2-100 byte plass og dei 8 første byta blir brukte som ein ekstra nonce. Det gir 2³² + 2⁶⁴) = 2⁹⁶ handlingsrom, og det er eit tal med 28 nullar bak. Om det også skulle bli for lite, kan ein begynna å triksa med tidsstemplinga. Dei andre felta i blokk-hovudet kan ikkje endrast på.

I figuren over har eg prøvt å få fram at (delar) av coinbase-transaksjonen også inngår i det som blir rekna hash-verdi av. Det er ikkje ofte det kjem fram i litteraturen.