Zum Inhalt springen
Website im Aufbau: Aktuell findet noch keine Geschäftstätigkeit statt – alle Angebote und Inhalte sind unverbindlich und dienen der Vorbereitung.

Das Bitcoin-Whitepaper – verständlich erklärt

ca. 16 Min. Lesezeit

Hinweis: Das Whitepaper wurde von Satoshi Nakamoto unter der freien MIT-Lizenz mit dem ursprünglichen Bitcoin-Projekt veröffentlicht. Statt den englischen Originaltext abzudrucken, gebe ich den Inhalt jedes der zwölf Abschnitte in eigener, deutscher Formulierung wieder (jeweils im Kasten „Im Original steht sinngemäß“) und erkläre ihn dann genau. Das Original findest du unter bitcoin.org/bitcoin.pdf.

§ 1 Einleitung

Im Original steht sinngemäß
Handel im Internet hängt fast vollständig von Finanzinstituten ab, die als vertrauenswürdige Dritte Zahlungen abwickeln. Dieses Modell funktioniert, hat aber Schwächen: Zahlungen lassen sich nicht endgültig machen, Streitfälle erzwingen Vermittlung, Transaktionskosten steigen. Gebraucht wird stattdessen ein elektronisches Zahlungssystem, das auf kryptografischem Beweis statt auf Vertrauen beruht und es zwei Parteien erlaubt, direkt miteinander zu handeln.

Stell dir vor, du willst jemandem online 50 Euro schicken. Heute läuft das über eine Bank oder einen Dienst wie PayPal. Dieser Mittelsmann garantiert, dass das Geld wirklich ankommt — und genau dafür musst du ihm vertrauen.

Nakamoto nennt zwei Probleme dieses Modells. Erstens ist keine Zahlung wirklich endgültig: Der Mittelsmann kann sie rückgängig machen, also muss er Streit schlichten, was Kosten und Misstrauen erzeugt. Zweitens, und das ist der Kern, hängt alles am Vertrauen in eine einzige Stelle.

Die Frage des ganzen Papiers lautet deshalb: Kann man digitales Geld direkt von Person zu Person schicken — so sicher, dass man keiner zentralen Stelle mehr vertrauen muss, sondern nur noch der Mathematik? Für einen Fachkundigen formuliert: ein Zahlungssystem, dessen Korrektheit aus kryptografischem Beweis folgt, nicht aus institutionellem Vertrauen.

§ 2 Transaktionen

Im Original steht sinngemäß
Eine elektronische Münze wird als Kette digitaler Signaturen definiert. Jeder Eigentümer überträgt die Münze weiter, indem er den Hash der vorherigen Transaktion zusammen mit dem öffentlichen Schlüssel des nächsten Eigentümers signiert und beides an die Münze anhängt. Ein Empfänger kann die Signaturen prüfen und so die Eigentümerkette verifizieren. Das Problem: Der Empfänger kann nicht erkennen, ob ein früherer Eigentümer dieselbe Münze nicht schon ein zweites Mal ausgegeben hat (das „Double-Spending“).

Hier kommt die wichtigste Idee des Papiers: Was ist eine digitale Münze überhaupt? Antwort: Eine Münze ist keine Datei, sondern eine Kette von Unterschriften.

Dafür braucht man zwei kryptografische Werkzeuge, die man kurz so verstehen kann:

Ein öffentlicher Schlüssel ist wie eine Kontonummer, die man jedem zeigen darf — er ist die „Adresse“ eines Eigentümers. Der dazugehörige private Schlüssel ist das Geheimnis, das nur der Eigentümer kennt; damit kann er unterschreiben. Eine digitale Signatur beweist mathematisch zweierlei: dass der Unterzeichner den privaten Schlüssel besaß, und dass an der unterschriebenen Nachricht nachträglich nichts verändert wurde.

