Satoshi Nakamoto – satoshin@gmx.com – www.bitcoin.org
Összefoglaló. Egy tisztán „peer-to-peer” alapú elektronikus készpénzrendszer lehetővé tenné, hogy az online fizetések közvetlenül az egyik féltől a másikhoz jussanak el, pénzügyi intézmény közbeiktatása nélkül. A digitális aláírások részben megoldást nyújtanak erre, azonban a legfontosabb előnyök elvesznek, ha a „double-spending” (kettős költés) megakadályozásához még mindig szükség van egy megbízható harmadik félre. Olyan megoldást javaslunk a „double-spending” problémára, amely „peer-to-peer” hálózatot alkalmaz. A hálózat időbélyeggel látja el a tranzakciókat úgy, hogy „hash”-eli őket egy folyamatosan bővülő, „hash”-alapú „proof-of-work” láncba, ezzel olyan nyilvántartást hozva létre, amelyet nem lehet megváltoztatni a „proof-of-work” újbóli elvégzése nélkül. A leghosszabb lánc nemcsak a megfigyelt eseménysorozat bizonyítékaként szolgál, hanem annak is, hogy a legnagyobb CPU-teljesítmény-készletből származik. Mindaddig, amíg a CPU-teljesítmény többségét olyan „node”-ok irányítják, amelyek nem működnek együtt a hálózat megtámadásában, ők fogják előállítani a leghosszabb láncot, és megelőzik a támadókat. Maga a hálózat minimális struktúrát igényel. Az üzeneteket legjobb szándékkal szórják szét, és a „node”-ok tetszés szerint csatlakozhatnak és elhagyhatják a hálózatot, a leghosszabb „proof-of-work” láncot elfogadva annak bizonyítékaként, hogy mi történt távollétük alatt.
1. Bevezetés
Az internetes kereskedelem szinte kizárólag pénzügyi intézményekre támaszkodik, amelyek megbízható harmadik félként dolgozzák fel az elektronikus fizetéseket. Bár a rendszer a legtöbb tranzakció esetében megfelelően működik, még mindig szenved a bizalmon alapuló modell inherens gyengeségeitől. A teljesen visszafordíthatatlan tranzakciók valójában nem lehetségesek, mivel a pénzügyi intézmények nem kerülhetik el a viták közvetítését. A közvetítés költsége növeli a tranzakciós költségeket, korlátozva a minimálisan praktikus tranzakcióméreteket, és elvágva a kis alkalmi tranzakciók lehetőségét. Ráadásul szélesebb körű veszteséget jelent a visszafordíthatatlan szolgáltatásokért való visszafordíthatatlan fizetés képességének elvesztése. A visszafordítás lehetőségével a bizalom igénye terjed. A kereskedőknek óvatosaknak kell lenniük ügyfeleikkel szemben, több információt kérve tőlük, mint amennyire egyébként szükségük lenne. A csalás bizonyos százalékát elkerülhetetlennek fogadják el. Ezek a költségek és fizetési bizonytalanságok személyesen elkerülhetők fizikai valuta használatával, de nem létezik olyan mechanizmus, amely lehetővé tenné a kommunikációs csatornán keresztüli fizetést megbízható fél nélkül.
Amire szükség van, az egy kriptográfiai bizonyítékon alapuló elektronikus fizetési rendszer a bizalom helyett, amely lehetővé teszi bármely két hajlandó fél számára, hogy közvetlenül egymással tranzakciókat bonyolítsanak le, megbízható harmadik fél szükségessége nélkül. A számítástechnikailag visszafordíthatatlan tranzakciók megvédenék az eladókat a csalástól, és rutinszerű „escrow” mechanizmusok könnyen megvalósíthatók lennének a vevők védelme érdekében. Ebben a tanulmányban olyan megoldást javaslunk a „double-spending” problémára, amely „peer-to-peer” elosztott „timestamp” szervert alkalmaz a tranzakciók kronológiai sorrendjének számítástechnikai bizonyítékaként. A rendszer mindaddig biztonságos, amíg a becsületes „node”-ok összességében több CPU-teljesítményt irányítanak, mint a támadó „node”-ok bármely együttműködő csoportja.
2. Tranzakciók
Az elektronikus érmét digitális aláírások láncolatának definiáljuk. Minden tulajdonos az érmét a következőnek úgy adja át, hogy digitálisan aláírja az előző tranzakció „hash”-ét és a következő tulajdonos nyilvános kulcsát, majd ezeket hozzáadja az érme végéhez. A kedvezményezett ellenőrizheti az aláírásokat a tulajdonosi lánc hitelesítéséhez.
A probléma természetesen az, hogy a kedvezményezett nem tudja ellenőrizni, hogy az egyik tulajdonos nem költötte-e el kétszer az érmét. Egy elterjedt megoldás egy megbízható központi hatóság, azaz egy „pénzverde” bevezetése, amely minden tranzakciót ellenőriz a kettős költés szempontjából. Minden tranzakció után az érmét vissza kell küldeni a pénzverdébe, hogy új érmét adjanak ki, és csak a pénzverdéből közvetlenül kibocsátott érmékben bíznak meg abban, hogy nem kerülnek kettős elköltésre. A megoldás problémája az, hogy az egész pénzrendszer sorsa a pénzverdét működtető vállalattól függ, és minden tranzakciónak át kell mennie rajtuk, akárcsak egy banknál.
Szükségünk van egy módszerre, amellyel a kedvezményezett tudhatja, hogy az előző tulajdonosok nem írtak alá korábbi tranzakciókat. Céljainkra a legkorábbi tranzakció számít, ezért nem törődünk a „double-spending” későbbi kísérleteivel. Az egyetlen módja egy tranzakció hiányának megerősítésére az, ha tudatában vagyunk az összes tranzakciónak. A pénzverde alapú modellben a pénzverde tudatában volt az összes tranzakciónak, és döntötte el, melyik érkezett először. Ennek megbízható fél nélkül való megvalósításához a tranzakciókat nyilvánosan be kell jelenteni [1], és szükségünk van egy rendszerre, amellyel a résztvevők egyezségre juthatnak a fogadásuk sorrendjének egyetlen előzményéről. A kedvezményezettnek bizonyítékra van szüksége arra, hogy minden egyes tranzakció időpontjában a „node”-ok többsége egyetértett abban, hogy az az első fogadott volt.
3. „Timestamp” Szerver
Az általunk javasolt megoldás egy „timestamp” szerverrel kezdődik. A „timestamp” szerver úgy működik, hogy „hash”-eli az időbélyeggel ellátandó elemek egy blokkját, és széles körben közzéteszi a „hash”-t, például egy újságban vagy Usenet-bejegyzésben [2-5]. A „timestamp” bizonyítja, hogy az adatoknak nyilvánvalóan léteznie kellett abban az időpontban, hogy bekerülhessenek a „hash”-be. Minden „timestamp” tartalmazza az előző „timestamp”-et a saját „hash”-ében, láncot alkotva, ahol minden további „timestamp” megerősíti az előttieket.
4. „Proof-of-Work”
Ahhoz, hogy „peer-to-peer” alapon valósítsunk meg egy elosztott „timestamp” szervert, Adam Back Hashcash rendszeréhez [6] hasonló „proof-of-work” rendszert kell alkalmaznunk, nem pedig újságokat vagy Usenet-bejegyzéseket. A „proof-of-work” egy olyan érték keresését jelenti, amely „hash”-elve (például SHA-256 segítségével) olyan „hash”-t ad, amely meghatározott számú nulla bittel kezdődik. A szükséges átlagos munka exponenciálisan nő a szükséges nulla bitek számával, és egyetlen „hash” végrehajtásával ellenőrizhető.
A „timestamp” hálózatunknál a „proof-of-work”-öt úgy valósítjuk meg, hogy növeljük a blokkban lévő „nonce”-t, amíg egy olyan értéket nem találunk, amely a blokk „hash”-ének megadja a szükséges nulla biteket. Miután a CPU-erőfeszítést elvégeztük a „proof-of-work” teljesítéséhez, a blokkot nem lehet megváltoztatni anélkül, hogy újból el ne végeznénk a munkát. Ahogy a późbbi blokkok láncolódnak utána, a blokk megváltoztatásának munkája magában foglalná az összes utána következő blokk újbóli elvégzését is.
A „proof-of-work” megoldja a többségi döntéshozatalban való képviselet meghatározásának problémáját is. Ha a többség egy IP-cím-egy szavazat alapján működne, azt bárki megkerülhetné, aki sok IP-t tud lefoglalni. A „proof-of-work” lényegében egy CPU-egy szavazat. A többségi döntést a leghosszabb lánc képviseli, amelybe a legtöbb „proof-of-work” erőfeszítést fektették. Ha a CPU-teljesítmény többségét becsületes „node”-ok irányítják, a becsületes lánc fog a leggyorsabban növekedni, és megelőz minden konkurens láncot. Egy múltbeli blokk módosításához a támadónak újra el kellene végeznie a blokk és az összes utána következő blokk „proof-of-work”-jét, majd utolérni és felülmúlni a becsületes „node”-ok munkáját. Később megmutatjuk, hogy egy lassabb támadó felzárkózásának valószínűsége exponenciálisan csökken, ahogy újabb blokkok kerülnek hozzá.
A növekvő hardversebesség és a „node”-ok futtatása iránti változó érdeklődés kompenzálására a „proof-of-work” nehézségét egy mozgóátlag határozza meg, amely óránként átlagos blokkok számát célozza. Ha túl gyorsan generálódnak, a nehézség növekszik.
5. Hálózat
A hálózat működtetésének lépései a következők:
- Az új tranzakciókat szétszórják az összes „node”-hoz.
- Minden „node” összegyűjti az új tranzakciókat egy blokkba.
- Minden „node” dolgozik a saját blokkjához tartozó nehéz „proof-of-work” megtalálásán.
- Amikor egy „node” megtalálja a „proof-of-work”-öt, szétszórja a blokkot az összes „node”-hoz.
- A „node”-ok csak akkor fogadják el a blokkot, ha az összes benne lévő tranzakció érvényes és még nem lett elköltve.
- A „node”-ok az elfogadás kifejezéseként a lánc következő blokkjának létrehozásán dolgoznak, az elfogadott blokk „hash”-ét használva előző „hash”-ként.
A „node”-ok mindig a leghosszabb láncot tekintik a helyesnek, és folytatják annak bővítésén való munkát. Ha két „node” egyszerre szórja szét a következő blokk különböző verzióit, egyes „node”-ok az egyiket, mások a másikat kaphatják meg először. Ebben az esetben az elsőn dolgoznak, de a másik ágat is megőrzik arra az esetre, ha az hosszabbá válik. A döntetlen akkor szűnik meg, amikor a következő „proof-of-work” megtalálják, és az egyik ág hosszabbá válik; a másik ágon dolgozó „node”-ok ekkor átváltanak a hosszabbra.
Az új tranzakciók szétszórásának nem kell feltétlenül elérnie az összes „node”-ot. Amíg sok „node”-hoz eljut, rövidesen bekerülnek egy blokkba. A blokk szétszórások szintén tolerálják az elveszett üzeneteket. Ha egy „node” nem kap meg egy blokkot, kérni fogja, amikor megkapja a következőt, és rájön, hogy lemaradt egyet.
6. Ösztönző
Megállapodás szerint a blokkban lévő első tranzakció egy speciális tranzakció, amely egy új érmét indít el, amelynek tulajdonosa a blokk létrehozója. Ez ösztönzőt ad a „node”-oknak a hálózat támogatásához, és kezdeti módot biztosít az érmék forgalomba hozatalára, mivel nincs központi hatóság a kibocsátásukra. Az új érmék állandó mennyiségének folyamatos hozzáadása hasonló az aranyásókhoz, akik erőforrásokat fordítanak arra, hogy aranyat adjanak a forgalomhoz. A mi esetünkben CPU-időt és villamos energiát fordítunk erre.
Az ösztönző tranzakciós díjakkal is finanszírozható. Ha egy tranzakció „output” értéke kisebb, mint az „input” értéke, a különbség tranzakciós díj, amelyet hozzáadnak a tranzakciót tartalmazó blokk ösztönző értékéhez. Miután meghatározott számú érme lépett forgalomba, az ösztönző teljes egészében átválthat tranzakciós díjakra, és teljesen inflációmentessé válhat.
Az ösztönző segíthet arra ösztökélni a „node”-okat, hogy becsületesek maradjanak. Ha egy kapzsi támadó több CPU-teljesítményt tud összegyűjteni, mint az összes becsületes „node”, választania kellene aközött, hogy azt emberek becsapására használja-e fel azáltal, hogy visszalopja a kifizetéseit, vagy új érmék generálására. Jövedelmezőbbnek kellene találnia a szabályok betartását — olyan szabályok ezek, amelyek több új érmével kedveznek neki, mint mindenki másnak együttesen —, mint a rendszer és saját vagyonának érvényességének aláásását.
7. Lemezterület visszanyerése
Miután egy érme legutóbbi tranzakciója elegendő blokk alá kerül, az előtte lévő elköltött tranzakciók eldobhatók lemezterület megtakarítása érdekében. Ennek megkönnyítése érdekében anélkül, hogy megtörnénk a blokk „hash”-ét, a tranzakciókat egy „Merkle tree”-ben „hash”-eljük [7][2][5], és csak a gyöker kerül bele a blokk „hash”-ébe. A régi blokkok ezután tömöríthetők a fa ágainak csonkításával. A belső „hash”-eket nem kell tárolni.
Egy tranzakciók nélküli blokkfejléc körülbelül 80 bájt lenne. Ha feltételezzük, hogy a blokkokat 10 percenként generálják: 80 bájt × 6 × 24 × 365 = 4,2 MB évente. 2008-ban a számítógépes rendszereket általában 2 GB RAM-mal árusítják, és Moore törvénye évente 1,2 GB-os növekedést jósol, így a tárolás nem lesz probléma, még akkor sem, ha a blokkfejléceket memóriában kell tartani.
8. Egyszerűsített fizetési ellenőrzés
Lehetséges a fizetések ellenőrzése teljes hálózati „node” futtatása nélkül. A felhasználónak csak a leghosszabb „proof-of-work” lánc blokkfejléceinek másolatát kell megőriznie, amelyet hálózati „node”-ok lekérdezésével szerezhet meg, amíg meg nem győződik arról, hogy a leghosszabb láncot kapja, és be kell szereznie a tranzakciót az időbélyeggel ellátott blokkhoz kötő „Merkle” ágat. Nem tudja maga ellenőrizni a tranzakciót, de a láncban lévő helyre hivatkozva láthatja, hogy egy hálózati „node” elfogadta azt, és az utána hozzáadott blokkok tovább erősítik, hogy a hálózat elfogadta.
Mint ilyen, az ellenőrzés megbízható mindaddig, amíg a becsületes „node”-ok irányítják a hálózatot, de sebezhetőbbé válik, ha a hálózatot egy támadó túlerővel uralja. Miközben a hálózati „node”-ok maguk ellenőrizhetik a tranzakciókat, az egyszerűsített módszert egy támadó koholt tranzakciókkal becsaphatja mindaddig, amíg a támadó folytatni tudja a hálózat túlerejét. Az ezzel szembeni védekezés egyik stratégiája az lenne, hogy elfogadják a hálózati „node”-ok riasztásait, amikor érvénytelen blokkot észlelnek, arra ösztönözve a felhasználó szoftverét, hogy töltse le a teljes blokkot és a riasztott tranzakciókat az ellentmondás megerősítéséhez. Azok a vállalkozások, amelyek sűrű fizetéseket kapnak, valószínűleg saját „node”-okat fognak futtatni a függetlenebb biztonság és gyorsabb ellenőrzés érdekében.
9. Értékek kombinálása és felosztása
Bár lehetséges lenne az érméket egyenként kezelni, kényelmetlen lenne külön tranzakciót csinálni az átutalás minden centjéért. Az érték felosztásának és kombinálásának lehetővé tételéhez a tranzakciók több „input”-ot és „output”-ot tartalmaznak. Általában vagy egyetlen „input” lesz egy nagyobb előző tranzakcióból, vagy több „input” kombinál kisebb összegeket, és legfeljebb két „output” lesz: egy a kifizetésre, és egy a visszajáró visszaküldésére, ha van, a küldőnek.
Meg kell jegyezni, hogy a „fan-out”, ahol egy tranzakció több tranzakciótól függ, és azok a tranzakciók még többtől, itt nem jelent problémát. Soha nincs szükség egy tranzakció előzményeinek teljes önálló másolatának kinyerésére.
10. Adatvédelem
A hagyományos banki modell az adatvédelmet azzal éri el, hogy az információkhoz való hozzáférést az érintett felekre és a megbízható harmadik félre korlátozza. Az összes tranzakció nyilvános bejelentésének szükségessége kizárja ezt a módszert, de az adatvédelem fenntartható azzal, hogy máshol megszakítjuk az információáramlást: a nyilvános kulcsok anonimitásának megőrzésével. A nyilvánosság láthatja, hogy valaki küld egy összeget valaki másnak, de anélkül, hogy a tranzakciót bárki személyhez kötné. Ez hasonló ahhoz az információszinthez, amelyet a tőzsdék tesznek közzé, ahol az egyes kereskedések időpontját és méretét, a „szalagot”, nyilvánosságra hozzák, de anélkül, hogy megmondanák, kik voltak a felek.
További tűzfalként minden tranzakcióhoz új kulcspárt kell használni, hogy ne legyenek összekapcsolhatók egy közös tulajdonossal. Bizonyos összekapcsolás még mindig elkerülhetetlen a több „input”-os tranzakcióknál, amelyek szükségszerűen feltárják, hogy „input”-jaik ugyanannak a tulajdonosnak a tulajdonában voltak. A kockázat az, hogy ha egy kulcs tulajdonosát felfedik, az összekapcsolás más tranzakciókat is feltárhat, amelyek ugyanannak a tulajdonosnak a tulajdonában voltak.
11. Számítások
Azt a forgatókönyvet vizsgáljuk, amelyben egy támadó a becsületes láncnál gyorsabban próbál alternatív láncot generálni. Még ha ez sikerül is, nem nyitja meg a rendszert önkényes változtatások előtt, mint például értéket teremteni a semmiből, vagy olyan pénzt elvenni, amely soha nem tartozott a támadóhoz. A „node”-ok nem fogadnak el érvénytelen tranzakciót fizetésként, és a becsületes „node”-ok soha nem fogadnak el ilyet tartalmazó blokkot. A támadó csak megpróbálhatja megváltoztatni az egyik saját tranzakcióját, hogy visszavegye a nemrég elköltött pénzt.
A becsületes lánc és a támadó lánc közötti verseny jellemezhető „Binomiális Véletlen Séta”-ként. A sikereseménye a becsületes lánc egy blokkal való bővítése (+1 előny), a sikertelenség eseménye a támadó láncának egy blokkal való bővítése (−1 rés).
Annak valószínűsége, hogy a támadó felzárkózik egy adott hátrányból, hasonló a „Gambler’s Ruin” problémához. Tegyük fel, hogy egy korlátlan hitelű játékos hátrányból indul, és potenciálisan végtelen számú próbajátékot játszik, hogy elérhesse a nullszaldót. Kiszámíthatjuk annak valószínűségét, hogy valaha eléri a nullszaldót, vagy hogy egy támadó valaha utolérje a becsületes láncot, az alábbiak szerint [8]:
p = annak valószínűsége, hogy egy becsületes "node" találja meg a következő blokkot q = annak valószínűsége, hogy a támadó találja meg a következő blokkot qz = annak valószínűsége, hogy a támadó valaha utolér z blokk hátrányból qz = 1 ha p ≤ q qz = (q/p)^z ha p > q
Mivel feltételezzük, hogy p > q, a valószínűség exponenciálisan csökken, ahogy a támadónak több blokkot kell utolérnie. Ha nem tesz szerencsés előrelépést korán, esélyei elhanyagolhatóvá válnak, ahogy egyre jobban lemarad.
Most azt vizsgáljuk, mennyi ideig kell várnia az új tranzakció kedvezményezettjének, mielőtt kellően biztos lehet abban, hogy a küldő nem tudja megváltoztatni a tranzakciót. Feltételezzük, hogy a küldő egy támadó, aki azt akarja, hogy a kedvezményezett elhiggye, hogy fizetett neki egy ideig, majd visszafizesse magának, miután eltelt némi idő. A fogadó riasztást kap, amikor ez megtörténik, de a küldő reméli, hogy már késő lesz.
A fogadó új kulcspárt generál, és a nyilvános kulcsot aláírás előtt röviddel átadja a küldőnek. Ez megakadályozza, hogy a küldő előre előkészítsen egy blokkláncat azzal, hogy folyamatosan dolgozik rajta, amíg elég szerencsés nem lesz, hogy elegendően előre jusson, majd abban a pillanatban hajtja végre a tranzakciót. Miután a tranzakciót elküldték, a becstelen küldő titokban elkezd dolgozni egy párhuzamos láncon, amely tranzakciójának alternatív verzióját tartalmazza.
A fogadó megvárja, amíg a tranzakciót egy blokkba adják, és z blokk láncolódik utána. Nem ismeri pontosan a támadó előrehaladásának mértékét, de feltételezve, hogy a becsületes blokkok az átlagos várható időt vették igénybe blokkonként, a támadó lehetséges előrehaladása Poisson-eloszlású lesz, várható értéke: λ = z·(q/p).
Az eloszlás végtelen farkának összegzésének elkerülése érdekében átrendezve, C kódba konvertálva:
#include <math.h>
double AttackerSuccessProbability(double q, int z)
{
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++)
{
double poisson = exp(-lambda);
for (i = 1; i <= k; i++)
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}
Néhány eredmény futtatásával láthatjuk, hogy a valószínűség exponenciálisan csökken z-vel:
q=0.1: z=0 P=1.0000000
z=1 P=0.2045873
z=2 P=0.0509779
z=3 P=0.0131722
z=4 P=0.0034552
z=5 P=0.0009137
z=6 P=0.0002428
z=7 P=0.0000647
z=8 P=0.0000173
z=9 P=0.0000046
z=10 P=0.0000012
q=0.3: z=0 P=1.0000000
z=5 P=0.1773523
z=10 P=0.0416605
z=15 P=0.0101008
z=20 P=0.0024804
z=25 P=0.0006132
z=30 P=0.0001522
z=35 P=0.0000379
z=40 P=0.0000095
z=45 P=0.0000024
z=50 P=0.0000006
P < 0,1% megoldása:
q=0.10 z=5 q=0.15 z=8 q=0.20 z=11 q=0.25 z=15 q=0.30 z=24 q=0.35 z=41 q=0.40 z=89 q=0.45 z=340
12. Következtetés
Javasoltunk egy rendszert az elektronikus tranzakciókhoz anélkül, hogy bizalomra támaszkodnánk. A digitális aláírásokból készült érmék szokásos keretéből indultunk ki, amely erős tulajdonosi ellenőrzést biztosít, de hiányos a „double-spending” megakadályozásának módja nélkül. Ennek megoldásához „peer-to-peer” hálózatot javasoltunk, amely „proof-of-work”-öt alkalmaz a tranzakciók nyilvános előzményeinek rögzítésére, amely gyorsan számítástechnikailag megváltoztathatatlanná válik egy támadó számára, ha a becsületes „node”-ok irányítják a CPU-teljesítmény többségét. A hálózat robusztus a strukturálatlan egyszerűségében. A „node”-ok egyszerre dolgoznak minimális koordinációval. Nem kell azonosítani őket, mivel az üzeneteket nem irányítják semmilyen különleges helyre, és csak legjobb szándékkal kell kézbesíteni. A „node”-ok tetszés szerint hagyhatják el és csatlakozhatnak újra a hálózathoz, a „proof-of-work” láncot elfogadva annak bizonyítékaként, hogy mi történt távollétük alatt. CPU-teljesítményükkel szavaznak, az érvényes blokkok elfogadásukat azok bővítésén való munkával fejezik ki, az érvénytelen blokkokat pedig azzal utasítják el, hogy megtagadják a rajtuk való munkát. Minden szükséges szabály és ösztönző érvényesíthető ezzel a konszenzusmechanizmussal.
Hivatkozások
- W. Dai, „b-money,” http://www.weidai.com/bmoney.txt, 1998.
- H. Massias, X.S. Avila, és J.-J. Quisquater, „Design of a secure timestamping service with minimal trust requirements,” In 20th Symposium on Information Theory in the Benelux, 1999. május.
- S. Haber, W.S. Stornetta, „How to time-stamp a digital document,” In Journal of Cryptology, vol 3, no 2, 99–111. o., 1991.
- D. Bayer, S. Haber, W.S. Stornetta, „Improving the efficiency and reliability of digital time-stamping,” In Sequences II: Methods in Communication, Security and Computer Science, 329–334. o., 1993.
- S. Haber, W.S. Stornetta, „Secure names for bit-strings,” In Proceedings of the 4th ACM Conference on Computer and Communications Security, 28–35. o., 1997. április.
- A. Back, „Hashcash – a denial of service counter-measure,” http://www.hashcash.org/papers/hashcash.pdf, 2002.
- R.C. Merkle, „Protocols for public key cryptosystems,” In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, 122–133. o., 1980. április.
- W. Feller, „An introduction to probability theory and its applications,” 1957.
