03 / 736DOC·001

Bitcoin Whitepaper

Bitcoin-Whitepaper

Neun Seiten darüber, wie Menschen digitales Geld ohne Bank als Vermittler versenden können. Ein Wegweiser zum ursprünglichen Entwurf und zu dem, was darin fehlt.

Das Bitcoin Whitepaper ist das Dokument, in dem Satoshi Nakamoto den Entwurf für Bitcoin vorstellte. Er kündigte es am 31. Oktober 2008 unter dem Titel Bitcoin: A Peer-to-Peer Electronic Cash System an. Auf neun Seiten einschließlich Quellen erklärt es, wie digitale Signaturen, ein öffentliches Zahlungsregister und Rechenarbeit ein System ohne zentrale Verwaltung ermöglichen. Es erläutert die Grundidee, ist aber weder eine vollständige Anleitung zur heutigen Software noch eine Sicherheitsgarantie für jeden Bitcoin-Dienst.

Ein Whitepaper stellt ein Problem vor und schlägt eine Lösung vor. Das Bitcoin-Dokument beginnt mit einer alltäglichen Frage: Muss zwischen uns immer eine Bank oder ein anderer Verwalter stehen, wenn ich Geld über das Internet versende? Satoshi schickte seinen Entwurf am 31. Oktober 2008 an eine Kryptografie-Mailingliste und fügte einen Link zum Text hinzu. Er versprach weder einen Bitcoin-Preis noch eine Rendite. Er erklärte, wie Menschen Zahlungen empfangen könnten, ohne einer einzigen Firma die Entscheidung über ihre Zahlungshistorie anzuvertrauen. Dieses Problem verbindet das ganze Dokument. [2] [1]

Stellen Sie sich vor, ein Absender unterschreibt zwei verschiedene Zahlungen, die dasselbe Geld ausgeben. Ein Empfänger sieht die erste, ein anderer die zweite. Beide können eine gültige digitale Signatur prüfen, also den Nachweis der Zahlungsberechtigung. Bezahlt werden können trotzdem nicht beide. Daten lassen sich im Internet leicht kopieren; eine Signatur allein löst das nicht. Kapitel 2 trennt deshalb die Berechtigung zum Ausgeben von der Frage, welche Zahlung zur gemeinsamen Historie gehört. Bitcoin ergänzt Signaturen durch ein öffentliches Register, an dem sich bereits ausgegebene Mittel erkennen lassen. [1]

Die Kapitel 3–5 beschreiben, wie Zahlungen in Blöcken zusammengefasst werden. Jeder neue Block verweist über einen Hash, einen kurzen digitalen Fingerabdruck von Daten, auf seinen Vorgänger. Eine Änderung älterer Einträge würde diesen Fingerabdruck verändern und die Verknüpfung aufbrechen. Proof of Work ergänzt kostspielige Rechenarbeit: Einen zulässigen Block zu erzeugen braucht viele Versuche, das Ergebnis lässt sich leicht prüfen. Bei konkurrierenden Zweigen zählt deshalb die angesammelte Arbeit einer regelkonformen Historie, nicht die Zahl erzeugter Konten oder IP-Adressen. Der Text nennt sie die längste Kette. Auch viel Arbeit macht eine ungültige Transaktion nicht gültig. Die Kette ordnet Ereignisse, liefert aber keine genaue Uhrzeit jeder Zahlung. [1] [3]

Computer und Strom kosten Geld. Kapitel 6 führt daher einen wirtschaftlichen Anreiz ein: Wer einen akzeptierten Block erstellt, kann neu ausgegebene Coins und Gebühren aus dessen Zahlungen erhalten. Die Gebühr ist die Differenz zwischen dem verbrauchten Wert und dem Wert der neu erzeugten Transaktionsausgänge. Sie besteht nicht aus zusätzlichen Coins aus dem Nichts. Der Text erwägt auch eine Zukunft, in der nur Gebühren die Vergütung finanzieren. Wichtig ist aber die Grenze des Entwurfs: Weder das genaue Limit von 21 Millionen noch die Halbierung nach jeweils 210.000 Blöcken stehen im Whitepaper. Diese Regeln sind anhand weiterer Bitcoin-Unterlagen zu prüfen. [1] [3]

Nicht jeder möchte sämtliche Transaktionen herunterladen und prüfen. Kapitel 8 schlägt deshalb SPV vor, die vereinfachte Zahlungsprüfung. Der Client beschafft Blockheader, die wesentlichen Kopfdaten der Blöcke, und einen Merkle-Beweis: eine Verbindung von Hashes, die die Aufnahme einer bestimmten Transaktion in einen Block belegt. Es ist der Unterschied zwischen der Prüfung, ob ein Eintrag in einem Buch steht, und der Prüfung des gesamten Buchinhalts. Der Aufnahmebeweis allein bestätigt weder alle Regeln noch die gesamte Ausgabenhistorie. Das Whitepaper benennt diese Grenze: Ein vereinfachter Client ist für manche Angriffe anfälliger als ein Full Node, der Transaktionen selbst prüft. [1]