Eine Übertragung läuft nun so ab: Der aktuelle Eigentümer nimmt die vorherige Transaktion (genauer: ihren Hash, also einen kurzen eindeutigen Fingerabdruck) und den öffentlichen Schlüssel des Empfängers, und unterschreibt beides mit seinem privaten Schlüssel. Diese Unterschrift hängt er an. So entsteht ein Glied nach dem anderen — eine lückenlose Kette, in der jeder Besitzwechsel beweisbar dokumentiert ist.

Transaktion 1 → 2 Public Key Eigent. 2 Hash der Vor-Tx Signatur Eigent. 1 Transaktion 2 → 3 Public Key Eigent. 3 Hash der Vor-Tx Signatur Eigent. 2 Transaktion 3 → 4 Public Key Eigent. 4 Hash der Vor-Tx Signatur Eigent. 3 verkettet per Hash signiert mit privatem Schlüssel
So liest man das: Jede Transaktion enthält den öffentlichen Schlüssel des neuen Eigentümers und den Hash der vorherigen Transaktion (grün), und wird vom bisherigen Eigentümer signiert (orange). Wer die Münze annimmt, kann die gesamte Kette zurückverfolgen und jede Unterschrift prüfen.

Doch eine Lücke bleibt — und sie ist das eigentliche Problem digitalen Geldes. Eine Unterschriftskette beweist, dass eine Münze gültig weitergegeben wurde. Sie beweist nicht, dass der Zahlende dieselbe Münze nicht heimlich schon einer zweiten Person gegeben hat. Digitale Dinge lassen sich beliebig kopieren; nichts hindert einen Betrüger daran, denselben „Euro“ zweimal auszugeben. Das nennt man Double-Spending.

Eine Bank löst das, indem sie als einzige zentrale Stelle jede Münze kennt und Doppelausgaben ablehnt. Aber genau die zentrale Stelle wollte Nakamoto ja loswerden. Der Rest des Papiers ist im Grunde die Antwort auf eine einzige Frage: Wie verhindert man Double-Spending ohne Bank?

§ 3 Der Timestamp-Server

Im Original steht sinngemäß
Die Lösung beginnt mit einem Zeitstempel-Server. Er nimmt einen Hash über einen Block von Daten und veröffentlicht ihn breit. Der Zeitstempel beweist, dass die Daten zu diesem Zeitpunkt existiert haben müssen. Jeder Zeitstempel enthält den vorherigen Zeitstempel in seinem Hash, sodass eine Kette entsteht — und jeder weitere Zeitstempel verstärkt die vorhergehenden.

Um Double-Spending zu verhindern, müssen alle Teilnehmer sich auf eine einzige, gemeinsame Reihenfolge aller Transaktionen einigen. Wenn alle wissen, dass Münze X zuerst an Anna ging, ist ein späterer Versuch, dieselbe Münze an Bob zu schicken, offensichtlich ungültig.

Der erste Baustein dafür ist ein Zeitstempel. Man fasst viele Transaktionen zu einem „Block“ zusammen, bildet darüber einen Hash (den Fingerabdruck) und veröffentlicht ihn. Das beweist: Diese Daten existierten zu diesem Zeitpunkt genau so. Entscheidend ist der Trick, dass jeder neue Zeitstempel den vorherigen mit einschließt. Dadurch hängen die Blöcke aneinander wie Glieder einer Kette: Wer ein altes Glied verändern wollte, müsste auch alle nachfolgenden ändern. Das ist die Grundidee der späteren „Blockchain“.

§ 4 Proof-of-Work

Im Original steht sinngemäß
Um die Zeitstempelkette in einem Peer-to-Peer-Netz ohne Vertrauensstelle umzusetzen, wird ein Proof-of-Work verwendet (ähnlich Adam Backs Hashcash). Man sucht einen Wert, sodass der Hash des Blocks mit einer bestimmten Zahl von Null-Bits beginnt. Der Aufwand wächst exponentiell mit der Zahl der geforderten Nullen, die Prüfung dagegen ist ein einziger Hash-Vorgang. Hat ein Block erst einmal einen gültigen Proof-of-Work, kann man ihn nicht ändern, ohne die ganze Arbeit erneut zu leisten. Es gilt: eine CPU, eine Stimme — die längste Kette repräsentiert die meiste investierte Rechenarbeit.

