del v0.31

HU/book_hu.asciidoc

@@ -1,6 +1,6 @@
 :bookseries: animal
 
-= Bitcoin fejlesztőknek
+= A bitcoinról, nem csak fejlesztőknek
 
 include::praise_hu.asciidoc[]
 

HU/ch01_hu.asciidoc

@@ -42,7 +42,7 @@ A bitcoin a kriptográfia és az osztott rendszerek évtizedes kutatásának a v
 
 === A bitcoin története
 
-((("bitcoin","kifejlődése")))((("Nakamoto, Satoshi")))A bitcoint 2008-ban találta fel Satoshi Nakamoto, amikor megjelentette a ((("Bitcoin: A Peer-to-Peer Electronic Cash System. (Nakamoto)"))) „Bitcoin: egy peer-to-peer elektronikus pénzrendszer” című dolgozatát. Satoshi Nakamoto számos előző felfedezés, pl. ((("b-money")))((("HashCash"))) a b-pénz és a HashCash kombinálásával egy teljesen decentralizált elektronikus pénzrendszert hozott létre, amelyben a pénzkibocsájtás, valamint a tranzakciók elszámolása és ellenőrzése nem egy központi szervezetre támaszkodik. A legfontosabb újítása a ((("munkabizonyíték (proof-of-work) algoritmus"))) munkabizonyíték algoritmuson alapuló, 10 percenkénti globális „szavazás”. Ennek révén a decentralizált hálózatban a tranzakciók állapotáról _konszenzus_ alakulhat ki. Ez elegáns megoldást jelent. a kettős költés kérdésére – vagyis arra, hogy egy pénzegységet ne lehessen kétszer is elkölteni. Korábban a digitális pénz egyik gyengeségét éppen a kettős költés jelentette, melyet úgy kezeltek, hogy az összes tranzakciót egy központ elszámolóházon keresztül rendezték. 
+((("bitcoin","kifejlődése")))((("Nakamoto, Satoshi")))A bitcoint 2008-ban találta fel Satoshi Nakamoto, amikor megjelentette a ((("Bitcoin: A Peer-to-Peer Electronic Cash System. (Nakamoto)"))) „Bitcoin: egy peer-to-peer elektronikus pénzrendszer” című dolgozatát. Satoshi Nakamoto számos előző felfedezés, pl. ((("b-money")))((("HashCash"))) a b-pénz és a HashCash kombinálásával egy teljesen decentralizált elektronikus pénzrendszert hozott létre, amelyben a pénzkibocsájtás, valamint a tranzakciók elszámolása és ellenőrzése nem egy központi szervezetre támaszkodik. A legfontosabb újítása a ((("munkabizonyíték (proof-of-work) algoritmus"))) munkabizonyíték algoritmuson alapuló, 10 percenkénti globális „szavazás”. Ennek révén a decentralizált hálózatban a tranzakciók állapotáról _konszenzus_ alakulhat ki. Ez elegáns megoldást jelent a kettős költés kérdésére – vagyis arra, hogy egy pénzegységet ne lehessen kétszer is elkölteni. Korábban a digitális pénz egyik gyengeségét éppen a kettős költés jelentette, melyet úgy kezeltek, hogy az összes tranzakciót egy központ elszámolóházon keresztül rendezték. 
 
 ((("bitcoin hálózat","eredete"))) A bitcoin hálózat a Nakamoto által publikált referencia implementáció alapján, 2009-ben kezdte meg a működését. A referencia implementációt azóta számos programozó felülvizsgálta. A bitcoin biztonságát és ellenállóképességét biztosító osztott feldolgozási kapacitás exponenciálisan nőtt, és manapság meghaladja a világ leggyorsabb szuper-számítógépeinek a feldolgozási kapacitását. A bitcoin teljes piaci értéke a bitcoin-dollár árfolyamtól függően becslések szerint 5 és 10 milliárd US dollár között van. A hálózat által feldolgozott eddigi legnagyobb tranzakció 150 millió US dollár volt. A tranzakció azonnal továbbításra került, és a feldolgozása díjtalan volt.
 

