Logička hijerarhija determinističkih novčanika (BIP44)

BIP32 ostavlja previše slobode u implementiranje logičke strukture HD novčanika što može uzrokovati probleme prilikom restoracije novčanika. BIP44 predlaže logičku strukturu na više razina.

Struktura

m / purpose' / coin_type' / account' / change / address_index
Apostrof označava da se radi o ojačanom izvodu ključa. Svaka razina ima određeno značenje i ondnosi se na indeks za BIP32 CKD.

Purpose (svrha)

Polje 'svrha' je konstanta koja iznosi 44 (0x8000002C). Označuje da se radi o stalastoj strukturi kakvu definira ovaj BIP.

Coin_type (vrsta kriptovalute)

Ovo polje označuje za koju se kriptovalutu izvode ključevi (Bitcoin, Litecoin, Dogecoin...). Npr. oznaka Bitcona je 0 (0x80000000), Litecoina 2 (0x80000002) i sl. Sve oznake mogu se pronaći ovdje.

Account (račun)

Na ovoj se razini ključevi dijele prema identitetima korisnika.tako da se različiti računi nikad ne pomiješaju. Brojevi računa kreću od 0 te se povećavaju.

Change (kusur)

0 označuje da se radi o normalnoj adresi na koju korisnik prima sredstva. 1 označuje da se radi o adresi nakoju korisnik prima ostatak sredstava (kusur) poslanih na neku adresu.

Address_index (indeks adresa)

Indeksi adresa počinju od nule te se inkrementiraju.

Bitovi verzija (BIP9)

Blokovi originalnog protokola Bitcoin imali su verziju 1. Polje za verziju bloka veliko je 32 bita, a zapisuje se u little-endian formatu. Pojavom BIP 34, verzija je povećana na 2 te je uveden mehanizam za provođenje soft-fork promjena. Mehanizam je provjeravao koliko blokova na 1000 ima zadanu verziju bloka što je signaliziralo da je promjena softvera prihvaćena. Problem ove metode je što podržava samo jedan soft-fork u paraleli. BIP 66 povećao je verziju bloka na 3, a BIP 65 na 4.

BIP 9 uvodi nov mehanizam provođenja soft-fork promjena te nov način tretiranja polja verizije u bloku. Verzija se od sada tretira kao vektor bitova u kojem se svaki bit može koristiti za praćenje verzije soft-forka. U dvotjednom (retarget) periodu zbrajaju se bitovi pojedinih verzija kako bi se ustanovilo ima li pojedina promjena dovoljnu podršku rudara (jesu li prešli "prag").

Specifikacija

 

Svaki soft-fork obilježavaju sljedeći parametri:

• Ime: Vrlo kratko opisuje soft-fork (npr. bip N).
• Bit: Označuje koji će se bit u verziji bloka koristiti za praćenje konkretnog soft-forka. Bira se iz skupa [0, 28].
• Starttime: Vrijeme u budućnost od kada bit počinje vrijediti specificirano kao srednje proteklo vrijeme (medium time past).
• Timeout: Specificira vrijeme nakon kojeg se prihvaćanje soft-forka smatra neuspjelim.

 

Stanja

Uz svaki blok i soft-fork vežu se stanja:

• DEFINED – svaki soft-fork započinje u ovom stanju.
• STARTED – svi blokoi za koje je prošlo starttime.
• LOCKED_IN – svi blokovi kojih nakon stanja STARTED u dvotjednom periodu ima barem za prijelaz praga određene verzije.
• ACTIVE – svi blokovi nakon stanja LOCKED_IN.
• FAILED – svi blokovi za koje prošao timeout, a LOCKED_IN nije postignut.

 

Bitovi kao zastavice

Blokovi u stanju STARTED postavljaju bitove u polju verzije na 1 kako bi signalizirali koji soft-fork podržavaju. Vršna tri bita takvih blokova moraju biti 001. Budući da su BIP 34, 66 i 65 imali verzije 00000000000000000000000000000010 (2), 00000000000000000000000000000011 (3) i 00000000000000000000000000000100 (4), odnosno u little-endian formatu 10000000000000000000000000000000, 11000000000000000000000000000000 i 00100000000000000000000000000000, mogu se koristiti samo bitovi od 3. do 31., odnosno svaka verzija mora imati tri vršna bita 001.