Jetzt fehlt nur noch eines: Wer darf eigentlich den nächsten Block veröffentlichen? In einem offenen Netz ohne Chef könnte jeder beliebig viele falsche Blöcke erzeugen. Nakamotos Antwort ist der Proof-of-Work — ein „Arbeitsnachweis“, der das Erstellen eines Blocks bewusst teuer macht.

Die Aufgabe: Man hängt an den Block eine Zahl an, die Nonce heißt, und probiert sie so lange durch, bis der Hash des gesamten Blocks mit einer vorgegebenen Anzahl von Nullen beginnt. Ein Hash ist nicht vorhersagbar — man kann nur raten und prüfen, millionen- und milliardenfach. Das kostet echte Rechenzeit und echten Strom. Hat man die passende Nonce aber gefunden, kann jeder andere die Lösung mit einem einzigen Hash sofort nachprüfen.

Daraus folgen zwei mächtige Eigenschaften. Erstens ist die Kette praktisch unveränderbar: Wer einen alten Block fälschen will, muss dessen Proof-of-Work und den aller folgenden Blöcke neu berechnen — und dabei mit dem ständig wachsenden Rest des Netzes Schritt halten. Zweitens ersetzt Rechenleistung die Abstimmung: Nicht „eine Person, eine Stimme“ (das ließe sich mit falschen Identitäten austricksen), sondern eine CPU, eine Stimme. Die ehrliche Mehrheit gewinnt, solange sie mehr Rechenleistung kontrolliert als ein Angreifer.

Block Hash des Vorgängers …a3f9 → Nonce: 2 459 113 Tx · Tx · Tx Tx · Tx · Tx Block Hash des Vorgängers …7c1d → Nonce: 884 027 Tx · Tx · Tx Tx · Tx · Tx Block Hash des Vorgängers …e08b → Nonce: 1 207 660 Tx · Tx · Tx Tx · Tx · Tx Nonce wird gesucht, bis der Block-Hash mit genug Nullen beginnt = Proof-of-Work
So liest man das: Jeder Block trägt den Hash seines Vorgängers (grün) — das verkettet die Blöcke unauflösbar. Die Nonce (orange) ist die mühsam gesuchte Zahl, die den gültigen Arbeitsnachweis liefert. Einen alten Block zu fälschen hieße, diese Suche für ihn und alle folgenden Blöcke zu wiederholen.

§ 5 Das Netzwerk

Im Original steht sinngemäß
Der Netzwerkbetrieb läuft in Schritten: Neue Transaktionen werden an alle gesendet; jeder Knoten sammelt sie in einem Block; jeder Knoten sucht den Proof-of-Work für seinen Block; wer ihn findet, sendet den Block an alle; die anderen akzeptieren ihn nur, wenn alle Transaktionen gültig und nicht doppelt ausgegeben sind; ihre Zustimmung drücken sie aus, indem sie den nächsten Block auf diesen aufbauen. Die längste Kette gilt immer als die richtige. Treffen zwei Versionen ein, arbeitet man an der ersten weiter, hebt die andere aber auf — sie gewinnt, falls ihre Verzweigung länger wird.

Jetzt fügt sich alles zusammen. So läuft das Netzwerk Schritt für Schritt:

1. Wer eine Zahlung tätigt, sendet die Transaktion an alle Teilnehmer (die „Knoten“). 2. Jeder Knoten sammelt eingehende Transaktionen in einem Block. 3. Jeder Knoten versucht, für seinen Block den Proof-of-Work zu finden. 4. Wer ihn zuerst findet, schickt den fertigen Block ins Netz. 5. Die anderen prüfen den Block — sind alle Transaktionen gültig und keine doppelt ausgegeben? 6. Akzeptieren sie ihn, drücken sie das aus, indem sie ihren nächsten Block auf diesen aufsetzen. So wächst die Kette.

