Bitcoin: Elektronisches Peer-to-Peer-Cash-System

Abstrakt. Eine reine Peer-to-Peer-Version des elektronischen Geldes wird es ermöglichen, Online-Zahlungen direkt von einer Partei zur anderen zu senden und dabei das Finanzinstitut zu umgehen. Digitale Signaturen stellen einen Teil der Lösung dar, aber die Hauptvorteile gehen verloren, wenn weiterhin ein vertrauenswürdiger Dritter erforderlich ist, um doppelte Ausgaben zu verhindern. Wir schlagen eine Lösung für das Problem der doppelten Ausgaben mithilfe eines Peer-to-Peer-Netzwerks vor. Das Netzwerk markiert Transaktionen, indem es sie in eine kontinuierliche Kette von Hash-basierten Arbeitsnachweisen einfügt und so einen Datensatz erstellt, der nicht geändert werden kann, ohne den Arbeitsnachweis erneut auszuführen. 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 Prozessorleistung stammt. Solange der Großteil der CPU-Leistung von Knoten kontrolliert wird, die nicht an Angriffen auf das Netzwerk beteiligt sind, werden sie die längste Kette erzeugen und die Angreifer überholen. Das Netzwerk selbst erfordert eine minimale Struktur. Nachrichten werden auf bestmöglicher Basis übertragen, und Knoten können das Netzwerk nach Belieben verlassen und wieder beitreten, wobei die längste Proof-of-Work-Kette als Beweis dafür herangezogen wird, was während ihrer Abwesenheit passiert ist.

Satoshi Nakamoto
satoshin@gmx.com
www.bitcoin.org

1. Einleitung

Der Online-Handel verlässt sich mittlerweile fast ausschließlich auf Finanzinstitute, die bei der Abwicklung elektronischer Zahlungen als vertrauenswürdige Dritte fungieren. Obwohl das System für die meisten Transaktionen gut genug funktioniert, weist es dennoch die Nachteile auf, die ein vertrauensbasiertes Modell mit sich bringt. Völlig unumkehrbare Transaktionen sind eigentlich nicht möglich, da Finanzinstitute nicht umhinkommen, Streitigkeiten zu vermitteln. Die Vermittlungskosten erhöhen die Transaktionskosten, indem sie die minimale praktische Größe einer Transaktion begrenzen und die Möglichkeit kleiner Zufallstransaktionen ausschließen, und die umfassenderen Kosten sind mit dem Verlust der Fähigkeit verbunden, irreversible Zahlungen für irreversible Dienstleistungen zu leisten. Mit der Möglichkeit einer Umkehr wächst das Bedürfnis nach Vertrauen. Händler müssen gegenüber ihren Kunden auf der Hut sein und sie um mehr Informationen bitten, als sie sonst benötigen würden. Ein gewisser Prozentsatz an Betrug gilt als unvermeidlich. Diese Kosten und Zahlungsunsicherheiten können persönlich durch die Verwendung physischer Währung vermieden werden, es gibt jedoch keinen Mechanismus, um Zahlungen über einen Kommunikationskanal ohne eine vertrauenswürdige Partei vorzunehmen.

Was benötigt wird, ist ein elektronisches Zahlungssystem, das auf kryptografischen Beweisen und nicht auf Vertrauen basiert und es zwei willigen Parteien ermöglicht, direkt miteinander Geschäfte abzuwickeln, ohne dass ein vertrauenswürdiger Dritter erforderlich ist. Transaktionen, die sich rechnerisch nicht rückgängig machen lassen, schützen Verkäufer vor Betrug, und herkömmliche Treuhandmechanismen können zum Schutz von Käufern problemlos implementiert werden. In diesem Artikel schlagen wir eine Lösung für das Problem der doppelten Ausgaben vor, indem wir einen verteilten Peer-to-Peer-Zeitstempelserver verwenden, um einen rechnerischen Beweis für die chronologische Reihenfolge von Transaktionen zu generieren. Das System ist sicher, solange die ehrlichen 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 gibt die Münze an den nächsten weiter, indem er den Hash der vorherigen Transaktion und den öffentlichen Schlüssel des nächsten Besitzers digital signiert und am Ende der Münze hinzufügt. Der Zahlungsempfänger kann die Unterschriften überprüfen, um die Eigentumskette zu bestätigen.