Dakle, mogući raspon bitova je [0x20000000, 0x3FFFFFFF]. Do tog se raspona dolazi ako se uzme najmanja moguća verzija u little-endian formatu 00100000000000000000000000000000 (0x20000000) i najveća moguća verzija 00111111111111111111111111111111 (0x3fffffff). To predstavlja 29 mogućih paralelnih soft-forkova.

Prijelazi između stanja

 

 

 

Svi blokovi unutar dvotjednog perioda imaju isto stanje. Iduće stanje ovisi o prethodnom. Prag za prijelaz u stanje LOCKED_IN je 1915 (95%) blokova.

Trošenje Bitcoin transakcije (dio drugi)

9. scriptPubKey

Ovo polje sadrži uvjete otključavanja gorenavedenih sredstava usmjerenih na neku bitcoin adresu. Ovo je polje usko vezano uz polje scriptSig (kao što je opisanu u člancima o Bitcoin skriptama). Zapisuje se u var_string big-endian formatu. Najčešće sadrži skriptu 76a914097072524438d003d23a2f23edb65aae1bb3e46988ac. Napisana je u skriptnom jeziku Bitcoina koji kad se deserijalizira kaže
DUP HASH160 <14> 097072524438d003d23a2f23edb65aae1bb3e469 EQUALVERIFY CHECKSIG
Detalji su opisani u člancima o Bitcoin skriptama. U ovo se polje prvo upisuje duljina skripte u bajtovima (u heksadecimalnom formatu) te zatim sama skripta.

Hex: "01000000

01 

eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2
01000000
76a914010966776006953d5567439e5e39f86a0d273bee88ac
ffffffff
01
605af40500000000
19
76a914097072524438d003d23a2f23edb65aae1bb3e46988ac"

10. Polje lock-time

Polje koje se može koristiti za vremensko zaključavanje transakcije. U slučaju da se transakcija može odmah potrošiti, polje je prazno. Veličine je četiri bajta te se zapisuje u little-endian formatu.

Hex: "01000000
    01
    eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2
    01000000
    76a914010966776006953d5567439e5e39f86a0d273bee88ac
    ffffffff
    01
    605af40500000000
    19
    76a914097072524438d003d23a2f23edb65aae1bb3e46988ac
    00000000"

11. Način potpisivanja transakcine (hashcode)

Ovom se zastavicom opsiuje kako će se transakcija potpisivati. Gotovo u svim slučajevima ova zastavica predstavlja sighash_all, odnosno potpisivanje svih ulaza i izlaza. Zastavica je veličine osam bajtova zapisanih u little-endian formatu.

Hex: "01000000

01

eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2
01000000
76a914010966776006953d5567439e5e39f86a0d273bee88ac
ffffffff
01
605af40500000000
19
76a914097072524438d003d23a2f23edb65aae1bb3e46988ac
00000000
01000000"

14. Hashiranje transakcije

Goreprikazani oblik transakcije spreman je za potpisivanje. Prije toga transakcija se sažima dvostrukim korištenjem funkcije SHA256(SHA256(tx)). Rezultat je

9302bda273a887cb40c13e02a50b4071a31fd3aae3ae04021b0b843dd61ad18e.

15. Potpisivanje transakcije

Transakcija se sada potpisuje privatnim ključem primatelja. Za to se koristi algoritam ECDSA, odnosno digitalni potpis zasnovan na eliptičkoj krivulji. Taj se potpis zatim enkodira u tzv. strogi DER format. Ovo je primjer takvog potpisa

0460221009e0339f72c793a89e664a8a932df073962a3f84eda0bd9e02084a6a95

67f75aa022100bd9cbaca2e5ec195751efdfac164b76250b1e21302e51ca86dd7eb

d7020cdc06. 

16. Popunjavanje polja scriptSig

Sada se može ispravno popuniti polje scriptSig iz petog koraka koje je do sada sadržavalo skriptu scriptPubKey. U polje scriptSig upisuje se ukupna duljina polja, duljina i potpis transakcije u DER formatu, hashcode (01 najčešće), duljina javnog ključa te sam javni ključ.