Die zentrale Spielregel lautet: Die längste Kette gilt als die wahre. „Am längsten“ meint dabei: die Kette mit der meisten hineingesteckten Rechenarbeit. Weil ehrliche Knoten stets an der längsten Kette weiterbauen, wächst sie am schnellsten — und überholt jede konkurrierende Version von selbst.

Was, wenn zufällig zwei Knoten gleichzeitig einen gültigen Block finden? Dann hat das Netz kurz zwei Versionen. Jeder arbeitet an der zuerst gehörten weiter, behält die andere aber im Hinterkopf. Sobald der nächste Block gefunden wird, ist ein Zweig länger — und alle wechseln auf ihn. Die Uneinigkeit löst sich also von selbst auf, ohne dass irgendeine Instanz entscheiden müsste.

§ 6 Der Anreiz

Im Original steht sinngemäß
Die erste Transaktion eines Blocks erzeugt eine neue Münze, die dem Erschaffer des Blocks gehört. Das gibt Knoten einen Anreiz, das Netz zu unterstützen, und verteilt zugleich neue Münzen, ohne dass eine zentrale Stelle sie ausgeben muss. Zusätzlich können Transaktionsgebühren anfallen. Der Anreiz hält Teilnehmer ehrlich: Wer genug Rechenleistung für einen Angriff hätte, fährt besser damit, regelkonform zu schürfen und belohnt zu werden, als das System zu untergraben, von dem sein eigener Reichtum abhängt.

Warum sollte überhaupt jemand seinen Strom für diese mühsame Rechenarbeit verbrennen? Weil es sich lohnt. Der allererste Eintrag in jedem Block ist eine Sonder-Transaktion, die neue Münzen erschafft und sie dem zuschreibt, der den Block gefunden hat. Das ist die Belohnung fürs Mitmachen — und zugleich der elegante Weg, wie überhaupt neue Bitcoins in Umlauf kommen: nicht durch eine Zentralbank, sondern als Nebenprodukt der Sicherung des Netzes. Später, wenn die Münzausgabe ausläuft, treten Transaktionsgebühren an ihre Stelle.

Der tiefere Punkt ist spieltheoretisch: Der Anreiz hält die Teilnehmer ehrlich. Wer so viel Rechenleistung besäße, dass er das Netz angreifen könnte, stünde vor einer Wahl — das System betrügen oder ehrlich schürfen und kassieren. Da sein eigener Reichtum am Funktionieren des Systems hängt, ist Ehrlichkeit für ihn fast immer die lukrativere Strategie. Das System verteidigt sich also nicht durch Verbote, sondern dadurch, dass es gutes Verhalten belohnt.

§ 7 Speicherplatz zurückgewinnen

Im Original steht sinngemäß
Sobald eine Münze unter genügend Blöcken vergraben ist, lassen sich die ausgegebenen Transaktionen davor verwerfen, um Speicher zu sparen. Damit der Block-Hash dabei intakt bleibt, werden die Transaktionen in einem Merkle-Baum organisiert; nur dessen Wurzel steht im Block-Hash. Alte Zweige lassen sich abschneiden — der innere Hash muss nicht aufbewahrt werden. Ein Block-Header ohne Transaktionen ist nur etwa 80 Byte groß.

Mit der Zeit würde die Kette riesig. Nakamoto zeigt, wie man Speicher spart, ohne die Sicherheit zu verlieren. Das Werkzeug heißt Merkle-Baum. Vereinfacht: Statt alle Transaktionen einzeln in den Block-Fingerabdruck einzurechnen, fasst man je zwei Hashes zusammen, dann wieder je zwei — wie ein Turnierbaum — bis ganz oben ein einziger Hash übrig bleibt, die Merkle-Wurzel. Nur diese Wurzel steckt im Block.