Das Problem besteht natürlich darin, dass der Zahlungsempfänger nicht überprüfen kann, ob einer der Besitzer die Münze nicht zweimal ausgegeben hat. Eine gängige Lösung besteht darin, eine vertrauenswürdige zentrale Behörde (Mint) einzurichten, die jede Transaktion auf Doppelausgaben überprüft. Nach jeder Transaktion muss die Münze an die Münzprägeanstalt zurückgegeben werden, um eine neue Münze auszugeben, und nur Münzen, die direkt von der Münzprägeanstalt ausgegeben werden, werden garantiert nicht doppelt ausgegeben. Das Problem bei dieser Lösung besteht darin, dass das Schicksal des gesamten Währungssystems von der Firma abhängt, die die Münzstätte betreibt, und jede Transaktion über diese abgewickelt werden muss, genau wie bei einer Bank.

Wir benötigen eine Möglichkeit, damit der Zahlungsempfänger weiß, dass die Vorbesitzer keine früheren Transaktionen unterzeichnet haben. Für unsere Zwecke wird die früheste Transaktion gezählt, sodass uns nachfolgende Doppelausgabeversuche egal sind. Die einzige Möglichkeit, das Fehlen einer Transaktion zu bestätigen, besteht darin, alle Transaktionen zu kennen. Im münzenbasierten Modell wusste die Münze über alle Transaktionen Bescheid und entschied, welche zuerst eintrafen. Um dies ohne eine vertrauenswürdige Partei zu erreichen, müssen Transaktionen öffentlich bekannt gegeben werden [1] und wir brauchen ein System, das es den Teilnehmern ermöglicht, sich auf eine einzige Historie der Reihenfolge zu einigen, in der sie empfangen wurden. Der Zahlungsempfänger benötigt den Nachweis, dass bei jeder Transaktion die Mehrheit der Knoten zugestimmt hat, dass die Transaktion zuerst empfangen wurde.

3. Zeitstempelserver

Unsere vorgeschlagene Lösung beginnt mit einem Zeitstempelserver. Ein Zeitstempelserver funktioniert, indem er einen Hash eines Blocks von Elementen, die mit einem Zeitstempel versehen werden müssen, nimmt und diesen Hash weithin veröffentlicht, beispielsweise in einer Zeitung oder einem Usenet-Beitrag [2–5]. Der Zeitstempel beweist, dass die Daten zu diesem Zeitpunkt offensichtlich vorhanden sein mussten, um in den Hash aufgenommen zu werden. Jeder Zeitstempel enthält den vorherigen Zeitstempel in seinem Hash und bildet so eine Kette, wobei jeder zusätzliche Zeitstempel den vorherigen verstärkt.

4. Arbeitsnachweis

Um einen verteilten Peer-to-Peer-Zeitstempelserver zu implementieren, müssten wir anstelle von Zeitungsbeiträgen oder dem Usenet ein Proof-of-Work-System verwenden, das Adam Backs Hashcash [6] ähnelt. Beim Arbeitsnachweis wird ein Wert gescannt, dessen Hash-Code beispielsweise mit SHA-256 mit einer Reihe von Nullbits beginnt. Der durchschnittliche Arbeitsaufwand hängt exponentiell von der Anzahl der erforderlichen Nullbits ab und kann durch die Durchführung eines einzelnen Hashs überprüft werden.