8c4930460221009e0339f72c793a89e664a8a932df073962a3f84eda0bd9e0208

4a6a9567f75aa022100bd9cbaca2e5ec195751efdfac164b76250b1e21302e51ca

86dd7ebd7020cdc0601410450863ad64a87ae8a2fe83c1af1a8403cb53f53e486d

8511dad8a04887e5b23522cd470243453a299fa9e77237716103abc11a1df3885

5ed6f2ee187e9c582ba6.

17. Micanje zastavice hashcode

U zadnjem koraku se miče zastavica hashcode s kraja transakcije jer je dodana u polje scriptSig iza potpisa transakcije.

Hex: "01000000

01

eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2
01000000
8c    4930460221009e0339f72c793a89e664a8a932df073962a3f84eda0bd9e02084

a6a9567f75aa022100bd9cbaca2e5ec195751efdfac164b76250b1e21302e51ca

86dd7ebd7020cdc0601410450863ad64a87ae8a2fe83c1af1a8403cb53f53e486

d8511dad8a04887e5b23522cd470243453a299fa9e77237716103abc11a1df38

855ed6f2ee187e9c582ba6
ffffffff
01
605af40500000000
19
76a914097072524438d003d23a2f23edb65aae1bb3e46988ac
00000000"

Trošenje Bitcoin transakcije (dio prvi)

Nakon što primatelj dobije bitcoine od pošiljatelja, kako se konstruira transakcija koja te bitcoine troši (šalje novom primatelju)?

Postupak konstruiranja nove transakcije sastoji se od više koraka i bit će prikazan u hex(string) formatu.

1. Verzija

Svaka bitcoin transakcija ima verziju. Verzija je uvijek "01". Polje u koje se zapisuje transakcija veličine je četiri bajta te se verzija zapisuje u little-endian formatu "01000000".

Hex: "01000000"

2. Broj ulaza

Nakon verzije dolazi broj i lista ulaza koje transakcija ima. Ulazi se referenciraju na izlaze prethodnih transakcija koje su poslane tom korisniku. Broj ulaza je cijeli broj varijabilne duljine (tzv. var_int), a najčešće zauzima jedan bajt. Za transakciju s jednim ulazom taj broj je "01".

Hex: "01000000

          01"

3. Indeks prethodne transakcije

Sada slijedi lista ulaza. Svaki ulaz u transakciju sastoji se od četiri dijela: indeks transakcije čiji se izlaz (odnosno bitcoini vezani uz taj izlaz) želi potrošiti, indeksa izlaza, potpisa te oznake niza (sequence). Indeks transakcije je zapravo dvostruki SHA256 hash prethodne transakcije. To je polje veličine 32 bajta te se zapisuje u little-endian formatu. Npr. takav hash može izgledati ovako
"eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2"
 

Hex: "01000000

01
eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2"

4. Indeks izlaza prethodne transakcije

Druga komponenta ulaza u transakciju, nakon indeksa prethodne transakcije, je indeks izlaza prethodne transakcije koji se želi potrošiti. Budući da transakcija može imati više od jednog izlaza, potrebno je označiti koji se točno od tih izlaza želi potrošiti. To je polje veličine četiri bajta te se zapisuje u little-endian formatu. Ako se radi o izlazu "01" to je "01000000".

 

Hex: "01000000

01

eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2

01000000 "

5. Polje scriptSig

Polje scriptSig u svakom ulazu dokazuje da primatelj ima pravo trošenja izlaza iz prethodne transakcije koji referenciraju goreopisani indeks prethodne transakcije i indeks izlaza. To polje sadrži potpis ove transakcije i javni ključ na koji su bitcoini poslani (iz kojeg je izvedena bitcoin adresa na koju su bitcoini poslani). Budući da je transakcija tek u nastajanju, umjesto potpisa transakcije, privremeno se kopira sadržaj polja scripPubKey.

Polje je varijabilne duljine i zapisano je u var_string big-endian formatu. Sadrži duljinu skripte u bajtovima te samu skriptu.

Hex: "01000000

01

eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2

01000000

76a914010966776006953d5567439e5e39f86a0d273bee88ac"

 