HU/ch02_hu.asciidoc

@@ -168,7 +168,7 @@ A választ <<example_2-2>> mutatja. Eszerint a bitcoin hálózat egyetlen egy el
 Lásd http://bit.ly/1tAeeGr[Joe tranzakciója Alíz számára].
 ====
 
-Mint látható, Alíz pénztárcájában elegendő bitcoin van az egyetlen egy el nem költött kimenetben ahhoz, hogy kifizesse a kávéját. Ha nem ez lenne a helyzet, akkor a pénztárca programnak „végig kellene bogarásznia” egy halom kisebb, el nem költött kimenetet, ahhoz hasonlóan, mint ha valaki egy fizikai pénztárcából újabb és újabb pénzérméket venne elő, hogy ki tudja fizetni a kávéját. Mindkét esetben kezelni kell a visszajáró pénzt is. Ezt a következő részben fogjuk látni, amikor a pénztárca alkalmazás létrehozza a tranzakció kimeneteket (a kifizetéseket). (payments).(((range="endofrange", startref="ix_ch02-asciidoc5")))
+Mint látható, Alíz pénztárcájában elegendő bitcoin van az egyetlen egy el nem költött kimenetben ahhoz, hogy kifizesse a kávéját. Ha nem ez lenne a helyzet, akkor a pénztárca programnak „végig kellene bogarásznia” egy halom kisebb, el nem költött kimenetet, ahhoz hasonlóan, mint ha valaki egy fizikai pénztárcából újabb és újabb pénzérméket venne elő, hogy ki tudja fizetni a kávéját. Mindkét esetben kezelni kell a visszajáró pénzt is. Ezt a következő részben fogjuk látni, amikor a pénztárca alkalmazás létrehozza a tranzakció kimeneteket (a kifizetéseket).(((range="endofrange", startref="ix_ch02-asciidoc5")))
 
 
 ==== A kimenetek létrehozása

HU/ch03_hu.asciidoc

@@ -173,7 +173,7 @@ config.status: executing depfiles commands
 $
 ----
 
-Ha minden jól megy, akkor a +configure+ parancs úgy ér véget, hogy egy testre szabott build scriptet hoz létre, amellyel lefordítható a bitcoind. Ha hiányzó könyvtárak vagy hibák vannak, akkor a +configure+ parancs hibával fog véget érni, és nem hozza létre a fenti példában látható build scripteket. Ha hiba történik, annak a legvalószínűbb oka egy hiányzó vagy nem kompatibilis könyvtár. Nézze át ismét az újraépítésre vonatkozó dokumentációt, és installálja a hiányzó előfeltételeket. Azután futtassa le ismét a +configure+ –t, és nézze meg, hogy elmúlt-e a hiba. Ezután fordítsa le a forráskódot – ez a folyamat akár egy óráig is tarthat. A fordítás során néhány másodpercenként vagy néhány percenként megjelenik valami – vagy hibaüzenetet kap, ha valami baj van. A fordítási folyamat bármikor folytatható, ha félbeszakadt. A fordítás megkezdéséhez gépelje be, hogy +make+ :
+Ha minden jól megy, akkor a +configure+ parancs úgy ér véget, hogy egy testre szabott build scriptet hoz létre, amellyel lefordítható a bitcoind. Ha hiányzó könyvtárak vagy hibák vannak, akkor a +configure+ parancs hibával fog véget érni, és nem hozza létre a fenti példában látható build scripteket. Ha hiba történik, annak a legvalószínűbb oka egy hiányzó vagy nem kompatibilis könyvtár. Nézze át ismét az újraépítésre vonatkozó dokumentációt, és installálja a hiányzó előfeltételeket. Azután futtassa le ismét a +configure+–t, és nézze meg, hogy elmúlt-e a hiba. Ezután fordítsa le a forráskódot – ez a folyamat akár egy óráig is tarthat. A fordítás során néhány másodpercenként vagy néhány percenként megjelenik valami – vagy hibaüzenetet kap, ha valami baj van. A fordítási folyamat bármikor folytatható, ha félbeszakadt. A fordítás megkezdéséhez gépelje be, hogy +make+ :
 
 ----
 $ make