Für unser Zeitstempelnetzwerk implementieren wir einen Proof of Work, indem wir die Nonce in einem Block erhöhen, bis ein Wert gefunden wird, der dem Block-Hash die notwendigen Nullbits gibt. Sobald die CPU-Leistung aufgewendet wurde, um den Arbeitsnachweis zu erfüllen, kann der Block nicht mehr geändert werden, ohne die Arbeit erneut auszuführen. Da nachfolgende Blöcke danach angehängt werden, erfordert die Änderung eines Blocks die Überarbeitung aller nachfolgenden Blöcke.

Der Arbeitsnachweis löst auch das Problem der Bestimmung der Vertretung bei Mehrheitsentscheidungen. Würde die Mehrheit auf dem Grundsatz „Eine IP-Adresse, eine Stimme“ beruhen, könnte sie von jedem widerlegt werden, der viele IP-Adressen vergeben könnte. Beim Arbeitsnachweis gilt im Wesentlichen „ein Bearbeiter, eine Stimme“. Die Mehrheitslösung wird durch die längste Kette repräsentiert, die den größten Aufwand in die Prüfung der Arbeit gesteckt hat. Wenn der Großteil der CPU-Leistung von ehrlichen Knoten gesteuert wird, wächst die ehrliche Kette am schnellsten und übertrifft alle konkurrierenden Ketten. Um einen vorherigen Block zu ändern, müsste ein Angreifer den Arbeitsnachweis des Blocks und aller darauf folgenden Blöcke wiederholen und dann die Arbeit ehrlicher Knoten einholen und übertreffen. Wir werden später zeigen, dass die Wahrscheinlichkeit, dass ein langsamerer Angreifer aufholt, exponentiell abnimmt, wenn weitere Blöcke hinzugefügt werden.

Um steigende Hardwaregeschwindigkeiten und sich änderndes Interesse am Betrieb von Knoten im Laufe der Zeit auszugleichen, wird der Nachweis der Arbeitsschwierigkeit mithilfe eines gleitenden Durchschnitts ermittelt, der auf die durchschnittliche Anzahl von Blöcken pro Stunde abzielt. Wenn sie zu schnell generiert werden, erhöht sich die Schwierigkeit.

5. Netzwerk

Die Schritte zum Starten 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 komplexen Arbeitsnachweis für seinen Block zu finden.
4. Wenn ein Knoten einen Arbeitsnachweis findet, sendet er den Block an alle Knoten.
5. Knoten akzeptieren einen Block nur, wenn alle darin enthaltenen Transaktionen gültig und noch nicht ausgegeben wurden.
6. Knoten drücken ihre Akzeptanz eines Blocks aus, indem sie an der Erstellung des nächsten Blocks in der Kette arbeiten und dabei den Hash des akzeptierten Blocks als vorherigen Hash verwenden.

Die Knoten betrachten immer die längste Kette als die richtige und arbeiten weiter an deren Erweiterung. Wenn zwei Knoten gleichzeitig unterschiedliche Versionen des nächsten Blocks senden, empfangen einige Knoten möglicherweise zuerst die eine oder andere Version. In diesem Fall arbeiten sie mit dem ersten Zweig, den sie erhalten, behalten aber einen anderen Zweig für den Fall, dass dieser länger wird. Die Verknüpfung wird unterbrochen, wenn der nächste Arbeitsnachweis gefunden wird, und ein Zweig wird länger; Knoten, die am anderen Zweig arbeiten, wechseln zum längeren.

Die Übertragung neuer Transaktionen muss nicht alle Knoten erreichen. Sobald sie viele Knoten erreichen, landen sie bald in einem Block. Block-Broadcasts tolerieren auch verpasste Nachrichten. Wenn ein Knoten keinen Block empfangen hat, fordert er einen an, wenn er den nächsten Block empfängt und erkennt, dass er einen verpasst hat.

6. Anreiz