6. Oznaka niza (sequence)

Ovo polje uvijek ima maksimalnu vrijednost budući da se nikada nije koristilo onako kako je originalno bilo zamišljeno. Duljine je četiri bajta te se zapisauje u little-endian formatu. U budućnosti će se to polje koristiti za vremenski zaključane transakcije.

Hex: "01000000

01

eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2

01000000

76a914010966776006953d5567439e5e39f86a0d273bee88ac

ffffffff"

7. Broj izlaza

Osim broja ulaza, transakcija sadrži i broj izlaza. Izlazi sadrže adrese i bitcoine koji se na njih šalju. Kao i broj ulaza, broj je izlaza cijeli broj varijabilne duljine (tzv. var_int), a najčešće zauzima jedan bajt. Za transakciju s jednim izlazom taj broj je "01".

Hex: "01000000

01

eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2

01000000

76a914010966776006953d5567439e5e39f86a0d273bee88ac

ffffffff 

01"

8. Iznosi

Iznosi vezani uz pojedini izlaz zapisuju se u satoshijima. Polje je veličine osam bajtova te se prikazuje u little-endian formatu. Za iznos od 0.999 BTC, odnosno 99900000 satoshija to je 605af40500000000.

Hex: "01000000

01

eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2

01000000

76a914010966776006953d5567439e5e39f86a0d273bee88ac

ffffffff 

01
605af40500000000"

Vremenski zaključane transakcije: Primjeri

Zajamčeni polog (escrow)

Ako Alice i Bob žele zajedno upravljati poslom, zajednička sredtva mogu držati u 2-od-2 višepotpisnoj transakciji. No u slučaju smrti jedne strane, druga strana neće imati pristup zajedničkim sredstvima. Zato bi mogli zaposili odvjetnika Lennyja da bude treća strana u slučaju nezgode. No kod 2-od-3 višepotpisne transakcije, odvjetnik se može urotit s bilokojom stranom te ukrasti zajednička sredstva. U ovakvom se slučaju može iskoristiti operator CHECKLOCKTIMEVERIFY u scriptSig dijelu transakcije:

IF

    <sad + 3 mjeseca> CHECKLOCKTIMEVERIFY DROP

    <Lennyjev pubkey> CHECKSIGVERIFY

    1

ELSE

    2

ENDIF

<Alicin pubkey> <Bobov pubkey> 2 CHECKMULTISIG

Ovakva se transakcija može potrošiti u bilokojem trenutku ovako:

0 <Alicin potpis> <Bobov potpis> 0

Postupak trošenja je sljedeći:

 

0

Bobov potpis

Alicin potpis

0

 

 

Ovako izgleda stog nakon pokušaja trošenja gornje vremenski zaključane transakcije prije isteka roka valjanosti. Naredba IF provjerava prvi element na stogu te se izvršavanje dalje nastavlja ovisno o tom elementu. Na vrhu stoga je 0 koja se tretira kao neistina te se prelazi na ELSE dio naredbe koja na stog stavlja 2.

2

Bobov potpis

Alicin potpis

0

 

Izgled stoga nakon izvršavanja naredbe IF. Ovo je sada normalna 2-od-2 višepotpisna transakcija

0 <Bobov potpis> <Alicin potpis> 2 <Alicin pubkey> <Bobov pubkey> 2 CHECKMULTISIG

Zbog buga u naredbu CHECKMULTISIG, m-od-n višepotpisna transakcija uzima jedan više potpis nego je zapravo potrebno.

Nakon isteka roka valjanosti ovu je transakciju moguće potrošiti na sljedeći način:

0 <Alicin/Bobov potpis> <Lennyjev potpis> 1

1

Lennyje potpis

Alicin/Bobov potpis

0

 

Ovako izgleda stog nakon pokušaja trošenja gornje vremenski zaključane transakcije nakon isteka roka valjanosti. Na stogu je 1 koji se tretira kao istina te se prelazi na provjeru roka valjanosti. Rok valjanosti ističe tri mjeseca nakon nastanka transakcije.

sad + 3 mjeseca

Lennyjev potpis

Alicin/Bobov potpis

0

 