Im Bankwesen ist ein großer Teil der Zahlungsaufzeichnungen nicht öffentlich. Bitcoin benötigt dagegen eine gemeinsame Historie und muss Privatsphäre anders schützen. Kapitel 10 erklärt die Trennung von Zahlungen und Identitäten der Schlüsselinhaber und empfiehlt neue Schlüsselpaare für weitere Transaktionen. Zugleich benennt es eine Schwachstelle: Zahlungen lassen sich verknüpfen. Wird eine Person einem Eintrag zugeordnet, können weitere Zahlungen sichtbar werden. Eine neue Adresse ist deshalb keine magische Tarnung. Sie begrenzt manche Verbindungen, beseitigt aber allein weder Informationen in der öffentlichen Historie noch das Wissen der Gegenpartei. [1]

Kapitel 11 fragt, wie wahrscheinlich ein Angreifer die von ehrlichen Teilnehmern erzeugte Kette einholt. Denken Sie an ein Rennen: Eine Seite hat Vorsprung, beide arbeiten weiter. Je kleiner der Rechenleistungsanteil des Angreifers und je größer der Vorsprung, desto geringer ist im beschriebenen Modell seine Aufholchance. Die Rechnung verwendet Annahmen und eine Poisson-Approximation, eine mathematische Vereinfachung zur Schätzung der Ereigniszahl in einem Zeitraum. Sie sagt nicht jeden realen Angriff voraus. Eine einzelne Tabellenzahl ist deshalb kein sicherer Bestätigungswert für jede beliebige Zahlung. [1]

Das Dokument beschreibt den ursprünglichen Entwurf. Netzwerk und Software haben sich weiterentwickelt; SegWit etwa, beschrieben im Vorschlag BIP 141, steht darin nicht. Ein BIP beschreibt einen Verbesserungsvorschlag. Seine Veröffentlichung macht ihn nicht automatisch zur Netzwerkregel. Bei heutigen technischen Fragen müssen wir deshalb zwischen Vorschlag, Programm, tatsächlich angewandten gemeinsamen Regeln und lokalen Entscheidungen eines Knotens zur Weiterleitung unterscheiden. Ein Knoten kann eine Transaktion nicht weiterleiten und sie später dennoch in einem gültigen Block akzeptieren. Das ist kein Widerspruch. [4] [3]

Beginnen Sie mit der Zusammenfassung und der Frage, wie doppelte Ausgaben ohne Verwalter verhindert werden können. Verfolgen Sie dann, was Signaturen, gemeinsame Historie und die Arbeit zur Blockerstellung beitragen. Wenn die Mathematik Sie aufhält, müssen Sie nicht sofort jede Formel verstehen: Klären Sie zuerst, welchen Angriff die Rechnung modelliert und welche Annahmen sie macht. Die Details können später folgen. Die ursprüngliche E-Mail belegt, wann Satoshi den Entwurf vorstellte; das PDF enthält die Argumentation. Ein herausgelöster Satz kann nicht beweisen, dass eine bestimmte Wallet oder ein Dienst sicher sein muss. [2] [1]

Entscheidend sind nicht die Kapitelnamen, sondern das Verständnis, warum kein Bestandteil allein genügt: Die Signatur belegt die Berechtigung, die öffentliche Historie hilft doppelte Ausgaben zu erkennen, und Proof of Work erschwert das Umschreiben der Reihenfolge. Die Einzelteile hatten Vorläufer, auf die Satoshi in den Quellen verweist. Der Beitrag liegt in ihrer Verbindung. So bleibt das Whitepaper ein guter Einstieg in das Denken über Bitcoin, wenn man es als begründeten Entwurf mit bestimmten Annahmen liest. Es ist weder Preisliste noch Anlageanleitung noch vollständige Spezifikation aller heutigen Bitcoin-Regeln und Werkzeuge. [1]

Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Satoshi Nakamoto, Bitcoin, Proof of Work, Transaktion, Timechain / Blockchain. Auf diesen Eintrag verweisen außerdem Bitcoin, Satoshi Nakamoto, Genesis Block, Cypherpunks.

DOC · 001Original Bitcoin whitepaperPrimärquelle DOC · 002Original announcement — 31 October 2008Primärquelle DOC · 003Bitcoin Developer Guide — Block ChainPrimärquelle DOC · 004BIP 141 — Segregated WitnessPrimärquelle
Überarbeitet: Quellenbasiert · Keine Anlageberatung