Konventionell ist die erste Transaktion in einem Block eine spezielle Transaktion, die einen neuen Coin im Besitz des Erstellers des Blocks startet. Dies stellt einen Anreiz für die Nodes dar, das Netzwerk aufrechtzuerhalten, und ermöglicht die anfängliche Verteilung von Münzen in den Umlauf, da es keine zentrale Behörde gibt, die sie ausgibt. Das ständige Hinzufügen einer konstanten Anzahl neuer Münzen ähnelt der Art und Weise, wie Goldgräber Ressourcen aufwenden, um Gold in den Umlauf zu bringen. In unserem Fall werden Prozessorzeit und Strom verschwendet.

Der Anreiz könnte auch über Transaktionsgebühren finanziert werden. Wenn der Ausgabewert einer Transaktion geringer ist als der Eingabewert, ist die Differenz eine Transaktionsgebühr, die zum Anreizwert des Blocks, der die Transaktion enthält, addiert wird. Sobald eine vorher festgelegte Anzahl an Münzen in Umlauf gelangt, kann der Anreiz vollständig auf Transaktionsgebühren verlagert werden und völlig frei von Inflation sein.

Ein Anreiz kann Knoten dabei helfen, ehrlich zu bleiben. Wenn ein gieriger Angreifer mehr CPU-Leistung als alle ehrlichen Knoten sammeln kann, muss er sich entscheiden, ob er sie nutzen möchte, um andere zu betrügen, indem er seine Zahlungen stiehlt, oder ob er sie zur Generierung neuer Münzen nutzt. Er sollte es profitabler finden, sich an die Regeln zu halten, Regeln, die es ihm ermöglichen, mehr neue Münzen zu erhalten als alle anderen zusammen, als das System und die Gültigkeit seines eigenen Reichtums zu untergraben.

7. Geben Sie Speicherplatz frei

Sobald die letzte Transaktion einer Münze unter genügend Blöcken verborgen ist, können die davor ausgegebenen Transaktionen verworfen werden, um Speicherplatz zu sparen. Um dies zu ermöglichen, ohne den Block-Hash zu verletzen, werden Transaktionen in einem Merkle-Baum [7][2][5] gehasht, wobei nur die Wurzel im Block-Hash enthalten ist. Alte Blöcke können dann durch Abschneiden von Ästen verdichtet werden. Es besteht keine Notwendigkeit, interne Hashes zu speichern.

Der Blockheader ohne Transaktionen wird etwa 80 Byte groß sein. Wenn wir davon ausgehen, dass alle 10 Minuten Blöcke generiert werden, dann sind 80 Bytes * 6 * 24 * 365 = 4,2 MB pro Jahr. Da Computersysteme im Jahr 2008 typischerweise mit 2 GB RAM verkauft wurden und Moores Gesetz ein aktuelles Wachstum von 1,2 GB pro Jahr vorhersagt, sollte die Speicherung kein Problem darstellen, selbst wenn Blockheader im Speicher gespeichert werden müssen.

8. Vereinfachte Zahlungsüberprüfung

Sie können Zahlungen bestätigen, ohne einen vollständigen Netzwerkknoten zu starten. Der Benutzer muss lediglich eine Kopie der Blockheader der längsten Proof-of-Work-Kette aufbewahren, die er durch Abfragen der Netzwerkknoten erhalten kann, bis er sicher ist, dass er über die längste Kette verfügt, und den Merkle-Zweig erhalten, der die Transaktion mit dem Block verknüpft . es hat einen Zeitstempel. Er kann die Transaktion nicht selbst verifizieren, aber indem er sie mit einer Stelle in der Kette verknüpft, kann er sehen, dass ein Knoten im Netzwerk sie akzeptiert hat, und die nach ihr hinzugefügten Blöcke bestätigen zusätzlich, dass das Netzwerk sie akzeptiert hat.