@@ -1034,7 +1034,9 @@ Most a tranzakcióban használt bemenetek egy +scriptsSig+-et is tartalmaznak. A
 Most küldjük el ezt az újonnan létrehozott tranzakciót a hálózatnak. Ezt a +sendrawtransaction+ paranccsal fogjuk megtenni, amelynek a paramétere a +signrawtransaction+ által létrehozott nyers hexadecimális string lesz. Ez ugyanaz a string, amit épp most dekódoltunk:
 
 ----
-$ bitcoin-cli sendrawtransaction 0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c000000006a47304402203e8a16522da80cef66bacfbc0c800c6d52c4a26d1d86a54e0a1b76d661f020c9022010397f00149f2a8fb2bc5bca52f2d7a7f87e3897a273ef54b277e4af52051a06012103c9700559f690c4a9182faa8bed88ad8a0c563777ac1d3f00fd44ea6c71dc5127ffffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac00000000ae74538baa914f3799081ba78429d5d84f36a0127438e9f721dff584ac17b346
+$ bitcoin-cli sendrawtransaction 0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c000000006a47304402203e8a16522da80cef66bacfbc0c800c6d52c4a26d1d86a54e0a1b76d661f020c9022010397f00149f2a8fb2bc5bca52f2d7a7f87e3897a273ef54b277e4af52051a06012103c9700559f690c4a9182faa8bed88ad8a0c563777ac1d3f00fd44ea6c71dc5127ffffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac00000000
+
+ae74538baa914f3799081ba78429d5d84f36a0127438e9f721dff584ac17b346
 ----
 
 A +sendrawtransaction+ parancs egy _tranzakció hasht (txid-t)_ ad vissza, miután feladta a tranzakciót a hálózatnak. Ekkor a +gettransaction+ paranccsal le tudjuk kérdezni ezt a tranzakciót:

HU/ch04_hu.asciidoc

@@ -52,7 +52,7 @@ image::images/msbt_0401.png["privk_to_pubK_to_addressA"]
 
 ((("titkos kulcsok","előállításuk véletlen számokból", id="ix_ch04-asciidoc3", range="startofrange")))A kulcsok előállításának első és legfontosabb lépése, hogy egy biztonságos entrópiaforrást, másképpen véletlenszerű forrást találjunk. Egy bitcoin kulcs előállítása lényegében egyenértékű azzal, hogy „Válasszunk egy számot 1 és 2^256^ között”. Hogy pontosan hogyan választjuk ezt a számot, az nem számít, feltéve, hogy a választás nem megjósolható vagy nem megismételhető. A bitcoin szoftver a mögöttes operációs rendszer véletlenszám generátorát használja 256 bit entrópia (véletlenszerűség) előállítására. Az OS véletlenszám generátorát általában egy emberi eredetű entrópiaforrással inicializálják, ezért van szükség pl. arra, hogy mozgassuk az egeret néhány másodpercig. Az igazán paranoiások számára a dobókockánál, a papírnál és a ceruzánál nincs jobb módszer.
 