Der Vorteil: Längst abgewickelte, „verbrauchte“ Transaktionen kann man wegwerfen und nur die Wurzel behalten — der Block bleibt trotzdem nachweislich unverändert. So schrumpft ein Block auf einen winzigen Header von rund 80 Byte. Selbst über Jahrzehnte bleibt die Datenmenge damit für normale Computer handhabbar.

§ 8 Vereinfachte Zahlungsprüfung

Im Original steht sinngemäß
Man kann Zahlungen prüfen, ohne einen vollständigen Knoten zu betreiben. Es genügt, die Block-Header der längsten Kette zu besitzen und sich über einen Merkle-Zweig zu bestätigen, dass die fragliche Transaktion in einem Block enthalten ist. Diese leichte Prüfung ist verlässlich, solange ehrliche Knoten das Netz kontrollieren; ein Angreifer mit Übermacht könnte sie täuschen. Für mehr Sicherheit kann der Client Warnungen vollständiger Knoten beachten und im Zweifel den ganzen Block anfordern.

Nicht jeder muss die komplette Kette speichern. Ein Handy zum Beispiel kann eine Zahlung schon dann als echt einstufen, wenn es nur die kleinen Block-Header kennt und sich über einen Merkle-Zweig zeigen lässt, dass die Transaktion tatsächlich in einem dieser Blöcke steckt — und dass auf diesem Block bereits weitere Blöcke aufbauen.

Das ist die Grundlage heutiger Wallet-Apps auf dem Smartphone. Diese „vereinfachte Zahlungsprüfung“ (im Englischen SPV) ist verlässlich, solange ehrliche Knoten die Mehrheit der Rechenleistung halten. Wer maximale Sicherheit will, betreibt einen vollen Knoten oder fragt im Zweifel den ganzen Block ab.

§ 9 Werte zusammenführen und aufteilen

Im Original steht sinngemäß
Eine Transaktion kann mehrere Eingänge und Ausgänge haben — Eingänge, um Beträge zu bündeln, und meist höchstens zwei Ausgänge: einen für die Zahlung und einen, der das Wechselgeld zurück an den Sender schickt. Es ist nicht nötig, jede einzelne Münze gesondert zu behandeln.

In der Praxis zahlt man selten mit genau passenden Beträgen. Deshalb darf eine Transaktion mehrere Eingänge haben (man bündelt mehrere kleinere Beträge) und mehrere Ausgänge (typischerweise zwei: die eigentliche Zahlung und das Wechselgeld zurück an einen selbst).

Die Analogie zur Geldbörse passt gut: Du legst mehrere Scheine auf den Tisch (Eingänge), bezahlst den Betrag und bekommst Rückgeld (Ausgänge). Man muss also nicht jede Münze einzeln verwalten — das System rechnet flexibel mit Summen.

§ 10 Privatsphäre

Im Original steht sinngemäß
Banken wahren Privatsphäre, indem sie den Zugang zu Informationen beschränken. Hier sind alle Transaktionen öffentlich — die Privatsphäre wird stattdessen dadurch gewahrt, dass die öffentlichen Schlüssel anonym bleiben. Man sieht zwar, dass jemand einen Betrag an jemanden schickt, aber nicht, wer dahintersteht. Zusätzlich sollte man für jede Transaktion ein neues Schlüsselpaar verwenden, damit sich Zahlungen nicht zu einer Person zusammenführen lassen.

Hier dreht Nakamoto das übliche Modell um. Banken halten Daten geheim, um Privatsphäre zu schützen. Bei Bitcoin ist dagegen jede Transaktion öffentlich einsehbar. Wie kann das privat sein?

Der Trick: Die öffentlichen Schlüssel sind pseudonym. Jeder sieht, dass „Adresse A 5 Münzen an Adresse B schickt“, aber niemand weiß ohne Zusatzwissen, welche echten Menschen hinter A und B stehen. Es ist ungefähr wie an der Börse, wo Kurse und Handelsvolumen sichtbar sind, die einzelnen Käufer aber nicht. Empfehlung des Papiers: Für jede Zahlung ein neues Schlüsselpaar verwenden, damit sich nicht alle Beträge einer Person zuordnen lassen.

