Bitcoin: Ein elektronisches Peer-to-Peer-Cash-System
Satoshi Nakamoto
satoshin@gmx.com
www.bitcoin.org
Abstrakt . Eine reine Peer-to-Peer-Version von Electronic Cash würde es ermöglichen, Online-Zahlungen direkt von einer Partei zur anderen zu senden, ohne ein Finanzinstitut zu durchlaufen. Digitale Signaturen stellen einen Teil der Lösung dar, aber die Hauptvorteile gehen verloren, wenn immer noch ein vertrauenswürdiger Dritter erforderlich ist, um doppelte Ausgaben zu verhindern. Wir schlagen eine Lösung für das Double-Spending-Problem vor, indem wir ein Peer-to-Peer-Netzwerk verwenden. Das Netzwerk versieht Transaktionen mit einem Zeitstempel, indem es sie in eine fortlaufende Kette von Hash-basierten Arbeitsnachweisen einfügt und so einen Datensatz bildet, der nicht geändert werden kann, ohne den Arbeitsnachweis zu wiederholen. Die längste Kette dient nicht nur als Beweis für die Abfolge der beobachteten Ereignisse, sondern auch als Beweis dafür, dass sie aus dem größten Pool an CPU-Leistung stammt. Solange ein Großteil der CPU-Leistung von Knoten kontrolliert wird, die nicht kooperieren, um das Netzwerk anzugreifen, werden sie die längste Kette generieren und Angreifer überholen. Das Netzwerk selbst erfordert eine minimale Struktur. Nachrichten werden nach bestem Bemühen gesendet, und Knoten können das Netzwerk nach Belieben verlassen und wieder beitreten, wobei sie die längste Proof-of-Work-Kette als Beweis dafür akzeptieren, was passiert ist, während sie weg waren.
1. Einleitung
Der Handel im Internet stützt sich mittlerweile fast ausschließlich auf Finanzinstitute, die als vertrauenswürdige Dritte dienen, um elektronische Zahlungen zu verarbeiten. Während das System für die meisten Transaktionen gut genug funktioniert, leidet es immer noch unter den inhärenten Schwächen des vertrauensbasierten Modells. Völlig unumkehrbare Transaktionen sind nicht wirklich möglich, da Finanzinstitute nicht umhin kommen, Streitigkeiten zu schlichten. Die Kosten der Mediation erhöhen die Transaktionskosten, begrenzen die praktische Mindesttransaktionsgröße und sperren die Möglichkeit für kleine Gelegenheitstransaktionen aus, und es entstehen weitere Kosten durch den Verlust der Fähigkeit, nicht umkehrbare Zahlungen für nicht umkehrbare Dienstleistungen zu leisten. Mit der Möglichkeit der Umkehrung breitet sich das Bedürfnis nach Vertrauen aus. Händler müssen sich vor ihren Kunden in Acht nehmen und sie mit mehr Informationen belästigen, als sie sonst benötigen würden. Ein gewisser Prozentsatz an Betrug wird als unvermeidbar akzeptiert. Diese Kosten und Zahlungsunsicherheiten können persönlich durch die Verwendung von physischer Währung vermieden werden, aber es gibt keinen Mechanismus, um Zahlungen über einen Kommunikationskanal ohne eine vertrauenswürdige Partei zu tätigen.
Was benötigt wird, ist ein elektronisches Zahlungssystem, das auf einem kryptografischen Nachweis statt auf Vertrauen basiert und es zwei willigen Parteien ermöglicht, direkt miteinander zu handeln, ohne dass ein vertrauenswürdiger Dritter erforderlich ist. Transaktionen, die rechnerisch nicht rückgängig gemacht werden können, würden Verkäufer vor Betrug schützen, und routinemäßige Treuhandmechanismen könnten leicht implementiert werden, um Käufer zu schützen. In diesem Artikel schlagen wir eine Lösung für das Double-Spending-Problem vor, indem wir einen verteilten Peer-to-Peer-Zeitstempelserver verwenden, um einen rechnerischen Nachweis der chronologischen Reihenfolge von Transaktionen zu generieren. Das System ist sicher, solange ehrliche Knoten gemeinsam mehr CPU-Leistung kontrollieren als jede kooperierende Gruppe von Angreiferknoten.
2. Transaktionen
Wir definieren eine elektronische Münze als eine Kette digitaler Signaturen. Jeder Besitzer überträgt die Münze an den nächsten, indem er einen Hash der vorherigen Transaktion und den öffentlichen Schlüssel des nächsten Besitzers digital signiert und an das Ende der Münze anfügt. Ein Zahlungsempfänger kann die Unterschriften verifizieren, um die Eigentumskette zu verifizieren.
Das Problem ist natürlich, dass der Zahlungsempfänger nicht nachweisen kann, dass einer der Besitzer die Münze nicht doppelt ausgegeben hat. Eine gängige Lösung besteht darin, eine vertrauenswürdige zentrale Behörde oder Minze einzuführen, die jede Transaktion auf doppelte Ausgaben überprüft. Nach jeder Transaktion muss die Münze an die Münzstätte zurückgegeben werden, um eine neue Münze auszugeben, und es wird darauf vertraut, dass nur Münzen, die direkt von der Münzstätte ausgegeben wurden, nicht doppelt ausgegeben werden. Das Problem bei dieser Lösung ist, dass das Schicksal des gesamten Geldsystems von dem Unternehmen abhängt, das die Münze betreibt, wobei jede Transaktion genau wie eine Bank über sie laufen muss.
Wir brauchen eine Möglichkeit, damit der Zahlungsempfänger weiß, dass die vorherigen Eigentümer keine früheren Transaktionen unterzeichnet haben. Für unsere Zwecke zählt die früheste Transaktion, daher kümmern wir uns nicht um spätere Versuche, doppelte Ausgaben zu tätigen. Die einzige Möglichkeit, das Fehlen einer Transaktion zu bestätigen, besteht darin, alle Transaktionen zu kennen. Beim mintbasierten Modell war sich die Mint aller Transaktionen bewusst und entschied, welche zuerst eintraf. Um dies ohne eine vertrauenswürdige Partei zu erreichen, müssen Transaktionen öffentlich angekündigt werden [1], und wir brauchen ein System, mit dem sich die Teilnehmer auf einen einzigen Verlauf der Reihenfolge ihres Eingangs einigen können. Der Zahlungsempfänger muss nachweisen, dass zum Zeitpunkt jeder Transaktion die Mehrheit der Knoten zugestimmt hat, dass es sich um die erste Transaktion handelt.
3. Zeitstempelserver
Die von uns vorgeschlagene Lösung beginnt mit einem Zeitstempelserver. Ein Zeitstempelserver funktioniert, indem er einen Hash eines Blocks von Elementen nimmt, die mit einem Zeitstempel versehen werden sollen, und den Hash weithin veröffentlicht, beispielsweise in einer Zeitung oder einem Usenet-Beitrag [2-5]. Der Zeitstempel beweist, dass die Daten zu diesem Zeitpunkt natürlich schon existiert haben müssen, um in den Hash zu gelangen. Jeder Zeitstempel enthält den vorherigen Zeitstempel in seinem Hash und bildet eine Kette, wobei jeder zusätzliche Zeitstempel die davor verstärkt.
4. Arbeitsnachweis
Um einen verteilten Zeitstempelserver auf Peer-to-Peer-Basis zu implementieren, müssen wir ein Proof-of-Work-System ähnlich Adam Backs Hashcash [6] verwenden, anstatt Zeitungs- oder Usenet-Beiträge. Der Proof-of-Work beinhaltet das Scannen nach einem Wert, der, wenn er gehasht wird, wie z. B. bei SHA-256, der Hash mit einer Reihe von Null-Bits beginnt. Die durchschnittlich erforderliche Arbeit ist exponentiell in der Anzahl der erforderlichen Nullbits und kann durch Ausführen eines einzelnen Hashs verifiziert werden.
Für unser Zeitstempelnetzwerk implementieren wir den Proof-of-Work, indem wir eine Nonce im Block inkrementieren, bis ein Wert gefunden wird, der dem Hash des Blocks die erforderlichen Nullbits gibt. Sobald der CPU-Aufwand aufgewendet wurde, um den Proof-of-Work zu erfüllen, kann der Block nicht geändert werden, ohne die Arbeit zu wiederholen. Da spätere Blöcke danach verkettet werden, würde die Arbeit zum Ändern des Blocks das Wiederholen aller Blöcke danach beinhalten.
Der Proof-of-Work löst auch das Problem der Bestimmung der Vertretung bei Mehrheitsentscheidungen. Wenn die Mehrheit auf einer IP-Adresse und einer Stimme basieren würde, könnte dies von jedem untergraben werden, der in der Lage ist, viele IPs zuzuweisen. Proof-of-Work ist im Wesentlichen One-CPU-One-Vote. Die Mehrheitsentscheidung wird durch die längste Kette repräsentiert, in die der größte Proof-of-Work-Aufwand investiert wurde. Wenn ein Großteil der CPU-Leistung von ehrlichen Knoten kontrolliert wird, wächst die ehrliche Kette am schnellsten und übertrifft alle konkurrierenden Ketten. Um einen vergangenen Block zu modifizieren, müsste ein Angreifer den Proof-of-Work des Blocks und aller Blöcke danach wiederholen und dann die Arbeit der ehrlichen Knoten einholen und übertreffen. Wir werden später zeigen, dass die Wahrscheinlichkeit, dass ein langsamerer Angreifer aufholt, exponentiell abnimmt, wenn nachfolgende Blöcke hinzugefügt werden.
Um die zunehmende Hardwaregeschwindigkeit und das unterschiedliche Interesse am Ausführen von Knoten im Laufe der Zeit auszugleichen, wird die Proof-of-Work-Schwierigkeit durch einen gleitenden Durchschnitt bestimmt, der auf eine durchschnittliche Anzahl von Blöcken pro Stunde abzielt. Wenn sie zu schnell generiert werden, erhöht sich die Schwierigkeit.
5. Netzwerk
Die Schritte zum Ausführen des Netzwerks sind wie folgt:
1) Neue Transaktionen werden an alle Knoten gesendet.
2) Jeder Knoten sammelt neue Transaktionen in einem Block.
3) Jeder Knoten arbeitet daran, einen schwierigen Proof-of-Work für seinen Block zu finden.
4) Wenn ein Knoten einen Proof-of-Work findet, sendet er den Block an alle Knoten.
5) Knoten akzeptieren den Block nur, wenn alle darin enthaltenen Transaktionen gültig und nicht bereits ausgegeben sind.
6) Nodes drücken ihre Akzeptanz des Blocks aus, indem sie daran arbeiten, den nächsten Block in der Kette zu erstellen, wobei sie den Hash des akzeptierten Blocks als vorherigen Hash verwenden.
Nodes betrachten immer die längste Kette als die richtige und werden weiter daran arbeiten, sie zu erweitern. Wenn zwei Knoten gleichzeitig verschiedene Versionen des nächsten Blocks aussenden, empfangen einige Knoten möglicherweise zuerst die eine oder die andere. In diesem Fall bearbeiten sie den ersten erhaltenen Zweig, speichern aber den anderen Zweig, falls er länger wird. Die Krawatte wird gebrochen, wenn der nächste Proof-of-Work gefunden wird und ein Ast länger wird; Die Knoten, die an dem anderen Zweig gearbeitet haben, wechseln dann zum längeren.
Neue Transaktionssendungen müssen nicht notwendigerweise alle Knoten erreichen. Solange sie viele Knoten erreichen, werden sie bald in einen Block geraten. Block-Broadcasts sind auch tolerant gegenüber verworfenen Nachrichten. Wenn ein Knoten keinen Block empfängt, fordert er ihn an, wenn er den nächsten Block empfängt und feststellt, dass er einen verpasst hat.
6. Anreiz
Per Konvention ist die erste Transaktion in einem Block eine spezielle Transaktion, die eine neue Münze startet, die dem Ersteller des Blocks gehört. Dies fügt den Nodes einen Anreiz hinzu, das Netzwerk zu unterstützen, und bietet eine Möglichkeit, Münzen zunächst in Umlauf zu bringen, da es keine zentrale Behörde gibt, die sie ausgibt. Das stetige Hinzufügen einer konstanten Menge neuer Münzen ist analog zu Goldminen, die Ressourcen aufwenden, um Gold in den Umlauf zu bringen. In unserem Fall sind es CPU-Zeit und Strom, die aufgewendet werden.
Der Anreiz kann auch mit Transaktionsgebühren finanziert werden. Wenn der Ausgabewert einer Transaktion kleiner als ihr Eingabewert ist, ist die Differenz eine Transaktionsgebühr, die zum Anreizwert des Blocks hinzugefügt wird, der die Transaktion enthält. Sobald eine vorbestimmte Anzahl von Münzen in Umlauf gekommen ist, kann der Anreiz vollständig auf Transaktionsgebühren übergehen und völlig inflationsfrei sein.
Der Anreiz kann dazu beitragen, Knoten zu ermutigen, ehrlich zu bleiben. Wenn ein gieriger Angreifer mehr CPU-Leistung als alle ehrlichen Knoten zusammenbauen kann, müsste er wählen, ob er damit Menschen betrügen möchte, indem er seine Zahlungen zurückstiehlt, oder ob er damit neue Coins generiert. Er sollte es profitabler finden, sich an die Regeln zu halten, solche Regeln, die ihn mit mehr neuen Münzen begünstigen als alle anderen zusammen, als das System und die Gültigkeit seines eigenen Reichtums zu untergraben.
7. Rückgewinnung von Speicherplatz
Sobald die letzte Transaktion in einer Münze unter genügend Blöcken begraben ist, können die zuvor ausgegebenen Transaktionen verworfen werden, um Speicherplatz zu sparen. Um dies zu erleichtern, ohne den Hash des Blocks zu brechen, werden Transaktionen in einem Merkle Tree [7][2][5] gehasht, wobei nur die Wurzel im Hash des Blocks enthalten ist. Alte Blöcke können dann verdichtet werden, indem Äste des Baums abgestumpft werden. Die internen Hashes müssen nicht gespeichert werden.
Ein Block-Header ohne Transaktionen wäre etwa 80 Bytes groß. Wenn wir davon ausgehen, dass Blöcke alle 10 Minuten generiert werden, sind 80 Bytes * 6 * 24 * 365 = 4,2 MB pro Jahr. Mit Computersystemen, die ab 2008 typischerweise mit 2 GB RAM verkauft werden, und dem Mooreschen Gesetz, das ein aktuelles Wachstum von
1,2 GB pro Jahr sollte die Speicherung kein Problem darstellen, auch wenn die Blockheader im Speicher gehalten werden müssen.
8. Vereinfachte Zahlungsüberprüfung
Es ist möglich, Zahlungen zu verifizieren, ohne einen vollständigen Netzwerkknoten zu betreiben. Ein Benutzer muss nur eine Kopie der Blockheader der längsten Proof-of-Work-Kette aufbewahren, die er durch Abfragen von Netzwerkknoten erhalten kann, bis er überzeugt ist, dass er die längste Kette hat, und den Merkle-Zweig erhalten, der die Transaktion mit dem Block verknüpft es ist mit einem Zeitstempel versehen. Er kann die Transaktion nicht selbst überprüfen, aber indem er sie mit einer Stelle in der Kette verknüpft, kann er sehen, dass ein Netzwerkknoten sie akzeptiert hat, und hinzugefügte Blöcke bestätigen, dass das Netzwerk sie akzeptiert hat.
Daher ist die Überprüfung zuverlässig, solange ehrliche Knoten das Netzwerk kontrollieren, ist jedoch anfälliger, wenn das Netzwerk von einem Angreifer überwältigt wird. Während Netzwerkknoten Transaktionen selbst verifizieren können, kann die vereinfachte Methode durch die erfundenen Transaktionen eines Angreifers getäuscht werden, solange der Angreifer das Netzwerk weiterhin überwältigen kann. Eine Strategie, sich dagegen zu schützen, wäre es, Warnungen von Netzwerkknoten zu akzeptieren, wenn sie einen ungültigen Block entdecken, und die Software des Benutzers aufzufordern, den vollständigen Block herunterzuladen und Transaktionen zu alarmieren, um die Inkonsistenz zu bestätigen. Unternehmen, die häufige Zahlungen erhalten, werden wahrscheinlich immer noch ihre eigenen Knoten für mehr unabhängige Sicherheit und schnellere Überprüfung betreiben wollen.
9. Kombinieren und Splitten von Werten
Obwohl es möglich wäre, Münzen einzeln zu handhaben, wäre es unhandlich, für jeden Cent einer Überweisung eine separate Transaktion durchzuführen. Damit Werte aufgeteilt und kombiniert werden können, enthalten Transaktionen mehrere Eingaben und Ausgaben. Normalerweise gibt es entweder eine einzige Eingabe aus einer größeren früheren Transaktion oder mehrere Eingaben, die kleinere Beträge kombinieren, und höchstens zwei Ausgaben: eine für die Zahlung und eine, die das Wechselgeld, falls vorhanden, an den Absender zurückgibt.
Es sei darauf hingewiesen, dass Fan-out, bei dem eine Transaktion von mehreren Transaktionen abhängt und diese Transaktionen von vielen weiteren abhängen, hier kein Problem darstellt. Es besteht nie die Notwendigkeit, eine vollständige eigenständige Kopie der Historie einer Transaktion zu extrahieren.
10. Datenschutz
Das traditionelle Bankenmodell erreicht ein gewisses Maß an Datenschutz, indem es den Zugang zu Informationen auf die beteiligten Parteien und den vertrauenswürdigen Dritten beschränkt. Die Notwendigkeit, alle Transaktionen öffentlich bekannt zu geben, schließt diese Methode aus, aber die Privatsphäre kann immer noch gewahrt werden, indem der Informationsfluss an anderer Stelle unterbrochen wird: durch die Anonymisierung öffentlicher Schlüssel. Die Öffentlichkeit kann sehen, dass jemand einen Betrag an jemand anderen sendet, jedoch ohne Informationen, die die Transaktion mit jemandem verknüpfen. Dies ist vergleichbar mit dem Informationsniveau der Börsen, wo der Zeitpunkt und die Größe einzelner Trades, das „Tape“, öffentlich gemacht werden, ohne jedoch zu sagen, wer die Parteien waren.
Als zusätzliche Firewall sollte für jede Transaktion ein neues Schlüsselpaar verwendet werden, um zu verhindern, dass sie einem gemeinsamen Eigentümer zugeordnet werden. Eine gewisse Verknüpfung ist bei Multi-Input-Transaktionen immer noch unvermeidlich, was notwendigerweise offenbart, dass ihre Eingaben demselben Eigentümer gehörten. Das Risiko besteht darin, dass, wenn der Besitzer eines Schlüssels aufgedeckt wird, die Verknüpfung andere Transaktionen aufdecken könnte, die demselben Besitzer gehörten.
11. Berechnungen
Wir betrachten das Szenario eines Angreifers, der versucht, eine alternative Kette schneller als die ehrliche Kette zu generieren. Selbst wenn dies erreicht wird, wird das System nicht willkürlichen Änderungen ausgesetzt, wie z. B. der Schaffung von Werten aus dem Nichts oder der Einnahme von Geld, das dem Angreifer nie gehört hat. Knoten werden eine ungültige Transaktion nicht als Zahlung akzeptieren, und ehrliche Knoten werden niemals einen Block akzeptieren, der sie enthält. Ein Angreifer kann nur versuchen, eine seiner eigenen Transaktionen zu ändern, um kürzlich ausgegebenes Geld zurückzuerhalten.
Das Rennen zwischen der ehrlichen Kette und einer Angreiferkette kann als Binomial Random Walk charakterisiert werden. Das Erfolgsereignis ist, dass die ehrliche Kette um einen Block verlängert wird, wodurch ihr Vorsprung um +1 erhöht wird, und das Fehlerereignis ist, dass die Kette des Angreifers um einen Block verlängert wird, wodurch die Lücke um -1 verringert wird.
Die Wahrscheinlichkeit, dass ein Angreifer ein gegebenes Defizit aufholt, ist analog zu einem Gambler's Ruin-Problem. Angenommen, ein Spieler mit unbegrenztem Kredit beginnt mit einem Defizit und spielt möglicherweise eine unendliche Anzahl von Versuchen, um zu versuchen, die Gewinnschwelle zu erreichen.
Unter der Annahme, dass p > q ist, sinkt die Wahrscheinlichkeit exponentiell, wenn die Anzahl der Blöcke zunimmt, die der Angreifer einholen muss. Mit den Chancen gegen ihn werden seine Chancen verschwindend gering, wenn er nicht früh einen glücklichen Sprung nach vorne macht, wenn er weiter zurückfällt.
Wir betrachten nun, wie lange der Empfänger einer neuen Transaktion warten muss, bevor er hinreichend sicher ist, dass der Sender die Transaktion nicht ändern kann. Wir gehen davon aus, dass der Absender ein Angreifer ist, der dem Empfänger vorgaukeln will, er habe ihn für eine Weile bezahlt, und ihn dann nach einiger Zeit so umstellen, dass er an sich selbst zurückzahlt. Der Empfänger wird benachrichtigt, wenn das passiert, aber der Sender hofft, dass es zu spät ist.
Der Empfänger generiert ein neues Schlüsselpaar und gibt den öffentlichen Schlüssel kurz vor dem Signieren an den Sender weiter. Dies verhindert, dass der Absender eine Kette von Blöcken im Voraus vorbereitet, indem er kontinuierlich daran arbeitet, bis er das Glück hat, weit genug voranzukommen, und dann die Transaktion in diesem Moment ausführt. Sobald die Transaktion gesendet wurde, beginnt der unehrliche Absender heimlich an einer parallelen Kette zu arbeiten, die eine alternative Version seiner Transaktion enthält.
Der Empfänger wartet, bis die Transaktion zu einem Block hinzugefügt wurde und z Blöcke danach verknüpft wurden. Er kennt den genauen Fortschritt des Angreifers nicht, aber unter der Annahme, dass die ehrlichen Blöcke die durchschnittlich erwartete Zeit pro Block benötigten, ist der potenzielle Fortschritt des Angreifers eine Poisson-Verteilung.
12. Fazit
Wir haben ein System für elektronische Transaktionen vorgeschlagen, ohne sich auf Vertrauen zu verlassen. Wir begannen mit dem üblichen Rahmen von Coins, die aus digitalen Signaturen hergestellt wurden, was eine starke Kontrolle des Eigentums bietet, aber ohne eine Möglichkeit, doppelte Ausgaben zu verhindern, unvollständig ist. Um dies zu lösen, haben wir ein Peer-to-Peer-Netzwerk vorgeschlagen, das Proof-of-Work verwendet, um eine öffentliche Historie von Transaktionen aufzuzeichnen, die für einen Angreifer schnell rechnerisch unpraktisch wird, um sie zu ändern, wenn ehrliche Knoten einen Großteil der CPU-Leistung kontrollieren. Das Netzwerk ist robust in seiner unstrukturierten Einfachheit. Knoten arbeiten alle gleichzeitig mit wenig Koordination. Sie müssen nicht identifiziert werden, da Nachrichten nicht an einen bestimmten Ort geleitet werden und nur nach besten Kräften zugestellt werden müssen. Knoten können das Netzwerk nach Belieben verlassen und wieder beitreten und die Proof-of-Work-Kette als Beweis dafür akzeptieren, was passiert ist, während sie weg waren. Sie stimmen mit ihrer CPU-Leistung ab, indem sie gültige Blöcke akzeptieren, indem sie an deren Erweiterung arbeiten, und ungültige Blöcke ablehnen, indem sie sich weigern, an ihnen zu arbeiten. Alle erforderlichen Regeln und Anreize können mit diesem Konsensmechanismus durchgesetzt werden.
Referenzen[1] W. Dai, "b-money", http://www.weidai.com/bmoney.txt, 1998.[2]H. Massias , XS Avila und J.-J. Quisquater , "Entwurf eines sicheren Zeitstempeldienstes mit minimalen Vertrauensanforderungen", In 20th Symposium on Information Theory in the Benelux, May 1999.[3] S. Haber, WS Stornetta , "How to time-stamp a digital document", In Journal of Cryptology, Bd. 3, Nr. 2, Seiten 99-111, 1991.[4] D. Bayer, S. Haber, WS Stornetta , „Verbesserung der Effizienz und Zuverlässigkeit digitaler Zeitstempel“, In Sequences II: Methods in Communication, Security and Computer Science, Seiten 329-334, 1993.[5] S. Haber, WS Stornetta , "Secure names for bit-strings", In Proceedings of the 4th ACM Conference on Computer and Communications Security, Seiten 28-35, April 1997.[6] A. Back, „ Hashcash – a Denial of Service Counter-Measure“, http://www.hashcash.org/papers/hashcash.pdf, 2002.[7] RC Merkle, "Protokolle für Kryptosysteme mit öffentlichem Schlüssel", In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, Seiten 122-133, April 1980.[8]W. Feller, „Eine Einführung in die Wahrscheinlichkeitstheorie und ihre Anwendungen“, 1957.
Bitcoins kaufen
Hier können Sie Bitcoin kaufen .