Satoshis Whitepaper auf Deutsch, Satz für Satz erklärt

Eine rein Peer-to-Peer-Version des elektronischen Bargelds würde es ermöglichen, Online-Zahlungen direkt von einer Partei zu einer anderen zu senden, ohne über ein Finanzinstitut abzuwickeln. Digitale Signaturen bieten einen Teil der Lösung, aber die Hauptvorteile gehen verloren, wenn ein vertrauenswürdiger Dritter noch erforderlich ist, um Double-Spending zu verhindern. Wir schlagen eine Lösung für das Double-Spending-Problem vor, indem wir ein Peer-to-Peer-Netzwerk verwenden. Das Netzwerk stempelt Transaktionen durch das Hashing in eine fortlaufende Kette von hash-basierten Proof-of-Work, und bildet so einen Datensatz, der nicht geändert werden kann, ohne den Proof-of-Work zu wiederholen. Die längste Kette dient nicht nur als Nachweis der beobachteten Ereignisfolge, sondern auch als Nachweis, dass sie von der grössten CPU-Leistung stammt. Solange die Mehrheit der CPU-Leistung von Knoten kontrolliert wird, die nicht kooperieren, um das Netzwerk anzugreifen, werden sie die längste Kette generieren und Angreifer übertreffen. Das Netzwerk selbst benötigt eine minimale Struktur. Nachrichten werden auf einer Best-Effort-Basis übertragen, und Knoten können das Netzwerk nach Belieben verlassen und wieder betreten, wobei sie die längste Proof-of-Work-Kette als Nachweis für das akzeptieren, was geschah, während sie weg waren.

Der Handel im Internet ist fast ausschliesslich auf Finanzinstitute als vertrauenswürdige Drittparteien angewiesen, um elektronische Zahlungen abzuwickeln. Obwohl 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 nicht rückgängig zu machende Transaktionen sind nicht wirklich möglich, da Finanzinstitute nicht vermeiden können, Streitigkeiten zu vermitteln.

Die Kosten der Mediation erhöhen die Transaktionskosten, begrenzen die minimale praktische Transaktionsgrösse und schneiden die Möglichkeit für gelegentliche Transaktionen ab, und es gibt breitere Kosten im Verlust der Fähigkeit, nicht rückgängig zu machende Zahlungen für nicht rückgängig zu machende Dienste zu leisten. Mit der Möglichkeit der Umkehr breitet sich die Notwendigkeit des Vertrauens aus. Händler müssen ihre Kunden misstrauisch sein, indem sie sie nach mehr Informationen fragen, als sie sonst benötigen würden.

Was benötigt wird, ist ein elektronisches Zahlungssystem, das auf kryptographischem Beweis statt auf Vertrauen basiert, das es zwei willigen Parteien ermöglicht, direkt miteinander zu handeln, ohne dass ein vertrauenswürdiger Dritter notwendig ist. Transaktionen, die rechnerisch unpraktisch wären umzukehren, würden Verkäufer vor Betrug schützen, und routinemässige Treuhandmechanismen könnten leicht implementiert werden, um Käufer zu schützen.

In diesem Paper schlagen wir eine Lösung für das Double-Spending-Problem vor, indem wir einen Peer-to-Peer-Distributed-Timestamp-Server verwenden, um eine rechnerische Aufzeichnung der Chronologie der Transaktionen zu generieren. Das System ist sicher, solange ehrliche Knoten gemeinsam mehr CPU-Leistung kontrollieren als jede kooperierende Gruppe von Angreifern.

Wir definieren eine elektronische Münze als eine Kette digitaler Signaturen. Jeder Eigentümer überträgt die Münze an den nächsten, indem er einen Hash der vorherigen Transaktion und den öffentlichen Schlüssel des nächsten Eigentümers digital signiert und diese am Ende der Münze hinzufügt. Ein Zahlungsempfänger kann die Signaturen überprüfen, um die Kette des Eigentums zu überprüfen.