Na stog se stavlja rok valjanosti te se uspoređuje s poljem nLockTime transakcije koja taj izlaz želi potrošiti. Budući da je rok istekao, izlaz se smije potrošiti. Naredba DROP odbacuje gornji element stoga (u ovom slučaju rok valjanosti).

Zatim se uzima Lennyjev javni ključ s kojim naredba CHECKSIGVERIFY provjerava Lennyjev potpis na stogu. Ako je potpis ispravan na stog se na kraju stavlja 1.

1

Alicin/Bobov potpis

0

Sada je ovo 1-od-2 višepotpisna transakcija koja se može potrošiti pomoću Alicinog ili pomoću Bobovog potpisa

0 Alicin/Bobov potpis 1 <Alicin pubkey> <Bobov pubkey> 2 CHECKMULTISIG

Neinteraktivna vremenski zaključana nadoknada

U nekim je protokolima potrebna suradnja dvije strane da bi se potrošila neka transakcija. U slučaju nedostupnosti jedne strane, povrat novca (nadoknada) se vremenski zaključati kako bi se nakon isteka roka valjanosti vratio pošiljatelju. Takva transakcija u kojoj Alice šalje Bobu sredstva može izgledati ovako

 

IF

     <rok_valjanosti> CHECKLOCKTIMEVERIFY DROP

    1

ELSE

     2

ENDIF

<Alicin pubkey> <Bobov pubkey> 2 CHECKMULTISIG

Slično kao i u prethodnom primjeru, ovakva se transakcija može prije isteka roka potrošiti s

0 <Alicin potpis> <Bobov potpis> 0

U slučaju nedostupnosti jedne strane i nakon isteka roka valjanosti, transakcija se može potrošiti s

0 <Alicin/Bobov potpis> 1

Plaćanje za objavljivanje podataka

Postoje usluge koje omogućuju plaćanje za objavljivanje informacija. Osoba koja objavljuje informaciju prvo mora dokazati da kriptirani dokument sadrži tražene podatke, a zatim konstruirati transakciju koja će otkriti ključ za dekripciju podataka. Trenutačne implementacije takvih sustava omogućuju osobi koja objavljuje informaciju da nikad ne otkrije tajni ključ. Taj se nedostatak može riješiti korištenjem naredbe CHECKLOCKTIMEVERIFY:

IF

    HASH160 <hash160(tajni_ključ)> EQUALVERIFY

    <pubkey objavljivača> CHECKSIG

ELSE

     <rok valjanosti> CHECKLOCKTIMEVERIFY DROP

     <pubkey platitelja> CHECKSIG

ENDIF

Objavljivač informacije transakciju može potrošiti ovako:

<potpis objavljivača> <tajni ključ> 1

 

1

Tajni ključ

Pubkey objavljivača

Ovako izgleda stog nakon pokušaja trošenja transakcije. 1 se smatra istinom te se prelazi na verifikaciju tajnog ključa.

 

Tajni ključ

Pubkey objavljivača

Gornji element stoga se hashira funkcijom HASH160 te uspoređuje s hashem podatka u transakciji. U slučaju da su identični (objavljen je pravi tajni ključ), verificira se potpis objavljivača te je tajna otkrivena onome tko je platio za nju.

U slučaju da objavljivač ne objavi tajni ključ, platitelj može dobit povrat novca nakon isteka roka valjanosti:

 

0 <potpis platitelja>

 

0

potpis platitelja

Zbog 0 se pralazi u ELSE dio transakcije koji na stog stavlja rok valjanosti i uspoređuje ga s poljem nLockTime:

 

Rok valjanosti

Potpis platitelja

Ako je rok prošao, odbacuje se sa stoga te se verificira potpis platitelja te on dobiva uplaćeni novac natrag.

Vremenski zaključane transakcije (BIP 65)

Svaka bitcoin transakcija ima polje nLockTime. Zamišljeno je da sadrži vrijednost koja govori kada se transakcija može potrošiti u budućnosti. Vrijednost polja može se interpertirati na dva načina: ako je vrijednost manja od 500.000.000 tretira se kao visina bloka u kojem transakcija postane validna, a ako je vrijednost veća od toga, tretira se kao datum kada transakcija postaje validna (broj sekundi od 1. siječnja 1970.).

