Források:

* Az eredeti Bitcoin-kliens forráskódja

Jelen dokumentációban a C99-es szabvány szerinti típus-elnevezéseket használtuk.

Gyakori szabványok

Hashek

A Bitcoin rendszere általában kétszeresen hashel. Legtöbbször SHA-256-tal, de néha RIPEMD-160-nal is, ha rövidebb hashre van szükség (például egy Bitcoin-cím létrehozásához).

A “hello” sztring például a következőképpen néz ki kétszeres SHA-256 kódolással:

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (első kör, SHA-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (második kör, SHA-256)

Bitcoin-címek esetében (RIPEMD-160) a következő lenne az eredmény:

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (első kör, SHA-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (második kör, RIPEMD-160)

Merkle-fák

A Merkle-fák bináris hash-fák. A Bitcoin Merkle-fái kétszeres SHA-256-ot használnak, és a következőképpen épülnek fel:

hash(a) = sha256(sha256(a))

hash(a) hash(b) hash(c)
hash(hash(a)+hash(b)) hash(hash(c)+hash(c))
hash(hash(hash(a)+hash(b))+hash(hash(c)+hash(c)))

Párba rendeződnek, az utolsó elem pedig duplázódik.

Aláírások

A Bitcoin elliptikus görbés digitális aláíró algoritmussal (ECDSA) írja alá a tranzakciókat.

Az ECDSA-hoz az secp256k1-es görbét használja innen.

A nyilvános kulcsok (a szkriptekben) 04 <x> <y>-ként vannak megadva, ahol a 32 bájtos x és y sztringek a görbe egy pontjának koordinátáit fejezik ki. Az s és r komponenseket az aláírások DER-kódolással csomagolják egyetlen bájtfolyamba (mivel az OpenSSL alapértelmezés szerint ilyet hoz létre).

Tranzakciók ellenőrzése

Lásd még: OP_CHECKSIG

Egy blokk első tranzakciója általában a generáló tranzakció, amelynek nincs “bemeneti” oldala, csak bitcoinokat generál (például a tranzakciós díjakból), amelyeket általában az adott blokk megfejtője kap meg. Ezeket “érmebázis-tranzakcióknak” nevezzük, és amennyiben blokkonként csak egyetlen egy van belőlük, úgy a Bitcoin-kliensek mindennemű szkript-végrehajtás nélkül elfogadják.

Nem-érmebázis-tranzakció esetén egyrészt az előző tranzakció hashei, másrészt pedig a másik tranzakció kimenetének a jelen tranzakció bemeneteként szolgáló indexe képezi az ellenőrzés bemeneti oldalát. Előbb a jelen tranzakció bemeneti, majd a hivatkozott tranzakció kimeneti oldalának szkriptje kerül végrehajtásra. A tranzakció akkor számít valódinak, ha a köteg legfelső eleme igaz.

Címek

A Bitcoin-címek valójában az egyes ECDSA nyilvános kulcsok hashei, melyeket a következőképpen számítunk ki:

Version = 1 0-ás (zerus) bájt; a teszthálózaton ez az 1. bájt a 111-ből
Key hash = Verzió összefűzve RIPEMD-160(SHA-256(nyilvános kulcs))-csal
Checksum = Az SHA-256(SHA-256(Kulcs hashe)) 1. 4 bájtja
Bitcoin Address = Base58Encode(Kulcs hashe összefűzve a Checksummal)

A Base58-as kódolás házi készítésű, és némileg eltér a szabványostól – így például abban, hogy konvertálásnál a vezető nullák egyszeres nullákban kerülnek tárolásra.

Gyakori szerkezetek

Szinte minden egész szám kis endianban kódolódik. Csak az IP és a portszám kódolódik nagy endianban.

Üzenetszerkezet

Mezőméret	Leírás	Adattípus	Megjegyzés
4	magic	uint32_t	A magic-érték egyrészt az üzenet küldő hálózatát jelöli, másrészt pedig ezzel kutatjuk fel a következő üzenetet, ha a folyam állapota ismeretlen
12	command	char[12]	A csomag tartalmát azonosító ASCII-sztring, NULL párnázással (nem-NULL-párnázás esetén a csomag elutasításra kerül)
4	length	uint32_t	A tartalom hossza a bájtok számában megadva
4	checksum	uint32_t	Az sha256(sha256(tartalom)) 1. 4 bájtja (a version vagy a verack ezt nem tartalmazza)
?	payload	uchar[][	A tényleges adat

A version és a verack üzeneteknek nincs checksumjuk, azoknál 4 bájttal előrébb kezdődik a tartalom.

Ismert magic-értékek:

Hálózat	Magic-érték	Küldési forma
fő	0xD9B4BEF9	F9 BE B4 D9
tesz	0xDAB5BFFA	FA BF B5 DA

Változó hosszúságú egész számok

Helytakarékosságból egész számokat kódolhatunk az általuk jelölt érték alapján. A változó hosszúságú array/vector adattípusokat mindig változó hosszúságú egész számok előzik meg.

Érték	Tárhossz	Formátum
< 0xfd	1	uint8_t
<= 0xffff	3	0xfd + uint16_t
<= 0xffffffff	5	0xfe + uint32_t
–	9	0xff + uint64_t

Változó hosszúságú sztring

A változó hosszúságú sztringek tárolhatóak önmagukban is, egy változó hosszúságú egész számmal az elejükön.

Mezőméret	Leírás	Adattípus	Megjegyzések
?	hossz	var_int	A sztring hossza
?	sztring	char[]	Maga a sztring (lehet üres is)

Hálózati cím

Ezt a szerkezetet használjuk, ha valahol hálózati címre van szükség. Ez a protokoll és szerkezet már az IPv6-ot is támogatja, azonban az eredeti kliens jelenleg csak az IPv4-et.

Mezőméret	Leírás	Adattípus	Megjegyzések
8	szolgáltatások	uint64_t	A versionben felsorolttal azonos szolgáltatások
16	IPv6/4	char[16]	IPv6-os cím. Hálózati bájtsorrend. Az eredeti kliens csak az IPv4-et támogatja, és csak az utolsó 4 bájtból olvssa ki az IPv4-címet. Az IPv4 cím azoban 16 bájtos, IPv4-térképezett IPv6-címként kerül rögzítésre az üzenetben. (12 bájt 00 00 00 00 00 00 00 00 00 00 FF FF, amit az IPv4-cím 4 bájtja követ).
2	port	uint16_t	portszám, hálózati bájtsorrend

Hálózati címszerkezet-példa hexdumpként:

0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
0010 00 00 FF FF 0A 00 00 01 20 8D …….. .

Hálózati cím:
01 00 00 00 00 00 00 00 – 1 (NODE_NETWORK: lásd a version parancsnál felsorolt szolgáltatásokat)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 – IPv6: ::ffff:10.0.0.1 vagy IPv4: 10.0.0.1
20 8D – 8333-as port

Leltárvektorok

Leltárvektorokkal értesítjuk a csomópontokat az objektumaikról és az éppen kért adatokról.

A leltárvektorok a következő adatformátumból épülnek fel:

Mezőméret	Leírás	Adattípus	Megjegyzések
4	típus	uint32_t	Azonosítja az ehhez a leltárhoz kapcsolt objektumtípust
32	hash	char[32]	Az objektum hashe

Az objektumtípust jelenleg a következő lehetőségek egyikeként határozzuk meg:

Érték	Név	Leírás
0	ERROR	Az ezzel a számmal jelölt adatok mind ignorálhatóak
1	MSG_TX	A hash egy tranzakcióhoz kapcsolódik
2	MSG_BLOCK	A hash egy adatblokkhoz kapcsolódik

A későbbiekben tervezzük további adattípusok bevezetését is.

Blokk fejlécek

A blokk fejlécek a getheaders üzenetre adott válaszként, fejléc-csomag formájában kerülnek elküldésre.

Mezőméret	Leírás	Adattípus	Megjegyzések
4	version	uint32_t	Blokkverzió-információ a kérdéses blokkot létrehozó szoftver verziószáma alapján
32	prev_block	char[32]	A kérdéses blokk által meghivatkozott előző blokk hash-értéke
32	merkle_root	char[32]	Hivatkozás a kérdéses blokkhoz kapcsolódó összes tranzakció hashét tartalmazó Merkle-fa-gyűjteményre
4	timestamp	uint32_t	A kérdéses blokk létrehozását rögzítő időbélyeg (felső korlátja: 2106 !)
4	bits	uint32_t	A kérdéses blokk kiszámított nehézségi célszáma
4	nonce	uint32_t	A kérdéses blokk legenerálásához felhasznált (a fejléc variálását és ezáltal különböző hash-értékek kiszámítását lehetővé tevő) nonce
1	txn_count	uint8_t	Tranzakció-bejegyzések száma; ez az érték mindig 0

Üzenettípusok

version

Kimenő kapcsolat létrehozásakor a csomópontok azonnal bejelentik a verziószámukat, amire a távoli csomópont a saját verziószámával válaszol. További kommunikáció csak a verziószámok cseréjét követően lehetséges.

Tartalom:

Mezőméret	Leírás	Adattípus	Megjegyzések
4	version	int32_t	Azonosítja a csomópont protokollverzióját
8	services	uint64_t	A kérdéses kapcsolathoz engedélyezendő funkciók bitmezője
8	timestamp	int64_t	szabványos, másodpercekben mért UNIX időbélyeg
version >= 106
26	addr_you	net_addr	Ezt a címet látja a kérdéses üzenetet küldő csomópont (értsd: a fogadó csomópont címe)
8	nonce	uint64_t	A csomópont minden újabb csomag elküldésekor véletlenszerűen generált nonce-a. Ezzel azonosíthatóak az önkapcsolódások.
?	sub_version_num	var_str	Másodlagos verzióinformáció (0x00 ha a sztring 0 bájt hosszú)
version >= 209
4	start_height	int32_t	A küldőcsomóponthoz utolsóként érkezett blokk

Ha a csomag küldőjénél version >= 209, úgy a version csomag elfogadását egy “verack” csomag elküldése követi.

Jelenleg a következő szolgáltatások vannak kiosztva:

Érték	Név	Leírás
1	NODE_NETWORK	Ettől a csomóponttól teljes blokkokat is lehet kérni, nem csak fejléceket.

Hexdump-példa version üzenetre (figyeld meg, hogy ennek a version-üzenetnek a fejléce nem tartalmaz checksumot):

0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ….version…..
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U….|……….
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 …M…………
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 …………….
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C ………. … ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U…

Üzenet fejléc:
F9 BE B4 D9 – Főhálózat magic-bájtjai
76 65 72 73 69 6F 6E 00 00 00 00 00 – “version” parancs
55 00 00 00 – 85 bájt hosszú tartalom
– version-üzenetben nincs checksum
Version üzenet:
9C 7C 00 00 – 31900 (0.3.19-es verzió)
01 00 00 00 00 00 00 00 – 1 (NODE_NETWORK szolgáltatások)
E6 15 10 4D 00 00 00 00 – Hét Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 – Küldő címinformációja – Lásd hálózati cím
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D – Fogadó címinformációja – Lásd hálózati cím
DD 9D 20 2C 3A B4 57 13 – véletlenszerűen generált, egyedi csomópont-ID
00 – “” sub-version sztring (0 bájt hosszú)
55 81 01 00 – A csomópont utolsó blokkja a #98645-ös

verack

Ez a >= 209 kliensek versionjére küldendő válasz. Ez az üzenet kizárólag üzenet fejlécből áll, benne a “verack” parancssztringgel.

A verack üzenet hexdumpja:

0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ….verack……
0010 00 00 00 00 ….

Üzenet fejléc:
F9 BE B4 D9 – Főhálózati magic-bájtok
76 65 72 61 63 6B 00 00 00 00 00 00 – “verack” parancs
00 00 00 00 – 0 bit hosszú tartalom

addr

A hálózat ismert csomópontjairól szolgáltat információt. A nem-hirdetett csomópontok átlagosan 3 óra múltán merülnek feledésbe.

Tartalom (maximális hossza: 1.000 bájt):

Mezőméret	Leírás	Adattípus	Megjegyzések
1+	count	var_int	Címbejegyzések száma
30x?	addr_list	(uint32_t + net_addr)[]	A hálózat más csomópontjainak címei. A version < 209-ek csak az elsőt fogják beolvasni. Az uint32_t egy időbélyeg (lásd a lenti megjegyzést).

Megjegyzés: A 31402-es verziótól kezdve a címeket időbélyeg előzi meg. Időbélyeg hiányában a címek csak akkor kerülnek továbbításra, ha valóban megerősítést nyert az aktivitásuk.

Hexdump példa addr üzenetre:

0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ….addr……..
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 …..R9…..M…
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF …………….
0030 FF 0A 00 00 01 20 8D ….. .

Üzenet fejléc:
F9 BE B4 D9 – Főhálózati magic-bájtok
61 64 64 72 00 00 00 00 00 00 00 00 – “addr”
1F 00 00 00 – 31 bájt hosszú tartalom
ED 52 39 9B – tartalom checksumja

Tartalom:
01 – Ez az üzenet 1 címet tartalmaz

Cím:
E2 15 10 4D – Hét Dec 20 21:50:10 EST 2010 (csak version >= 31402 esetén)
01 00 00 00 00 00 00 00 – 1 (NODE_NETWORK szolgáltatás – lásd version üzenet)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 – IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-es IPv6-cím)
20 8D – 8333-as port

inv

Ha egy csomópontnak tudomása van egy vagy több objektumról, akkor azt ezáltal hirdetheti. Érkezhet kérés nélkül és getblocks-ra adott válaszként is.

Tartalom (maximális hossza: 50.000 bájt)

Mezőméret	Leírás	Adattípus	Megjegyzések
?	count	var_int	Leltárbejegyzések száma
36x?	inventory	inv_vect[]	Leltárvektorok

getdata

Az invre adott válaszként használatos, egy meghatározott objektum tartalmának lekérése érdekében, és általában egy inv csomag fogadása után kerül elküldésre, a már ismert elemek kiszűrését követően.

Tartalom (maximális hossza: 50.000 bájt):

Mezőméret	Leírás	Adattípus	Megjegyzések
?	count	var_int	Leltárbejegyzések száma
36x?	inventory	inv_vect[]	Leltárvektorok

getblocks

A hash_starttól 500 blokkig vagy a hash_stopig (amelyik előbb jön) terjedő blokkok listáját tartalmazó inv csomagot ad vissza. A következő blokk hashei a legutóbbi ismert hashsel megismételt getblocks-szal kérhetőek le.

Tartalom:

Mezőméret	Leírás	Adattípus	Megjegyzések
4	version	uint32_t	a protokoll verziója
1+	start count	var_int	Blokklokátor-hash bejegyzések száma
32+	block locator hashes	char[32]	Blokklokátor objektum. Az ősblokkig visszamenőleg a legújabb (sűrűn indul, aztán ritkul)
32	hash_stop	char[32]	Az utolsó lekért blokk hashe. Ha a lehető legtöbb blokk kell (500), állítsd nullára.

Blokklokátor-hashek létrehozásához addig told vissza a hasheket, amíg el nem érsz az ősblokkig. 10 hash visszatolása után minden hurok kétszer nagyobb lépést tesz visszafelé az őt megelőzőnél.

$step = 1
loop until at genesis block:
store current block hash
move backwards by $step
if number of stored hashes > 10:
$step *= 2
store genesis block

getheaders

Egy, a hash_starttól 2.000 blokkig vagy a hash_stopig (amelyik előbb jön) terjedő blokkok fejléceinek listáját tartalmazó headers csomagot ad vissza. A következő blokk hashei a legutóbbi ismert hashsel megismételt getheaders-szel kérhetőek le. A getheaders parancsot a vékony kliensek használják a blokklánc gyors letöltésére olyankor, amikor az egyes tranzakció tartalma érdektelen (mivel azok nem a mieink).

Tartalom:

Mezőméret	Leírás	Adattípus	Megjegyzések
1+	start count	var_int	hash_start bejegyzések száma
32+	hash_start	char[32]	A küldő csomópont utolsó ismert blokkjának hashe
32	hash_stop	char[32]	Az utolsó lekért blokk hashe. Ha a lehető legtöbb blokk kell (2.000), állítsd nullára.

tx

A tx egy bitcoin-tranzakciót ír le, a getdata-ra adott válaszként.

Mezőméret	Leírás	Adattípus	Megjegyzések
4	version	uint32_t	Tranzakció adatformátumának verziója
1+	tx_in count	var_int	Tranzakció bemeneteinek száma
41+	tx_in	tx_in[]	Egy vagy több tranzakcióbemenet vagy érmeforrás listája
1+	tx_out count	var_int	Tranzakció kimeneteinek száma
8+	tx_out	tx_out[]	Egy vagy több tranzakciókimenet vagy érmecélállomás listája
4	lock_time	uint32_t	A kérdéses tranzakció időbélyege vagy a blokkjának a száma: Érték Leírás 0 Mindig zárt < 500000000 A tranzakció lezárásának blokkszáma >= 500000000 A tranzakció lezárásának UNIX időbélyege Le nem zárt tranzakció nem kerülhet blokkba, és az időkeret lejárta előtt még módosítható egy új változatának elküldésével (mivel azonban ez a lehetőség a Bitcoinban jelenleg le van tiltva, ezért ez használhatatlan).

A TxIn a következő mezőkből áll:

Mezőméret	Leírás	Adattípus	Megjegyzések
36	previous_output	outpoint	Az előző kimeneti tranzakcióhivatkozás OutPoint-szerkezetként
1+	script length	var_int	Az aláíró szkript hossza
?	signature script	unchar[]	Számítási szkript a tranzakciók hitelesítésének ellenőrzésére.
4	sequence	uint32_t	A küldő által meghatározott tranzakcióverzió. Tranzakciók “kicserélésére” az információk frissítése esetén, még egy blokkba való bekerülés előtt.

Az OutPoint szerkezet a következő mezőkből áll:

Mezőméret	Leírás	Adattípus	Megjegyzések
32	hash	char[32]	A hivatkozott tranzakció hashe.
4	index	uint32_t	A tranzakció meghatározott kimenetének indexe. Az első kimenet 0, stb.

A szkriptszerkezet egy sor információmorzsából és a tranzakció értékéhez kapcsolódó műveletekből áll.

(A szerkezet a későbbiekben még bővítendő… további információkért lásd script.h, script.cpp és Script.)

A TxOut szerkezet a következő mezőkből áll:

Mezőméret	Leírás	Adattípus	Megjegyzések
8	value	uint64_t	A tranzakció értéke
1+	pk_script length	var_int	A pk_script hossza
?	pk_script	uchar[]	Általában a nyilvános kulcsot tartalmazza egy, a kérdéses kimenet fogadásának feltételeit előkészítő Bitcoin szkript formájában.

Példa tx-üzenet:

000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ….tx……….
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB ………….m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[…Q……..f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P……j.6)…
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r…
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#…h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W… Y…..
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z…XN…
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5…6..;…A….
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m…@..!…
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y… …
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o…Q…
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K…..
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL……v….
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB …..E.z……..
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 “^………..v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj…..H^…
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R……

Üzenet fejléc:
F9 BE B4 D9 – főhálózati magic-bájtok
74 78 00 00 00 00 00 00 00 00 00 00 – “tx” parancs
02 01 00 00 – a tartalom 258 bájt hosszú
E2 93 CD BE – tartalom checksumja

Tranzakció:
01 00 00 00 – version

Bemenetek:
01 – tranzakció bemeneteinek száma

1. bemenet:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D – előző kimenet (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B – a szkript 139 bájt hosszú

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 – aláíró szkript (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF – szekvencia

Kimenetek:
02 – 2 kimeneti tranzakció

1. kimenet:
40 4B 4C 00 00 00 00 00 – 0.05 BTC (50.000.00)
19 – A pk_script 25 bájt hosszú

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 – pk_script
A9 D9 EA 1A FB 22 5E 88 AC

2. kimenet:
80 FA E9 C7 00 00 00 00 – 33.54 BTC (3.354.000.000)
19 – a pk_script 25 bájt hosszú

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E – pk_script
FD A0 B7 8B 4E CC 52 88 AC

Lezárás ideje:
00 00 00 00 – lezárás ideje

block

A block üzenet egy blokkhashről tranzakció-információt kérő getdata üzenetre adott válaszként érkezik.

Mezőméret	Leírás	Adattípus	Megjegyzések
4	version	uint32_t	Blokkverzió-információ a blokkot létrehozó szoftver verziószáma alapján
32	prev_block	char[32]	A kérdéses blokk által meghivatkozott előző blokk hash-értéke
32	merkle_root	char[32]	Hivatkozás egy Merkle-fa-gyűjteményre (a kérdéses blokkhoz kapcsolódó összes tranzakció hashére)
4	timestamp	uint32_t	A kérdéses blokk létrejöttét rögzítő időbélyeg (felső határ: 2106 !)
4	bits	uint32_t	A kérdéses blokkhoz használt kiszámított nehézségi célszám
4	nonce	uint32_t	A kérdéses blokkhoz használt (a fejléc variálását és ezáltal különböző hash-értékek kiszámítását lehetővé tevő) nonce
?	txn_count	var_int	Tranzakció-bejegyzések száma
?	txns	tx[]	Blokk tranzakciói, “tx” parancs-formátumban

Az egyes blokkokat azonosító SHA256 hash (melynek egy sor nullás bittel kell kezdődnie) ennek a szerkezetnek az első 6 mezőjéből kerül kiszámításra (version, prev_block, merkle_root, timestamp, bits, nonce és szabványos SHA256-párnázás, ami összesen két 64 bájtos darabot eredményez), nem pedig a blokk teljes egészéből. A hash kiszámításához az SH256-algoritmusnak mindössze két darabot kell feldolgoznia. Mivel a nonce mező a második darabban van, ezért az első változatlan marad a bányászat során, és csak a másodikat kell feldolgozni. Mivel azonban a Bitcoin-hash a hash hashe, ezért összesen két SHA256-kör kell minden újabb bányászathoz. Részletekért és példáért lásd a Blokkhashelő algoritmust.

headers

A headers csomag blokkfejléceket ad vissza egy getheaders csomagra adott válaszként.

Tartalom:

Mezőméret	Leírás	Adattípus	Megjegyzések
?	count	var_int	Blokkfejlécek száma
77x?	headers	block_header[]	Blokkfejlécek

getaddr

A getaddr üzenet ismert aktív peerekről kér információt egy csomóponttól a hálózat más potenciálisan aktív csomópontjainak azonosítása érdekében. Erre a válasz egy addr üzenet, benne egy vagy több peerrel az ismert peerek adatbázisából. Általános előfeltevés, hogy ha egy csomópont az elmúlt három órában küldött üzenetet, akkor még vélhetőleg aktív.

Más adatot ez az üzenet nem továbbít.

checkorder

Ez az üzenet IP-tranzakciókhoz használatos; ez teszi fel a kérdést a peernek, hogy fogad-e ilyen tranzakciókat, és lehetővé teszi számára a rendelés tartalmának megtekintését.

CWalletTx objektumot tartalmaz.

Tartalom:

Mezőméret	Leírás	Adattípus	Megjegyzések
CMerkle Tx mezők
?	hashBlock
?	vMerkleBranch
?	nIndex
CWalletTx mezők
?	vtxPrev
?	mapValue
?	vOrderForm
?	fTimeReceivedIsTxTime
?	nTimeReceived
?	fFromMe
?	fSpent

submitorder

Megerősíti, hogy elküldésre került egy rendelés.

Tartalom:

Mezőméret	Leírás	Adattípus	Megjegyzések
32	hash	char[32]	A tranzakció hashe
?	wallet_entry	cWalletTx	Tartalma azonos a checkorderével

reply

Általános válasz IP-tranzakciókra.

Tartalom:

Mezőméret	Leírás	Adattípus	Megjegyzések
4	reply	uint32_t	Válaszkód

Lehetséges értékek:

Érték	Név	Leírás
0	SUCCESS	Mehet az IP-tranzakció (checkorder) vagy elfogadásra került (submitorder)
1	WALLET_ERROR	Nem sikerült az AcceptWalletTransaction()
2	DENIED	Ez a csomópont nem fogad IP-tranzakciókat

ping

A ping üzenet elsődleges célja annak megerősítése, hogy továbbra is érvényes-e a TCP/IP kapcsolat. Adáshiba esetén a kapcsolat lezárultnak tekinthető, a cím pedig törlődik a jelenleg aktív peerek listájából. Erre az üzenetre nem várunk sem választ, sem semmiféle egyéb reakciót a kliens részéről.

alert

Alerttel általános értesítő üzenetet küldenek szét egymásnak a csomópontok a hálózatban. Ha az aláírással megerősíthető, hogy az alert valóban a Bitcoin szoftver fejlesztői körének magjától indult ki, úgy javasolt az üzenet megjelenítése, hogy a felhasználó is olvashassa. Ajánlott továbbá ilyenkor a kliensen keresztüli tranzakciók – és főleg az automatizált tranzakciók – végrehajtásának felfüggesztése. A Message sztring szövege lejegyzendő a naplófájlokba és megjelenítendő a felhasználói felületeken.

Tartalom:

Mezőméret	Leírás	Adattípus	Megjegyzések
?	message	var_str	Rendszerüzenet, melynek célja a hálózaton keresztüli információtovábbítás
?	signature	var_str	Egy nyilvános kulccsal megerősíthető aláírás, ellenőrizendő, hogy valóban Satoshi (a bitcoinok forrása) küldte az üzenetet vagy “engedélyezte” annak az elküldését.

Az aláírás a következő nyilvános ECDSA-kulccsal kerül összevetésre:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Forrás: [1]

Szkriptelés

Lásd script.

Wireshark-szike

A wireshark-szike jelenleg is fejlesztés alatt áll itt.

Lásd még

Hálózat

Protokoll szabályok

Forrás: Protocol specification

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.