Das Problem ist natürlich, dass der Zahlungsempfänger nicht überprüfen kann, ob einer der Eigentümer die Münze nicht doppelt ausgegeben hat. Eine übliche Lösung besteht darin, eine vertrauenswürdige zentrale Behörde oder Münzanstalt einzuführen, die jede Transaktion auf Double-Spending prüft. Nach jeder Transaktion muss die Münze zur Münzanstalt zurückgegeben werden, um eine neue auszugeben, und nur die direkt von der Münzanstalt ausgegebenen Münzen sind nicht doppelt ausgegeben. Das Problem bei dieser Lösung ist, dass das Schicksal des gesamten Geldsystems von dem Unternehmen abhängt, das die Münzanstalt betreibt, wobei jede Transaktion durch sie gehen muss, ähnlich wie eine Bank.

Wir brauchen eine Möglichkeit für den Zahlungsempfänger zu wissen, dass die vorherigen Eigentümer keine früheren Transaktionen unterschrieben haben. Für unsere Zwecke ist die früheste Transaktion diejenige, die zählt, also kümmern wir uns nicht um spätere Versuche des Double-Spending. Die einzige Möglichkeit, das Fehlen einer Transaktion zu bestätigen, besteht darin, sich aller Transaktionen bewusst zu sein.

Die Lösung, die wir vorschlagen, beginnt mit einem Timestamp-Server. Ein Timestamp-Server funktioniert, indem er einen Hash eines Blocks von Elementen, die mit einem Zeitstempel versehen werden sollen, entgegennimmt und den Hash weit verbreitet, beispielsweise in einer Zeitung oder in einem Usenet-Post. Der Timestamp beweist, dass die Daten zu diesem Zeitpunkt offensichtlich existiert haben mussten, um in den Hash aufgenommen zu werden. Jeder Timestamp enthält den vorherigen Timestamp in seinem Hash, und bildet so eine Kette, wobei jeder zusätzliche Timestamp die vor ihm kommt, verstärkt.

Um einen verteilten Peer-to-Peer-Timestamp-Server zu implementieren, müssen wir ein Proof-of-Work-System verwenden, ähnlich Adam Backs Hashcash, anstatt Zeitung- oder Usenet-Posts. Das Proof-of-Work beinhaltet das Scannen nach einem Wert, der beim Hashing mit SHA-256 mit einer Anzahl von Null-Bits beginnt. Die durchschnittliche erforderliche Arbeit ist exponential zu der Anzahl der erforderlichen Null-Bits, und kann durch Ausführen eines einzelnen Hashs überprüft werden.

Für unser Timestamp-Netzwerk implementieren wir das Proof-of-Work durch das Inkrementieren einer Nonce im Block, bis ein Wert gefunden wird, der dem Block den erforderlichen Null-Hash-Bits gibt. Sobald die CPU-Anstrengung ausgegeben wurde, um es den Proof-of-Work-Anforderungen zu entsprechen, kann der Block nicht ohne die Arbeit zu wiederholen geändert werden. Da spätere Blöcke danach gekettet sind, würde die Arbeit, den Block zu ändern, das Neuberechnen aller nachfolgenden Blöcke beinhalten.

Proof-of-Work löst auch das Problem der Bestimmung der Repräsentation bei der Mehrheitsentscheidung. Wenn die Mehrheit auf Basis einer-IP-Adresse-eine-Stimme wäre, könnte sie von jedem, der viele IPs zuweisen kann, gebrochen werden. Proof-of-Work ist im Wesentlichen eine-CPU-eine-Stimme. Die Mehrheitsentscheidung wird durch die längste Kette repräsentiert, in die die grösste Proof-of-Work-Anstrengung investiert wurde.

Die Schritte zum Betrieb des Netzwerks sind wie folgt:

1. Neue Transaktionen werden an alle Nodes übertragen.
2. Jeder Node sammelt neue Transaktionen in einem Block.
3. Jeder Node arbeitet daran, einen schwierigen Proof-of-Work für seinen Block zu finden.
4. Wenn ein Node den Proof-of-Work findet, sendet er den Block an alle Nodes.
5. Nodes akzeptieren den Block nur, wenn alle Transaktionen darin gültig sind und nicht bereits ausgegeben wurden.
6. Nodes drücken ihre Akzeptanz des Blocks aus, indem sie an der Erstellung des nächsten Blocks in der Kette arbeiten und dabei den Hash des akzeptierten Blocks als den vorherigen Hash verwenden.