Takva se transakcija može uključiti u blok koji je na zadanoj ili većoj visini, odnosno čije je vrijeme pronalaska veće ili jednako onome u polju nLockTime. Problem je što se ne može garantirati da izlazi koje koristi transakcija s popunjem nLockTime poljem neće prije potrošiti neka druga transakcija.

Zato je definirana naredba CHECKLOCKTIMEVERIFY (odnosno redefinirana je naredba NOP2). Ona služi tome da se zaključaju pojedini izlazi iz transakcija koji će se potrošiti u budućnosti te prima jedan parametar: rok valjanosti. Kada se tako zaključani izlaz želi potrošiti, njegov se rok valjanosti uspoređuje s poljem nLockTime transakcije koja ga troši. Izlaz će se potrošiti samo ako je rok valjanosti manji od nLockTime. Transakcije zaključane s CHECKLOCKTIMEVERIFY mogu se normalno uvrstiti u blok.

Primjer zamrzavanja sredstava

Slijedi primjer skripte u skriptnom jeziku Bitcoina kojom je moguće zamrznuti sredstva sve dok ne istekne zadani rok valjanosti:


<rok valjanosti> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG


Transakcija koja će potrošiti ovaj izlaz mora imati nLockTime veći od roka valjanosti. Budući da se transakcija s takvim poljem može tek uključiti u blok čija je visina ili vrijeme veće od vrijednosti nLockTime, originalna će transakcija ostati nepotrošena do zadanog vremena. Nakon isteka roka valjanosti, transakcija se dalje normalno validira.

Zaobilaženje roka valjanosti

Rok valjanosti moguće je zaobići ako transakcija koja troši vremenski zaključani izlaz redne brojeve svojih izlaza postavi na maksimum (0xffffffff). To je zaostatak iz starih verzija protokola Bitcoin te operacija CHECKLOCKTIMEVERIFY provjerava vrijednosti rednih brojeva ulaza. Ako redni broj nije maksimum transakcija će moći normalno potrošiti izlaz ako je prošao rok valjanosti. U suprotnom, transakcija ne može potrošiti izlaz.

Detalji coinbase transakcije

Na početku svakog bloka transakcija nalazi se tzv. coinbase transakcija. Ona donosi nagradu onome tko je uspješno izrudario blok. Sama nagrada sastoji se od subvencije za blok (trenutačno 25 BTC) te od naknada za sve transakcije u bloku.

Primjer strukture coinbase transakcije je

Version	1
Inputs
Prevoius hash	0
Index	0xFFFFFFFF
ScriptSig	03dae7052f4249503130302f040e7164560902c8108999000000d3072f425443432f20
Sequence	0
Outputs
Value	2510629190
ScriptPubKey	76a9142c30a6aaac6d96687291475d7d52f4b469f665a688ac
Locktime	0

U odnosu na ostale transakcije, coinbase transakcija je pojednostavljena. Nema referencu na prethodnu transakciju jer stvara nove bitcoine, a ne preuzima već postojeće. Budući da se ne referira na prethodnu transakciju, nema niti indeks prethodnog izlaza.

Coinbase transakcija nije niti potpisana digitalnim potpisom nego se polje ScriptSig koristi kao tzv. extra nonce polje. Često polje nonce u zaglavlju transakcije nije dovoljno veliko da bi se moglo samo koristiti za pretraživanje svih mogućih vrijednosti noncea. Zato se ono dopunjava poljem ScriptSig u koje se upisuje dio noncea koji nije stao u zaglavlje. Na taj način rudari dobivaju više mogućnosti za kombiniranje.

BIP34

Osim što služi kao extra nonce, u prvi bajt polja ScriptSig zapisuje se i visina bloka u kojem se nalazi coinbase transakcija. To osigurava da je hash svakog idućeg bloka i transakcije jedinstven. Format zapisa je broj bajtova u visini te sama visina zapisana u little endian formatu. U gornjem primjeru to je "03dae705", odnosno "03" bajta za visinu te visina u little endian formatu "dae705", odnosno u big endianu 05e7da te u decimalnom formatu 387034. Blok 227835 je prvi blok takvog formata te on i svi sljedeći imaju verziju 2.