Szerző: James

Elgondolkodtál már valaha azon, hogy vajon pontosan mi is zajlik a blokkláncban? A Bitcoin wikin persze van erről egy áttekintő jellegű szócikk, de a dolog igazi velejét mégiscsak maguk a nyers bájtok jelentik. Jelen cikkben az ősblokkot alkotó bájtokon foglak végigvezetni, elmagyarázva minden egyes részletének a tartalmát és jelentőségét az alapoktól kezdve. Ezt az írást elsősorban azoknak szánom, akik már tudnak valamennyit a Bitcoin működéséről, és szeretnének még többet is megtudni róla. Ha azonban profi informatikus vagy, aki kívülről-belülről, oda-vissza ismeri a Bitcoint, akkor valószínűleg nem fogsz itt már túl sok újdonságot találni.

Ez a poszt eredetileg egy halom jegyzetként kezdte a pályafutását, amit magamnak készítettem a protokollról, de ahogy egyre jobban terebélyesedett az anyag, végül úgy döntöttem, hogy akkor már rendesen összerakom és közzéteszem őket. Többhelyütt is el lehetett volna kalandozni a még apróbb részletek felé, de igyekeztem uralkodni magamon, és inkább csak a témába vágó linkekkel helyettesíteni az ilyen potenciális kitérőket. A forráskód-hivatkozások alapját a hivatalos kliens 0.5.0-s verziója adja.

Kedvenc tanulási stratégiám az absztrakcióktól való lehető legteljesebb megszabadulás, hogy a maga nyers valóságában láthassam mindazokat a mechanizmusokat, amelyek működtetik a kérdéses rendszert. Remélem, mások is hasznosnak találják majd ezt a megközelítést a Bitcoin protokolljának és forráskódjának alaposabb kivesézéséhez és megértéséhez. (Bár a magam részéről elsősorban a protokoll megértésére törekedtem anélkül, hogy túl sok C++-t kelljen megemésztenem.)

Lássunk hát neki!

Ha belenézel a Bitcoin-installációd adatkönyvtárába (Ubuntun: ~/.bitcoin), úgy ott két fontos fájlt is találhatsz, jelesül a blkindex.dat-ot és a blk0001.dat-ot. Előbbi a blokkindex, utóbbi pedig a blokklánc.

(És hogy miért blk0001.dat? Azért, mert a kliens igyekszik 2GB alatt tartani a blokklánc helyigényét, hogy ne kerüljön összeütközésbe a fájlrendszerek korlátaival (main.cpp, 1461. sor). Lehet, hogy a jövőben már találkozol majd blk0002.dat-tal, blk0003.dat-tal, és így tovább… vagy, a nagyon távoli jövőben talán végre teljesen elavulnak majd a régi fájlrendszerek és a 32 bites gépek, így nyugodtan használhat a kliens egyetlen fájlt is… vagy pedig valami teljesen más módon tárolja majd a blokkláncot.)

A blokkindex egy eszközfájl, ami a blokkláncon belüli nyers adatkeresés folyamatát pörgeti fel igen hatékonyan. Maga az index pedig nem más, mint egy Btree formátumú Berkeley adatbázisfájl:

$ file ~/.bitcoin/blkindex.dat
/home/james/.bitcoin/blkindex.dat: Berkeley DB (Btree, version 9, native byte-order)

A blk0001.dat fájlnak nincs adatbázis-szerkezete; ez csupán a klienshez beérkező blokküzenetek füzére. Jelen cikk szempontjából ez a fájl az, ami igazán érdekes lesz számunkra. Vegyük hát elő a hexdumpot és lássunk neki a mókának!