Somit ist die Überprüfung zuverlässig, solange ehrliche Knoten das Netzwerk kontrollieren, wird jedoch anfälliger, wenn das Netzwerk unter der Kontrolle eines Angreifers steht. Obwohl Netzwerkknoten selbst Transaktionen überprüfen können, kann eine Abkürzungsmethode durch die gefälschten Transaktionen eines Angreifers getäuscht werden, solange der Angreifer das Netzwerk weiterhin überwältigen kann. Eine Strategie zum Schutz davor wäre, Warnungen von Netzwerkknoten zu akzeptieren, wenn sie einen ungültigen Block erkennen, die Benutzersoftware aufzufordern, den vollständigen Block herunterzuladen, und Transaktionen zu warnen, um die Diskrepanz zu bestätigen. Unternehmen, die häufig Zahlungen erhalten, möchten wahrscheinlich weiterhin ihre eigenen Knoten betreiben, um eine unabhängigere Sicherheit und eine schnellere Überprüfung zu gewährleisten.

9. Werte bündeln und teilen

Während es möglich wäre, Münzen einzeln zu verarbeiten, wäre es umständlich, für jeden überwiesenen Cent eine separate Transaktion durchzuführen. Um die gemeinsame Nutzung und Bündelung von Werten zu ermöglichen, enthalten Transaktionen mehrere Ein- und Ausgänge. Typischerweise gibt es entweder eine Eingabe aus einer größeren vorherigen Transaktion oder mehrere Eingaben, die kleinere Beträge kombinieren, und nicht mehr als zwei Ausgaben: eine für die Zahlung und eine für die Rückgabe von etwaigem Wechselgeld an den Absender.

Es ist zu beachten, dass Forking, bei dem eine Transaktion von mehreren Transaktionen abhängt und diese Transaktionen von vielen anderen abhängen, hier kein Problem darstellt. Es besteht nie die Notwendigkeit, eine vollständige Offline-Kopie Ihres Transaktionsverlaufs abzurufen.

10. Datenschutz

Das traditionelle Bankmodell bietet ein gewisses Maß an Privatsphäre, indem es den Zugriff auf Informationen auf teilnehmende Parteien und vertrauenswürdige Dritte beschränkt. Die Notwendigkeit, alle Transaktionen öffentlich bekannt zu geben, schließt diese Methode aus, aber die Privatsphäre kann dennoch gewahrt werden, indem der Informationsfluss an anderer Stelle unterbrochen wird: die Anonymisierung öffentlicher Schlüssel. Die Öffentlichkeit kann sehen, dass jemand einen Betrag an eine andere Person sendet, jedoch ohne Informationen, die die Transaktion mit jemandem in Verbindung bringen. Dies ähnelt dem Informationsniveau der Börsen, bei denen der Zeitpunkt und das Volumen einzelner Geschäfte, das „Tape“, veröffentlicht werden, ohne jedoch die Parteien zu identifizieren.

Als zusätzliche Firewall sollte für jede Transaktion ein neues Schlüsselpaar verwendet werden, um eine Bindung an einen gemeinsamen Eigentümer zu verhindern. Bei Transaktionen mit mehreren Eingaben, die notwendigerweise zeigen, dass ihre Eingaben demselben Eigentümer gehörten, ist eine gewisse Kopplung immer noch unvermeidlich. Das Risiko besteht darin, dass, wenn der Eigentümer des Schlüssels bekannt gegeben wird, die Bindung andere Transaktionen desselben Eigentümers offenlegen könnte.

11. Berechnungen

Wir betrachten ein Szenario, in dem ein Angreifer versucht, eine alternative Kette schneller als die ehrliche Kette zu erstellen. Selbst wenn dies gelingt, wird das System nicht für willkürliche Veränderungen anfällig sein, wie zum Beispiel die Schaffung von Werten aus dem Nichts oder die Entnahme von Geldern, die nie dem Angreifer gehörten. Knoten akzeptieren keine ungültige Transaktion als Zahlung, und ehrliche Knoten akzeptieren niemals einen Block, der sie enthält. Ein Angreifer könnte versuchen, nur eine seiner Transaktionen zu ändern, um das zuletzt ausgegebene Geld zurückzubekommen.