Nodes betrachten immer die längste Kette als die richtige und werden weiterhin daran arbeiten, sie zu verlängern. Wenn zwei Nodes gleichzeitig verschiedene Versionen des nächsten Blocks übertragen, empfangen einige Nodes möglicherweise den einen oder den anderen zuerst. In diesem Fall arbeiten sie an dem ersten, den sie erhalten haben, behalten aber den anderen Zweig für den Fall, dass er länger wird. Das Unentschieden wird gebrochen, wenn der nächste Proof-of-Work gefunden wird und ein Zweig länger wird; die Nodes, die auf dem anderen Zweig gearbeitet haben, wechseln dann zu dem längeren.

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 einen Anreiz für Nodes hinzu, das Netzwerk zu unterstützen, und bietet eine Möglichkeit, Münzen anfänglich in Umlauf zu bringen, da es keine zentrale Behörde gibt, die sie ausgibt. Die stetige Hinzufügung einer konstanten Menge neuer Münzen ist analog zu Goldmineninhabern, die Ressourcen aufwenden, um Gold in Umlauf zu bringen. In unserem Fall ist es die CPU-Zeit und Strom, der aufgewendet wird.

Der Anreiz kann auch durch Transaktionsgebühren finanziert werden. Wenn der Ausgabewert einer Transaktion kleiner ist als ihr Eingabewert, ist die Differenz eine Transaktionsgebühr, die dem Block-Wert der Transaktion hinzugefügt wird. Sobald eine vorher festgelegte Anzahl von Münzen in Umlauf gebracht wurde, kann der Anreiz vollständig zu Transaktionsgebühren übergehen und völlig inflationsfrei sein.

Der Anreiz kann helfen, Nodes zu ermutigen, ehrlich zu bleiben. Wenn ein gieriger Angreifer in der Lage ist, mehr CPU-Leistung zusammenzufügen als alle ehrlichen Nodes, müsste er wählen, ob er es verwenden will, um die Leute zu betrügen, indem er seine Zahlungen zurückstiehlt, oder ob er es verwenden will, um neue Münzen zu generieren. Er sollte es profitabler finden, nach den Regeln zu spielen.

Sobald die neueste Transaktion in einer Münze unter genügend Blöcken begraben ist, können die vorherigen Transaktionen verworfen werden, um Speicherplatz zu sparen. Um dies zu ermöglichen, ohne den Block-Hash zu brechen, werden Transaktionen in einem Merkle-Baum gehasht, wobei nur die Wurzel im Block-Hash enthalten ist. Alte Blöcke können dann komprimiert werden, indem Äste des Baums entfernt werden. Die inneren Hashes müssen nicht gespeichert werden.

Ein Block-Header ohne Transaktionen wäre ca. 80 Bytes. Wenn wir annehmen, dass alle 10 Minuten Blöcke generiert werden, entspricht das 80 Bytes × 6 × 24 × 365 = 4,2 MB pro Jahr. Mit Computersystemen, die typischerweise ab 2008 mit 2 GB RAM verkauft werden, und Moores Gesetz, das ein Wachstum von 1,2 GB pro Jahr voraussagt, sollte die Speicherung kein Problem sein, selbst wenn die Block-Header im Speicher gehalten werden.

Es ist möglich, Zahlungen zu verifizieren, ohne einen vollständigen Netzwerk-Node zu betreiben. Ein Benutzer muss nur eine Kopie der Block-Header der längsten Proof-of-Work-Kette aufbewahren, die er durch Abfragen von Netzwerk-Nodes 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, in dem er mit einem Zeitstempel versehen ist.

Er kann die Transaktion nicht selbst überprüfen, aber indem er sie mit einem Platz in der Kette verknüpft, kann er sehen, dass ein Netzwerk-Node sie akzeptiert hat, und Blöcke, die danach hinzugefügt wurden, bestätigen weiter, dass das Netzwerk sie akzeptiert hat. Solange ehrliche Nodes das Netzwerk kontrollieren, ist die Verifizierung zuverlässig.