$ hexdump -n 300 -C blk0001.dat
00000000 f9 be b4 d9 1d 01 00 00 01 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 3b a3 ed fd |............;...|
00000030 7a 7b 12 b2 7a c7 2c 3e 67 76 8f 61 7f c8 1b c3 |z{..z.,>gv.a....|
00000040 88 8a 51 32 3a 9f b8 aa 4b 1e 5e 4a 29 ab 5f 49 |..Q2:...K.^J)._I|
00000050 ff ff 00 1d 1d ac 2b 7c 01 01 00 00 00 01 00 00 |......+|........|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff |................|
00000080 ff ff 4d 04 ff ff 00 1d 01 04 45 54 68 65 20 54 |..M.......EThe T|
00000090 69 6d 65 73 20 30 33 2f 4a 61 6e 2f 32 30 30 39 |imes 03/Jan/2009|
000000a0 20 43 68 61 6e 63 65 6c 6c 6f 72 20 6f 6e 20 62 | Chancellor on b|
000000b0 72 69 6e 6b 20 6f 66 20 73 65 63 6f 6e 64 20 62 |rink of second b|
000000c0 61 69 6c 6f 75 74 20 66 6f 72 20 62 61 6e 6b 73 |ailout for banks|
000000d0 ff ff ff ff 01 00 f2 05 2a 01 00 00 00 43 41 04 |........*....CA.|
000000e0 67 8a fd b0 fe 55 48 27 19 67 f1 a6 71 30 b7 10 |g....UH'.g..q0..|
000000f0 5c d6 a8 28 e0 39 09 a6 79 62 e0 ea 1f 61 de b6 |\..(.9..yb...a..|
00000100 49 f6 bc 3f 4c ef 38 c4 f3 55 04 e5 1e c1 12 de |I..?L.8..U......|
00000110 5c 38 4d f7 ba 0b 8d 57 8a 4c 70 2b 6b f1 1d 5f |\8M....W.Lp+k.._|
00000120 ac 00 00 00 00 f9 be b4 d9 d7 00 00 |............|
0000012c

Ez a hexdump “kanonikus hex+ascii nézet” üzemmódja. Minden egyes sor 16 bájtot jelenít meg a vizsgált fájlból. Balról jobbra haladva az egyes sorokon először a fájl kezdetétől számított offsetet látjuk, majd 16 bájtot, melyek mindegyikét két hexadecimális karakter jeleníti meg, majd pedig ugyanezt a 16 bájtot ASCII karakterbe dekódolva, ahol csak lehetséges. A meg nem jeleníthető karakterek helyén csak egy-egy pontot látunk. A függőleges vonal-karakterek nem részei az adathalmaznak; ezek csak arra szolgálnak, hogy elválasszák a hex-nézetet az ASCII-nézettől.

Mágikus hálózati azonosító

Az f9 be b4 d9 az a mágikus szám, amely Bitcoin-protokoll-üzenetként azonosítja azt, ami utána következik. Érdemes megjegyezni, hogy a blokk minden száma “kicsi a végén” (little-endian) bájtsorrendben kerül megjelenítésre (a portszám és az IP-cím “nagy a végén”-ben (big-endian), de azok nem szerepelnek a blokk-üzenetben), így ez a négy bájt 0xD9B4BEF9, avagy, tizes számrendszerben (dec), 3.652.501.241 értéket képvisel. A forráskód szerint azért választották éppen ezt a számot, mert normál adatban igen valószínűtlen az előfordulása (main.cpp, 1760. sor).

Megjegyzendő továbbá, hogy a mágikus hálózati azonosító nem része a blokknak; egyetlen célja, szerepe és funkciója az egyes blokkok egymástól való elválasztó. Tekintve, hogy az egyes blokkok hossza is rögzítésre kerül, és hogy van még egy indexfájl is, ezt akár minden további nélkül el is hagyhatnánk. Ezzel a takarékoskodással azonban még akkor is csak 800.000 bájtot, vagyis 0,76 MiB-ot spórolhatnánk meg, ha a blokklánc már 200.000 blokkból állna (200.000 x 4 bájt). Ennél jóval több helyet takaríthatunk meg másutt.

Blokkhossz

Az 1d 01 00 00 (0x0000011d hex, 285 dec) a blokk bájtokban mért hosszát jelöli. Mivel erre a célra összesen négy bájt áll rendelkezésre, így egyetlen blokk sem lehet nagyobb 2³² – 1 = 4.294.967.295 bájtnál, vagyis durván 4 GiB-nál. Elméletben. Gyakorlatban a jelenlegi kliens még 1 MB-nál nagyobb blokkokat sem fogad el (main.h, 30. sor).

Értelemszerűen a blokk hossza sem része magának a blokknak.

Blokkformátum verzió

A 01 00 00 00 (0x00000001 hex, 1 dec) a blokkformátum verzió. Ez független a protokoll- és kliensverziótól, amelyeket külön-külön is lehet növelni. A már meglévő blokkok blokkformátum verziója azonban nem változtatható meg, mivel ez esetben a hashük is megváltozna és ezzel máris megtörne a blokkokat egymással összekapcsoló hashláncolat.

Az előző blokk hashe

Mivel most az első, vagyis az ősblokkot vizsgáljuk, ezért előző blokk hashére itt most pont nem láthatunk példát. Bármely más blokk esetében itt értelemszerűen az azt megelőző blokk 32 bájtos hashét találhatjuk, ám az ősblokk esetében ugyanitt csak 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00-t láthatunk.

Ezen a ponton megjegyzendő, hogy bár rendkívül valószínűtlen ugyan, de elméletileg előfordulhat az is, hogy egy blokk hashe ténylegesen ugyanezt az értéket, vagyis abszolút nullát adjon ki. Mi több, a nehézség növekedésével ennek a tényleges bekövetkezte az idő múlásával csak egyre valószínűbb lesz. Emiatt vélhetőleg korrigálni kellene a protokollt annyiban, hogy az abszolút nullás hasht tekintse érvénytelennek, megőrizve így azt kizárólag az ősblokkban használatos és érvényes őrző értéknek.

Merkle-gyökér

A 3b a3 ed fd 7a 7b 12 b2 7a c7 2c 3e 67 76 8f 61 7f c8 1b c3 88 8a 51 32 3a 9f b8 aa 4b 1e 5e 4a a jelen blokk tranzakcióit rendszerező hashek merkle-fájának gyökérhashe.

Időbélyegző

A 29 ab 5f 49 (0x495fab29 hex, 1.231.006.505 dec) a blokk létrehozásának időpontját rögzítő időbélyegző. Mivel ez az érték már a blokk részét képezi, ezért a bányászati folyamat során már nem fog változni. Ebből következően nem azt az időpontot jelöli, amikor a már elkészült blokk ténylegesen közzé lett téve, hanem azt, amikor összegyűjtötték az azt alkotó tranzakciókat. “Néhány másodpercenként” azonban (main.cpp, 3088. sor) mégis frissítésre kerül, hogy ne maradjon le túlságosan.

Ez a mező Unix-időben adja meg az időt: az 1.231.006.505 annyit tesz, hogy 2009, január 3., 18:15:05 UTC. (Az időzóna-információ nem a kód része, hanem alapértelmezetten UTC-vel dolgozik a rendszer). Ezt a mezőt a rendszer jelöletlen egész számként kezeli (main.h, 765. sor), következésképp a maximális értéke 4.294.967.295, vagyis megközelítőleg 2106. február 7. lehet, így a protokollt még ezen időpont előtt frissíteni kell majd!

Bitek

Az ff ff 00 1d (0x1d00ffff hex, 486.604.799 dec) a célszámot, vagyis azt az értéket jelöli, amelyet a blokk fejlécének nem szabad átlépnie a blokk sikeres kibányászásához. Ez a Bitcoin egyik jellegzetessége.

Nonce

Az 1d ac 2b 7c egy, a bányászati folyamat során generált véltelen szám. Egy-egy blokk sikeres kibányászásának kulcsa a fejlécének a hashelése; ha az eredményül kapott hash-érték nem kisebb vagy egyenlő a célszámnál/-mal, akkor a bányászprogram megnöveli a nonce-ot, és úgy számolja vele újra a hasht. Ezt a folyamatot általában többmilliárdszor kell elismételnie egymás után, mire végre talál egy olyan számot, ami kellően alacsony hash-értéket eredményez.

Tranzakciószámláló

A 01 egy változó hosszúságú egész szám, amely az ebbe a blokkba foglalt tranzakciók számát jelöli. A végtelenségig azonban nem változtatható a hosszúsága, mivel egy jelöletlen egész számnak legfeljebb 8 bájt áll rendelkezésére, így a felső határ egész pontosan 18.446.744.073.709.551.615 – ami pedig azért elég sok tranzakciónak biztosít helyet egyetlen blokkban.

Soha egyetlen blokk sem lehet “üres”, vagyis nem tartalmazhat nulla tranzakciót; legalább egy mindig lesz benne: a blokk legenerálásáért járó jutalmat kifizető tranzakció.

És amint azt ebből a számból láthatjuk, ebben a blokkban csak egy tranzakció van, így ezután már csak ennek az egy tranzakciónak az alkotórészei következnek.

Tranzakció verziószáma

A 01 00 00 00 (0x01 hex, 1 dec) a tranzakció adatformátumának verziószáma. A blokkformátum verziószámnál már említett okok miatt ez sem változtatható a protokoll vagy a kliens verziószámával együtt.

Bemenetek száma

A 01 a tranzakció bemeneteinek száma. Ez is egy változó hosszúságú egész szám, azonban ennek nincs praktikus felső határa.

Bemenet

Ehhez mutatok mégegy kivonatot a hexdumpból, linkekkel együtt, hogy jobban el lehessen mélyedni a tranzakció bemeneti részleteiben:

00000050 ff ff 00 1d 1d ac 2b 7c 01 01 00 00 00 01 00 00 |......+|........|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff |................|
00000080 ff ff 4d 04 ff ff 00 1d 01 04 45 54 68 65 20 54 |..M.......EThe T|
00000090 69 6d 65 73 20 30 33 2f 4a 61 6e 2f 32 30 30 39 |imes 03/Jan/2009|
000000a0 20 43 68 61 6e 63 65 6c 6c 6f 72 20 6f 6e 20 62 | Chancellor on b|
000000b0 72 69 6e 6b 20 6f 66 20 73 65 63 6f 6e 64 20 62 |rink of second b|
000000c0 61 69 6c 6f 75 74 20 66 6f 72 20 62 61 6e 6b 73 |ailout for banks|
000000d0 ff ff ff ff 01 00 f2 05 2a 01 00 00 00 43 41 04 |........*....CA.|

A bemeneti tranzakció hashe

A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a bemenetiként meghivatkozott tranzakció hashe lenne, de mivel ez a blokk legenerálásáért járó jutalmat kifizető tranzakció, ezért itt ilyen nincs.

Bemeneti tranzakció indexe

Az ff ff ff ff a meghivatkozott bemeneti tranzakció egy meghatározott kimenetének az indexe. Mint tudjuk, az egyes tranzakcióknak számos kimenete lehet, és ezek egyike-másika (vagy akár mindegyike vagy egyike sem) lehet az azt követő tranzakciók bemenete is egyben. Ha ez az érték nulla, úgy az a meghivatkozott tranzakció első kimenetét jelöli. Jelen esetben azonban az itt álló érték a -1 megfelelője; ez egy amolyan dugó-érték, mivel itt nincs bemeneti tranzakció.

Megjegyzésre érdemes azonban, hogy legalábbis elméletben egy előző tranzakciónak valóban lehetne 0xffffffff + 1 (dec 4.294.967.296) kimenete, de ha a 0xffffffff értéket őrző értékként használjuk, akkor sehogyan sem tudnánk hivatkozni a 4.294.967.296. kimenetre, ami így elveszne. Szerencsére azonban a 4 GiB-ban meghatározott maximális blokkméret eleve lehetetlenné teszi ilyen sok kimenet használatát.

Válaszszkript hossza

A 4d (dec 77) az ezt követő szkript hossza. Ez is változó hosszúságú egész szám, így elméletben igen hosszú szkriptek is támogatottak.

Válaszszkript

Ez talán az egész blokk legérdekesebb és legizgalmasabb része: ez az a szkript, amely bizonyítja, hogy ez a tranzakció valóban jogosult az általa meghivatkozott bemenetek használatára. Ha még nem vagy tisztában a Bitcoin szkriptrendszerének lehetőségeivel, úgy javaslom, hogy alaposan tanulmányozd át az idevágó wiki-oldalt. Tartsd észben azonban azt is, hogy az opkódok legtöbbje még le van tiltva, és majd csak fokozatosan válnak használhatóvá, ahogyan megoldják a biztonságos alkalmazásukat. Ebből következően a kliens által felismerhető és elfogadható tranzakciótípusok száma egyelőre erősen korlátozott. Íme a szkript újra, félkövéren kiemelve:

00000080 ff ff 4d 04 ff ff 00 1d 01 04 45 54 68 65 20 54 |..M.......EThe T|
00000090 69 6d 65 73 20 30 33 2f 4a 61 6e 2f 32 30 30 39 |imes 03/Jan/2009|
000000a0 20 43 68 61 6e 63 65 6c 6c 6f 72 20 6f 6e 20 62 | Chancellor on b|
000000b0 72 69 6e 6b 20 6f 66 20 73 65 63 6f 6e 64 20 62 |rink of second b|
000000c0 61 69 6c 6f 75 74 20 66 6f 72 20 62 61 6e 6b 73 |ailout for banks|

Az első 04 arról tájékoztatja az értelmezőt, hogy az utána következő négy bájt verembe való adat. Ez a négy bájt pedig (ff ff 00 1d) a korábban is látott célszámot jelképezi. A 01 azt jelöli, hogy a következő egy bájt – a 04 – szintén verembe való. Hasonlóképp, a 45 az azt követő 69 bájtot utalja a verembe. Amint azt láthatjuk az ASCII-megjelenítésből, ez a következő 69 bájt a “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks” (= The Times, 2009. január 03.: A kancellár hamarosan újabb mentőövet dob a bankoknak) sztring.

És hogy ez a sztring miért van itt? Talán azt a vízválasztó pillanatot jelöli a pénzügyi történelmünkben, amikor már mindenképp Kellett Tenni Valamit. De az is lehet, hogy csak annak a bizonyítékául áll itt, hogy a Bitcoint mindenképpen ennek a cikknek a leközlését követően indították be.

És itt ér véget a szkript. Nem csinált ugyan túl sok mindent, de tekintve, hogy ez amúgy is csak egy érmegeneráló tranzakció, ezért nem is kell tartalmaznia a normál tranzakciókban egyébként mindig megtalálható aláírásellenőrző mechanizmusokat. Ez a szkript bármilyen tetszés szerinti adatot a verembe lökhet, és ezt arra használják fel, hogy üzeneteket illesszenek be a blokkláncba. Ez a blokkot sikeresen legeneráló bányász előjoga.

Ezt pedig azért neveztem válaszszkriptnek, mert általában ez ad választ egy meghivatkozott kimenet szkriptjének a kihívására.

Szekvenciaszám

Az ff ff ff ff a tranzakciócsere lehetőségét biztosító “szekvenciaszám”. Elméletben ez úgy működik, hogy a tranzakciódhoz meghatározol egy jövőbeli záridőt (lásd lejjebb) – amely időhatárig így még szabadon lecserélheted ezt a tranzakciót egy másik, magasabb szekvenciaszámúra. Ha permanensen le akarod zárni a tranzakciót, akkor ehhez a kliens a legnagyobb négybájtos egész számra, a 0xffffffff-re állítja be a szekvenciaszámot. Mivel azonban egyelőre egyetlen kliens sem használja ezt a csere-zárás funkciót, ezért jelenleg kivétel nélkül minden tranzakció alapértelmezetten zárt.

Kimenet

Íme egy újabb elmélyedésre érdemes újrafogalmazás:

000000d0 ff ff ff ff 01 00 f2 05 2a 01 00 00 00 43 41 04 |........*....CA.|
000000e0 67 8a fd b0 fe 55 48 27 19 67 f1 a6 71 30 b7 10 |g....UH'.g..q0..|
000000f0 5c d6 a8 28 e0 39 09 a6 79 62 e0 ea 1f 61 de b6 |\..(.9..yb...a..|
00000100 49 f6 bc 3f 4c ef 38 c4 f3 55 04 e5 1e c1 12 de |I..?L.8..U......|
00000110 5c 38 4d f7 ba 0b 8d 57 8a 4c 70 2b 6b f1 1d 5f |\8M....W.Lp+k.._|
00000120 ac 00 00 00 00 f9 be b4 d9 d7 00 00 |............|
0000012c

Kimenetszámláló

A 01 a kimenetek száma, változó hosszúságú egész szám formátumban.

Kimenet értéke

A 00 f2 05 2a 01 00 00 00 (hex 0x000000012a05f200, dec 5000000000) az elküldött “bitcoinok” – illetve pontosabban alapegységek – száma, mivel egy bitcoin 100000000 alapegységből áll. Ez tehát egy 50 BTC-t (a blokkért járó jutalmat) küldő tranzakció. Ennek a mezőnek a mérete fix, 8 bájtban rögzített, ami így az egyes bitcoinok jelenlegi oszthatóságának mértékét is meghatározza. Ha valaha is annyira értékessé válnának már az egyes bitcoinok, hogy még több tizedesjegyű felosztást kellene használni, akkor ezt a mezőt kell majd kibővíteni. Én a magam részéről valamiféle tetszőleges precizitást biztosító megoldást részesítenék előnyben.

Kihívó szkript hossza

A 43 (dec 67) az ezt követő válaszszkript hossza.

Kihívó szkript

A 41 04 67 8a fd b0 fe 55 48 27 19 67 f1 a6 71 30 b7 10 5c d6 a8 28 e0 39 09 a6 79 62 e0 ea 1f 61 de b6 49 f6 bc 3f 4c ef 38 c4 f3 55 04 e5 1e c1 12 de 5c 38 4d f7 ba 0b 8d 57 8a 4c 70 2b 6b f1 1d 5f ac a szkript második fele, a válasz a kihívásra. Ez bizonyítja azt, hogy valóban jogosult vagy a bemeneti tranzakció elköltésére. Opkódokra lebontva:

A 41 (dec 65) arról a tájékoztatja a szkript-értelmezőt, hogy a következő 65 bájt verembe való adat. Mivel pedig már csak 66 bájt van vissza a szkriptből, ezért az utolsóhoz ugorva az ac (dec 172) értéket találjuk, vagyis az OP_CHECKSIG opkódot. Ez arra utasítja az értelmezőt, hogy az ezt megelőző két verem-elemet aláírásként és nyilvános kulcsként kezelje, és ellenőrizze, hogy az aláírás valóban a nyilvános kulcsnak megfelelő titkos kulccsal történt-e. De honnan jön ez a másik verem-elem, ha csak egyet utaltunk oda (a 65 bájtnyi adatot)? Az ennek a tranzakciónak a párjául szolgáló másik tranzakció válaszszkriptjéből: a következő tranzakció aláírása (nagyjából és lényegében; részleteket lásd itt). Ennek a tranzakciónak a szkriptje intézi a kihívást – és hogy egy nyilvános kulcsból kiindulva milyen aláírás nyomán adhat az OP_CHECKSIG “igaz” eredményt a következő tranzakcióval való összevetés nyomán? Nos, ilyen aláírást csak a megadott nyilvános kulcshoz illő titkos kulcs tulajdonosa tud generálni. Ezért nem költhetik el mások a te bitcoinjaidat.

És hogy mit tartalmaz a 65 bájtnyi adat? Egy ECDSA nyilvános kulcs szabványos megjelenítését: a 04-es bájtot követő két 32 bájtos “nagy a végén” egész szám az secp256k1-görbe egy pontjának koordinátáit adja meg. Bárki, aki szeretne takarékoskodni a hellyel a blokkláncában, valószínűleg elhagyhatja ezt a 04-et és kikövetkeztetheti a jelenlétét a tranzakció verziószámából.

A nyilvános kulcsot gyakran jelenítik meg az SHA-256 hashének a RIPEMD-160 hasheként, összefűzve egy verziószámmal és egy ellenőrzőértékkel (checksum), és mindezt Base 58-ban megjelenítve. Jelen esetben ez 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa – Satoshi első Bitcoin-címe. Amint pedig azt láthatjuk a Block Exploreren, ezeket a bitcoinokat még nem használták fel…

Záridő

A 00 00 00 00 a záridő. Ez az érték egyelőre minden tranzakciónál nulla, mivel ezt a funkciót még nem építették bele egyetlen kliensbe sem. Az alapelképzelés itt az (main.h, 40. sor), hogy az 500.000.000-ig terjedő értékek blokkszámot jelölnek, míg az afölöttiek azt az UNIX időbélyegzőt, amelytől kezdve a tranzakció lezárul és többé már nem lesz cserélhető.

Érdekesség: az 500.000.000. blokkhoz megközelítőleg valamikor 11.515 (mint évszám) környékén érünk majd el, UNIX időbélyegzőként pedig az 500.000.000 megközelítőleg 1985. április 11.-ét jelöli, ami kellően biztonságos távolságra van a jelenlegi blokklánc indulásától.

És ezután?

Ha visszanézel a jelen cikk legelején idézett hexdumpra, láthatod, hogy ezután az f9 be b4 d9 bájtok következnek, amelyek egy új blokk elejét jelölik. Mostanra, 2012 januárjára 160.000-nél is több blokk gyűlt már össze ezen első után. Az 1.000.000. blokkhoz feltehetőleg 2031-ben jutunk el, amikor a valaha is kibányászható bitcoinok több, mint 99%-a kibocsátásra került már.

Ami hiányzik

Nincs blokkszám. Ha bárhol, így például a Block Exploreren blokkszámokkal találkozol, úgy az egyszerűen csak egy adott blokk offsetjét jelöli a leghosszabb érvényes láncban.

Zárszó

Bízom benne, hogy lesz majd valaki, aki hasznosnak találja ezt a posztot. A megírásával magam is jobban megérthettem a Bitcoin protokollját. Természetesen hálával várok minden esetleg szükséges korrekciót és pontosítást is.

Forrás: JL6

A lap szövege Creative Commons Nevezd meg! – Ne add el! – Így add tovább! 3.0 licenc alatt áll, felhasználni csak forrásmegjelöléssel, és ide mutató linkkel szabad.