Der Wettlauf zwischen einer ehrlichen Kette und einer böswilligen Kette kann als binomialer Zufallslauf charakterisiert werden. Ein Erfolgsereignis ist die Verlängerung der ehrlichen Kette um einen Block, wodurch sich ihr Vorsprung um +1 erhöht, und ein Misserfolgsereignis ist die Verlängerung der Kette des Angreifers um einen Block, wodurch sich der Vorsprung um -1 verringert.

Die Wahrscheinlichkeit, dass ein Angreifer einen bestimmten Rückstand ausgleicht, ähnelt dem Problem, dass ein Spieler pleite geht. Nehmen wir an, ein Spieler mit unbegrenztem Guthaben beginnt mit einem Defizit und unternimmt möglicherweise unendlich viele Versuche, um die Gewinnschwelle zu erreichen. Wir können die Wahrscheinlichkeit, dass es jemals die Gewinnschwelle erreicht oder dass der Angreifer jemals zur ehrlichen Kette aufschließen wird, wie folgt berechnen [8]:

p = Wahrscheinlichkeit, dass ein ehrlicher Knoten den nächsten Block findet
q = Wahrscheinlichkeit, dass ein Angreifer den nächsten Block findet
qz = Wahrscheinlichkeit, dass ein Angreifer jemals z Blöcke dahinter einholen wird

Unter der Annahme, dass p > q, sinkt die Wahrscheinlichkeit exponentiell, wenn die Anzahl der Blöcke, die der Angreifer einholen muss, zunimmt. Angesichts der gegen ihn stehenden Chancen werden seine Chancen verschwindend gering, wenn er nicht gleich zu Beginn einen erfolgreichen Vorstoß macht, je weiter er zurückfällt.

Wir schauen uns nun an, wie lange der Empfänger einer neuen Transaktion warten muss, bevor er einigermaßen sicher ist, dass der Absender die Transaktion nicht ändern kann. Wir gehen davon aus, dass es sich beim Absender um einen Angreifer handelt, der dem Empfänger vorgaukeln möchte, dass er ihn eine Zeit lang bezahlt hat, und ihn dann dazu verleiten will, das Geld nach einiger Zeit an sich selbst zurückzugeben. In diesem Fall wird der Empfänger benachrichtigt, der Absender hofft jedoch, dass es zu spät ist.

Der Empfänger generiert ein neues Schlüsselpaar und übermittelt den öffentlichen Schlüssel kurz vor der Signatur an den Absender. Dies verhindert, dass der Absender die Blockchain im Voraus vorbereitet, kontinuierlich daran arbeitet, bis er das Glück hat, weit genug voranzukommen, und dann an diesem Punkt die Transaktion ausführt. Sobald die Transaktion gesendet wurde, beginnt der unehrliche Absender heimlich an einer Parallelkette zu arbeiten, die eine alternative Version seiner Transaktion enthält.

Der Empfänger wartet, bis die Transaktion dem Block hinzugefügt wird und danach z-Blöcke zugeordnet sind. Der genaue Fortschritt des Angreifers ist nicht bekannt, aber unter der Annahme, dass ehrliche Blöcke die durchschnittlich erwartete Zeit pro Block in Anspruch nehmen, ist der potenzielle Fortschritt des Angreifers eine Poisson-Verteilung mit dem erwarteten Wert:

Um die Wahrscheinlichkeit zu erhalten, dass ein Angreifer jetzt noch aufholen könnte, multiplizieren wir die Poisson-Dichte für jeden Fortschritt, den er machen könnte, mit der Wahrscheinlichkeit, dass er von diesem Punkt an aufholen könnte:

Neuordnung, um eine Summierung des unendlichen Endes der Verteilung zu vermeiden ...

In C-Code konvertieren...

 #include <math.h>