Obwohl es möglich wäre, Münzen einzeln zu behandeln, wäre es unhandlich, für jeden Cent in einem Transfer eine separate Transaktion zu machen. Um zu ermöglichen, dass Wert aufgeteilt und kombiniert wird, enthalten Transaktionen mehrere Inputs und Outputs. In der Regel gibt es entweder einen einzigen Input aus einer grösseren vorherigen Transaktion oder mehrere Inputs, die kleinere Mengen kombinieren, und höchstens zwei Outputs: einen für die Zahlung und einen, der das Wechselgeld zurück an den Sender zurückgibt.

Das traditionelle Bankmodell erreicht ein Privatsphäreniveau, 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, schliesst diese Methode aus, aber die Privatsphäre kann immer noch aufrechterhalten werden, indem der Informationsfluss an anderer Stelle unterbrochen wird: indem öffentliche Schlüssel anonym gehalten werden. Das Publikum kann sehen, dass jemand Geld an jemand anderen schickt, aber ohne Informationen, die die Transaktion mit jemandem in Verbindung bringen.

Als zusätzliche Firewall sollte für jede Transaktion ein neues Schlüsselpaar verwendet werden, um zu verhindern, dass sie mit einem gemeinsamen Eigentümer in Verbindung gebracht werden. Einige Verknüpfungen sind bei Multi-Input-Transaktionen immer noch unvermeidlich, die notwendigerweise enthüllen, dass ihre Inputs dem gleichen Eigentümer gehörten.

Wir betrachten das Szenario eines Angreifers, der versucht, eine alternative Kette schneller als die ehrliche Kette zu generieren. Selbst wenn dies erreicht wird, öffnet es das System nicht für willkürliche Änderungen, wie das Schaffen von Wert aus der Luft oder das Nehmen von Geld, das dem Angreifer nie gehörte. Nodes werden keine ungültige Transaktion als Zahlung akzeptieren, und ehrliche Nodes werden niemals einen Block akzeptieren, der sie enthält.

Ein Angreifer kann nur versuchen, eine seiner eigenen Transaktionen zu ändern, um Geld zurückzubekommen, das er kürzlich ausgegeben hat. Das Rennen zwischen der ehrlichen Kette und einer Angreifer-Kette kann als Binomial Random Walk charakterisiert werden. Das Erfolgsereignis ist, dass die ehrliche Kette um einen Block erweitert wird, die Lücke zu +1 erhöht, und das Misserfolgsereignis ist, dass die Kette des Angreifers um einen Block erweitert wird, die Lücke um -1 zu verringern.

Mit p = Wahrscheinlichkeit, dass ein ehrlicher Node den nächsten Block findet und q = Wahrscheinlichkeit, dass der Angreifer den nächsten Block findet, und q < p, sinkt die Wahrscheinlichkeit eines erfolgreichen Angriffs exponentiell mit zunehmender Anzahl von Blöcken.

Wir haben ein System für elektronische Transaktionen ohne Vertrauen vorgeschlagen. Wir begannen mit dem üblichen Rahmen der Münzen aus digitalen Signaturen, der eine starke Kontrolle des Eigentums bietet, aber ohne eine Möglichkeit, Double-Spending zu verhindern, unvollständig ist. Um dies zu lösen, schlugen wir ein Peer-to-Peer-Netzwerk mit Proof-of-Work vor, um eine öffentliche Geschichte der Transaktionen aufzuzeichnen, die für einen Angreifer schnell rechnerisch unpraktisch wird zu ändern, wenn ehrliche Nodes die Mehrheit der CPU-Leistung kontrollieren.

Das Netzwerk ist in seiner unstrukturierten Einfachheit robust. Die Nodes arbeiten alle gleichzeitig mit wenig Koordination. Sie müssen nicht identifiziert werden, da Nachrichten nicht zu einem bestimmten Ort weitergeleitet werden müssen und nur auf einer Best-Effort-Basis zugestellt werden müssen. Nodes können das Netzwerk nach Belieben verlassen und wieder betreten, indem sie die Proof-of-Work-Kette als Nachweis für das akzeptieren, was während ihrer Abwesenheit geschah. Sie stimmen mit ihrer CPU-Leistung ab und drücken ihre Akzeptanz gültiger Blöcke aus, indem sie daran arbeiten, sie zu verlängern, und lehnen ungültige Blöcke ab, indem sie sich weigern, daran zu arbeiten. Alle erforderlichen Regeln und Anreize können mit diesem Konsensmechanismus durchgesetzt werden.