-Pontosabban, a titkos kulcs egy +1+ és +n - 1+ közötti tetszőleges szám lehet, ahol n konstans (n=1.158 * 10^77^, vagyis egy kicsit kevesebb, mint 2^256^), és a bitcoinnál használt elliptikus görbe rendszámával egyenlő (lásd az <<elliptic_curve>> részt). Egy ilyen kulcs előállításához véletlenszerűen válasszunk egy 256 bites számot, és ellenőrizzük, hogy kisebb-e +n - 1+-nél. Programozási szempontból ezt általában úgy valósítható meg, hogy kriptográfiailag biztonságos véletlen forrásból származó bitek egy nagyobb halmazát egy SHA256 hash algoritmussal összetömörítjük, és ezzel egyszerűen létrehozunk egy 256 bites számot. Ha az eredmény kisebb, mint +n - 1+, akkor a titkos kulcs megfelelő. Ha nem, akkor egy másik véletlen számmal próbálkozunk. 
+Pontosabban, a titkos kulcs egy +1+ és +n-1+ közötti tetszőleges szám lehet, ahol n konstans (n=1.158 * 10^77^, vagyis egy kicsit kevesebb, mint 2^256^), és a bitcoinnál használt elliptikus görbe rendszámával egyenlő (lásd az <<elliptic_curve>> részt). Egy ilyen kulcs előállításához véletlenszerűen válasszunk egy 256 bites számot, és ellenőrizzük, hogy kisebb-e +n-1+-nél. Programozási szempontból ezt általában úgy valósítható meg, hogy kriptográfiailag biztonságos véletlen forrásból származó bitek egy nagyobb halmazát egy SHA256 hash algoritmussal összetömörítjük, és ezzel egyszerűen létrehozunk egy 256 bites számot. Ha az eredmény kisebb, mint +n-1+, akkor a titkos kulcs megfelelő. Ha nem, akkor egy másik véletlen számmal próbálkozunk. 
 
 [TIP]
 ====
@@ -129,7 +129,7 @@ vagy
 \end{equation}
 ++++
 
-A _mod p_ (p prímszám szerinti modulus) azt jelzi, hogy egy _p_ rendszámú véges mező fölött definiált görbéről van szó, ami úgy is írható, hogy latexmath:[\(\mathbb{F}_p\)], ahol p = 2^256^ - 2^32^ - 2^9^ – 2^8^ -2^7^ - 2^6^ – 2^4^ -1, egy nagyon nagy prímszám. 
+A _mod p_ (p prímszám szerinti modulus) azt jelzi, hogy egy _p_ rendszámú véges mező fölött definiált görbéről van szó, ami úgy is írható, hogy latexmath:[\(\mathbb{F}_p\)], ahol p = 2^256^-2^32^-2^9^-2^8^-2^7^-2^6^-2^4^-1, egy nagyon nagy prímszám. 
 
 Mivel ez a görbe a valós számok halmaza helyett egy prím rendszámú véges mező fölött lett definiálva, úgy néz ki, mint két dimenzióban szétszórt pontok halmaza, ami nagyon nehézzé teszi a megjelenítését. A matematikája azonban megegyezik a fenti, valós számok fölött definiált elliptikus görbéével. Például lent ugyanez a <<ecc-over-F17-math>> elliptikus görbe látható egy sokkal kisebb, 17 rendszámú véges mező fölött, ahol a pont-minták egy rácson lettek megjelenítve. A bitcoin +secp256k1+ elliptikus görbéje úgy képzelhető el, mint egy sokkal összetettebb pontminta, egy mérhetetlenül nagy rácson. 
 