double AttackerSuccessProbability(double q, int z)
{
     double p = 1.0 - q;
     doppeltes Lambda = z*(q/p);
     Doppelsumme = 1,0;
     Intervall i, k;
     for (k = 0; k <= z; k++)
     {
          double Poisson = exp(-lambda);
          für (i = 1; i <= k; i++)
               Poisson *= lambda / i;
          sum -= Poisson * (1 - pow(q/p, z - k));
     }
     ReturnAmount;
}

Nachdem wir einige Ergebnisse ausgeführt haben, können wir sehen, dass die Wahrscheinlichkeit mit zunehmendem z exponentiell abnimmt.

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

Lösung für P weniger als 0,1 %...

P < 0,001
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. Fazit

Wir haben ein elektronisches Transaktionssystem vorgeschlagen, das nicht auf Vertrauen basiert. Wir haben mit einer herkömmlichen Münzstruktur begonnen, die mithilfe digitaler Signaturen erstellt wurde und eine starke Eigentumskontrolle bietet, jedoch unvollständig ist, wenn es keine Möglichkeit gibt, doppelte Ausgaben zu verhindern. Um dieses Problem zu lösen, haben wir ein Peer-to-Peer-Netzwerk vorgeschlagen, das Proof-of-Work verwendet, um einen öffentlichen Transaktionsverlauf aufzuzeichnen, dessen Änderung für einen Angreifer schnell rechnerisch unpraktisch wird, wenn ehrliche Knoten den Großteil der CPU-Leistung kontrollieren. Das Netzwerk ist robust in seiner unstrukturierten Einfachheit. Die Knoten arbeiten gleichzeitig und mit wenig Koordination. Sie müssen nicht identifiziert werden, da Nachrichten nicht an einen bestimmten Ort weitergeleitet werden, sondern nur auf der höchstmöglichen Ebene zugestellt werden. Knoten können das Netzwerk nach Belieben verlassen und wieder beitreten, wobei die Proof-of-Work-Kette als Beweis dafür dient, was während ihrer Abwesenheit passiert ist. Sie stimmen mit der Macht ihres Prozessors ab, stimmen gültigen Blöcken zu, indem sie an deren Erweiterung arbeiten, und lehnen ungültige Blöcke ab, indem sie sich weigern, an ihnen zu arbeiten. Über diesen Konsensmechanismus können alle notwendigen Regeln und Anreize umgesetzt werden.

Empfehlungen

[1] W. Dai, „b-money“, http://www.weidai.com/bmoney.txt, 1998.

[2] H. Massias, K.S. Avila und J.-J. Kiskater, „Entwicklung eines sicheren Zeitstempeldienstes mit minimalem Overhead.“

Vertrauensanforderungen“, im 20. Benelux-Informationstheorie-Symposium, Mai 1999.

[3] S. Haber, V.S. Stornetta, „How to Timestamp a Digital Document“, Journal of Cryptology, Bd. 3, Nr.

2, Seiten 99–111, 1991.

[4] D. Bayer, S. Haber, V. S. Stornetta, „Verbesserung der Effizienz und Zuverlässigkeit digitaler Zeitstempel.“

In Sequences II: Communication, Security and Information Science Methods, Seiten 329–334, 1993.

[5] S. Haber, V.S. Stornetta, „Sichere Namen für Bitstrings“, In Proceedings of the 4th ACM Conference.

on Computer and Communications Security, Seiten 28–35, April 1997.

[6] A. Back, „Hashcash – eine Maßnahme zur Bekämpfung von Denial-of-Service“

http://www.hashcash.org/papers/hashcash.pdf, 2002

[7] R. C. Merkle, „Protocols for public key cryptosystems“, In Proc. 1980 Symposium über Sicherheit und

Privacy, IEEE Computer Society, Seiten 122–133, April 1980.

[8] W. Feller, „Einführung in die Wahrscheinlichkeitstheorie und ihre Anwendungen“, 1957.