§ 11 Berechnungen

Im Original steht sinngemäß
Betrachtet wird ein Angreifer, der eine eigene, gefälschte Kette schneller wachsen lassen will als die ehrliche. Selbst wenn ihm das gelänge, könnte er nicht beliebig Geld erschaffen — er könnte nur versuchen, eine eigene, bereits getätigte Zahlung rückgängig zu machen. Das Aufholen gleicht einem Glücksspielproblem (Random Walk / Gambler’s Ruin): Hat die ehrliche Kette einen Vorsprung, sinkt die Wahrscheinlichkeit, dass der Angreifer ihn noch einholt, exponentiell mit jedem weiteren Block. Wartet ein Empfänger einige Bestätigungen ab, wird ein erfolgreicher Angriff verschwindend unwahrscheinlich.

Im rechnerischen Teil fragt Nakamoto: Wie sicher ist das Ganze wirklich? Das wichtigste Ergebnis lässt sich ohne Formeln verstehen.

Ein Angreifer kann kein Geld aus dem Nichts erzeugen — die ehrlichen Knoten würden ungültige Blöcke einfach ablehnen. Das Schlimmste, was er versuchen kann, ist eine bereits getätigte eigene Zahlung rückgängig zu machen, indem er heimlich eine konkurrierende, längere Kette baut. Dafür muss er die ehrliche Kette überholen.

Das ist wie ein Wettrennen, bei dem die ehrliche Mehrheit pro Runde im Schnitt vorlegt. Liegt der Angreifer auch nur ein paar Blöcke zurück, ist seine Chance, je wieder gleichzuziehen, gering — und sie fällt exponentiell, je mehr Blöcke (sogenannte „Bestätigungen“) obendrauf kommen. Praktisch heißt das: Wer einen größeren Betrag empfängt, wartet einige Bestätigungen ab, dann wird ein Rückgängigmachen astronomisch unwahrscheinlich. Genau deshalb empfehlen Börsen heute, vor der endgültigen Gutschrift mehrere Bestätigungen abzuwarten.

§ 12 Schlussfolgerung

Im Original steht sinngemäß
Vorgeschlagen wurde ein System für elektronische Transaktionen, das nicht auf Vertrauen beruht. Aus digitalen Signaturen entsteht eine starke Kontrolle über Eigentum; das Double-Spending-Problem löst ein Peer-to-Peer-Netz mittels Proof-of-Work, das eine praktisch unumkehrbare öffentliche Historie erzeugt, solange ehrliche Knoten die meiste Rechenleistung kontrollieren. Das Netz braucht keine Struktur: Nachrichten werden grob verteilt, Knoten kommen und gehen nach Belieben und akzeptieren die längste Proof-of-Work-Kette als Beweis dessen, was in ihrer Abwesenheit geschah.

Am Ende fügt Nakamoto die Teile zu einem Bild zusammen. Digitale Signaturen regeln das Eigentum an den Münzen. Das Double-Spending-Problem löst ein Peer-to-Peer-Netz, das mit Proof-of-Work eine öffentliche Transaktionsgeschichte schreibt, die sich nicht mehr umschreiben lässt — solange die ehrlichen Teilnehmer die meiste Rechenleistung stellen.

Das Schöne daran ist die Schlichtheit des Netzes: Es braucht keine feste Struktur, keine Anmeldung, keine Verwaltung. Knoten dürfen kommen und gehen, wie sie wollen, und finden beim Wiedereinstieg einfach Anschluss an die längste Kette — sie ist der Beweis dessen, was in ihrer Abwesenheit geschah. Aus lauter einfachen Regeln entsteht so ein Geldsystem ohne Mittelsmann. Das ist die ganze Idee.

₿ Bitcoin Netzwerk
Hashrate
Difficulty
TX-Gebühren
Daten: mempool.space · Aktualisierung jede Minute