@@ -145,6 +145,7 @@ P = (550662630222773436695787188951685343262506034537775941755001873603891167292
 ====
 [source, pycon]
 ----
+$ python3
 Python 3.4.0 (default, Mar 30 2014, 19:23:13)
 [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.38)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
@@ -160,7 +161,7 @@ Az elliptikus görbék matematikája tartalmaz egy ((("végtelenben lévő pont
 
 Van továbbá egy „összeadásnak” nevezett ((("+ művelet")))((("elliptikus görbékkel végzett titkosítás","összeadási művelet"))) pass:[+] művelet, amelynek néhány sajátossága hasonlít az iskolában tanult valós számok összeadásához. Ha az elliptikus görbén van két pont, P~1~ és P~2~, akkor létezik egy harmadik pont, P~3~, amely szintén az elliptikus görbén van, és amelyre P~3~ = P~1~ + P~2~ .
 
-Geometriailag ez a harmadik pont, a P~3~ úgy számítható ki, hogy húzunk egy egyeneset a P~1~ és P~2~ között. Ez az egyenes az elliptikus görbét pontosan egy további helyen fogja metszeni. Nevezzük ezt a pontot P~3~'-nak: P~3~' = (x, y). A P~3~ pont ennek a pontnak az x tengelyre történő tükrözésével kapható meg: P~3~ = (x, -y).
+Geometriailag ez a harmadik pont, a P~3~ úgy számítható ki, hogy húzunk egy egyenest a P~1~ és P~2~ között. Ez az egyenes az elliptikus görbét pontosan egy további helyen fogja metszeni. Nevezzük ezt a pontot P~3~'-nak: P~3~' = (x, y). A P~3~ pont ennek a pontnak az x tengelyre történő tükrözésével kapható meg: P~3~ = (x, -y).
 
 Van néhány különleges eset, amely megvilágítja, miért van szükség a „végtelenben lévő pontra”.
 

HU/ch05_hu.asciidoc

@@ -291,7 +291,7 @@ A script nyelv úgy hajtja végre a scriptet, hogy balról jobbra minden egyes e
 
 A feltételes műveletek egy feltétel kiértékelése után IGAZ vagy HAMIS eredményt állítanak elő. Például az +OP_EQUAL+ két tételt távolít el a veremről, és IGAZ értéket tesz a veremre (az IGAZ értéknek az 1 felel meg) ha a két szám egyenlő, és HAMIS értéket (amelyet a nulla ábrázol), ha a két szám nem egyenlő.
 
-<<simplemath_script>> futása során a +2 3 OP_ADD 5 OP_EQUAL+ script az +OP_ADD+ összeadási műveletet szemlélteti: összead két számot, az eredményt a veremre helyezi, majd ezt követően egy OP_EQUAL feltételes művelettel megvizsgálja, hogy az eredményül kapott összeg egyenlő-e +5+-tel. A rövidség kedvéért az +OP_+ előtagot a részletes, lépésről-lépésre történő kiértékelésben elhagytuk. 
+<<simplemath_script>> futása során a +2 3 OP_ADD 5 OP_EQUAL+ script az +OP_ADD+ összeadási műveletet szemlélteti: összead két számot, az eredményt a veremre helyezi, majd ezt követően egy +OP_EQUAL+ feltételes művelettel megvizsgálja, hogy az eredményül kapott összeg egyenlő-e +5+-tel. A rövidség kedvéért az +OP_+ előtagot a részletes, lépésről-lépésre történő kiértékelésben elhagytuk. 
 
 
 A következő egy kicsit bonyolultabb példa, amely a ++2 + 7 - 3 + 1++ kifejezés értékét számítja ki. Figyeljük meg, hogy ha a script számos egymás utáni műveletet tartalmaz, a verem lehetővé teszi, hogy az eredményt a következő művelet felhasználhassa:
@@ -365,13 +365,13 @@ A +Kávéház nyilvános kulcsának hashe+ egyenértékű a kávéház bitcoin c
 A fenti zároló script a következő formájú, zárolást megszüntető scripttel elégíthető ki:
 
 ----
-<a kávéházhoz tartozó aláírás> <a kávéház nyilvános kulcsa>
+<aláírás> <a kávéház nyilvános kulcsa>
 ----
 
 A két script együttesen a következő egyesített ellenőrző scriptet alkotja:
 
 ----
-<a kávéházhoz tartozó aláírás> <a kávéház nyilvános kulcsa> OP_DUP OP_HASH160 <a kávéház nyilvános kulcsának hash értéke> OP_EQUAL OP_CHECKSIG 
+<aláírás> <a kávéház nyilvános kulcsa> OP_DUP OP_HASH160 <a kávéház nyilvános kulcsának hash értéke> OP_EQUAL OP_CHECKSIG 
  
 ----
 
@@ -469,7 +469,7 @@ OP_RETURN <adat>
 
 Az adat rész 80 bájtra van korlátozva, és leggyakrabban egy hash értéknek felel meg, pl. az SHA256 algoritmus kimenetének (32 bájt). Sok alkalmazás egy előtagot helyez az adatok elé, hogy könnyebb legyen az alkalmazás azonosítása. Például a http://proofofexistence.com[Proof of Existence] digitális közjegyzői szolgáltatás a „DOCPROOF” 8 bájtos előtagot használja, amely hexadecimális alakban +444f4350524f4f46+.
 
-Emlékeztetünk rá, hogy az +OP_RTEURN+-höz nem tartozik „zárolás feloldó script”, amellyel „elkölthető” lenne az +OP_RETURN+. Az +OP_RETURN+-nek épp az az értelme, hogy nem költhető el az adott kimenetben zárolt pénz, és ezért nem kell a kimenetet az UTXO halmazban tartani, mint potenciálisan elkölthető kimenetet – az +OP_RETURN+ _bizonyíthatóan nem elkölthető_. Az +OP_RETURN+ általában egy nulla összegű bitcoin kimenet, mivel az ilyen kimenethez rendelt bitcoinok örökre elvesznének. Ha a script ellenőrző program egy +OP_RETURN+-nel találkozik, akkor azonnal félbeszakítja az ellenőrző script végrehajtását, és a tranzakciót érvénytelennek tekinti. Emiatt ha véletlenül egy +OP_RETURN+ kimenetre hivatkozunk egy tranzakció bemenetében, akkor a tranzakció érvénytelen lesz. 
+Emlékeztetünk rá, hogy az +OP_RETURN+-höz nem tartozik „zárolás feloldó script”, amellyel „elkölthető” lenne az +OP_RETURN+. Az +OP_RETURN+-nek épp az az értelme, hogy nem költhető el az adott kimenetben zárolt pénz, és ezért nem kell a kimenetet az UTXO halmazban tartani, mint potenciálisan elkölthető kimenetet – az +OP_RETURN+ _bizonyíthatóan nem elkölthető_. Az +OP_RETURN+ általában egy nulla összegű bitcoin kimenet, mivel az ilyen kimenethez rendelt bitcoinok örökre elvesznének. Ha a script ellenőrző program egy +OP_RETURN+-nel találkozik, akkor azonnal félbeszakítja az ellenőrző script végrehajtását, és a tranzakciót érvénytelennek tekinti. Emiatt ha véletlenül egy +OP_RETURN+ kimenetre hivatkozunk egy tranzakció bemenetében, akkor a tranzakció érvénytelen lesz. 
 
 Egy érvényes tranzakciónak (amely megefelel az +isStandard()+ ellenőrzéseknek) csak egy +OP_RETURN+ kimenete lehet. Az +OP_RETURN+ kimenet azonban tetszőleges egyéb kimeneti típusokkal kombinálható. 
 
@@ -517,7 +517,7 @@ A P2SH tranzakciókban a zároló scriptet egy hash helyettesíti, melynek ((("r
 
 Amint az a fenti táblázatokból látható, a P2SH használatakor a nem jelenik meg az a bonyolult script a kimenetben, amely a kimenet elköltésének feltételeit részletezi. Csak a script egy hashe van jelen a zárolást végző scriptben, a beváltási script pedig később, a kimenet elköltésekor, a zárolást feloldó script részeként kerül bemutatásra. Ennek révén a komplexitás és a tranzakciós díjak terhe a tranzakció küldőjéről a címzettre tevődik át. 
 
-Tekintsük Mohanmmed cégét, a bonyolult multi-sig scriptet és az eredményként kapott P2SH scriptet. 
+Tekintsük Mohammed cégét, a bonyolult multi-sig scriptet és az eredményként kapott P2SH scriptet. 
 
 Nézzük először azt a multi-sig scriptet, melyet Mohammed cége az összes bejövő fizetésnél használ: