Das Bitcoin Whitepaper beschreibt ein elektronisches Zahlungssystem ohne Banken: digitale Signaturen, Proof-of-Work und Konsens über Rechenleistung.

Peer-to-Peer statt dritter Partei

Am 31. Oktober 2008 veröffentlichte eine Person oder Gruppe unter dem Pseudonym Satoshi Nakamoto ein neunseitiges Dokument mit dem Titel „Bitcoin: A Peer-to-Peer Electronic Cash System“. Dieses Bitcoin Whitepaper beschreibt ein elektronisches Zahlungssystem, das ohne Bank oder Zahlungsdienstleister auskommt.

Der Ausgangspunkt ist eine einfache Beobachtung: Online-Zahlungen laufen fast immer über eine dritte Partei. Kreditkartenunternehmen, Banken oder Zahlungsdienste bestätigen Transaktionen, verwalten Konten und können Zahlungen im Nachhinein rückgängig machen.

Diese Vermittlerrolle bringt Kosten und Reibung mit sich. Für kleine Beträge lohnt sich der Aufwand oft kaum, und ein gewisser Anteil an Betrug wird als unvermeidbar hingenommen. Das Bitcoin Whitepaper schlägt stattdessen ein System vor, in dem sich zwei Parteien direkt einigen, ohne dass eine dritte Instanz dazwischensteht.

Die Bausteine des Bitcoin Whitepapers

Damit ein elektronisches Zahlungssystem ohne Vermittler funktioniert, muss es zwei technische Probleme lösen. Das erste betrifft den Nachweis, dass eine Zahlung tatsächlich vom Absender stammt. Das Whitepaper setzt dafür auf digitale Signaturen: Jede Münze wird als Kette von Signaturen verstanden, bei der jeder Eigentümer die vorherige Transaktion und den öffentlichen Schlüssel des nächsten Empfängers signiert.

Ein zweites Problem ist die doppelte Ausgabe derselben Münze. Bei rein digitalen Werten lässt sich eine Datei beliebig kopieren, ohne dass Absender oder Empfänger es merken. Ohne eine zentrale Prüfstelle könnte jemand denselben Betrag zweimal versenden.

Das vollständige Bitcoin Whitepaper ist bis heute öffentlich einsehbar, etwa als Originaldokument auf bitcoin.org. Es zeigt, wie knapp und konkret die ursprüngliche Beschreibung des Systems ausfällt.

Um Doppelausgaben zu verhindern, braucht es eine Möglichkeit, Transaktionen öffentlich und in der richtigen Reihenfolge festzuhalten. Hier setzt der zweite Teil des Whitepapers an.

Konsens über Rechenleistung

Die Lösung für das Reihenfolge-Problem ist ein Zeitstempel-Netzwerk auf Basis von Proof-of-Work. Transaktionen werden zu Blöcken zusammengefasst, und für jeden Block muss ein Rechenrätsel gelöst werden, das nachweisbaren Aufwand an Rechenleistung voraussetzt.

Jeder neue Block enthält den Hash des vorherigen Blocks. Dadurch entsteht eine Hash-Chain: Wer einen bereits bestätigten Block nachträglich verändern wollte, müsste auch alle folgenden Blöcke neu berechnen und dabei schneller sein als der Rest des Netzwerks.

Der Konsens im Netzwerk ergibt sich allein aus Rechenleistung, nicht aus Abstimmungen nach Kopfzahl. Jeder Teilnehmer folgt der längsten Kette gültiger Blöcke, weil sie den größten nachgewiesenen Rechenaufwand darstellt. So entsteht ohne zentrale Autorität eine gemeinsame, manipulationsresistente Reihenfolge von Transaktionen.

Digitale Signaturen, eine Hash-Chain und Konsens über Rechenleistung verbindet das Bitcoin Whitepaper zu einem einzigen elektronischen Zahlungssystem ohne Mittelsperson.

berichteten wir über Bitcoins Vorgeschichte: Die Fakten vor dem Whitepaper.

Bevor Satoshi Nakamoto 2008 das Bitcoin-Whitepaper veröffentlichte, legten Jahrzehnte kryptografischer Forschung und mehrere gescheiterte digitale Geldkonzepte den Grundstein.

Die kryptografischen Wurzeln von Bitcoin

Bitcoins Vorgeschichte beginnt nicht 2008, sondern reicht mehrere Jahrzehnte zurück. Ohne bestimmte kryptografische Wurzeln aus den 1970er und 1980er Jahren hätte das Whitepaper keine Grundlage gehabt. Wer diese Zusammenhänge verstehen will, setzt deshalb zuerst bei der Kryptografie an.

Ein zentraler Baustein war die asymmetrische Kryptografie, die 1976 von Whitfield Diffie und Martin Hellman öffentlich beschrieben wurde. Sie zeigten, dass zwei Parteien ein gemeinsames Geheimnis austauschen können, ohne sich vorher zu kennen. Daraus entstanden Schlüsselpaare aus öffentlichem und privatem Schlüssel, wie sie später jede Bitcoin-Adresse nutzt.

Daneben spielten kryptografische Hashfunktionen eine zentrale Rolle. Sie wandeln beliebige Daten in eine feste, eindeutige Zeichenkette um, aus der sich die Ausgangsdaten nicht zurückrechnen lassen. Ralph Merkle trug mit Arbeiten zu Hashbäumen und digitalen Signaturen dazu bei, dass solche Funktionen praktisch nutzbar wurden.

Bitcoins Vorgeschichte im Überblick

In den 1980er und 1990er Jahren bildete sich rund um diese Werkzeuge die Cypherpunk-Bewegung. Ab 1992 tauschten sich ihre Mitglieder über eine Mailingliste aus und verfolgten das Ziel, mit Kryptografie Privatsphäre gegenüber Staaten und Banken zu stärken. Viele spätere Bitcoin-Ideen wurden dort zuerst diskutiert.

David Chaum entwickelte bereits 1983 ein Konzept für digitales Bargeld namens eCash, das auf blinden Signaturen beruhte. Zahlungen sollten anonym bleiben, ohne dass eine Bank den Käufer erkennen konnte. Das System blieb jedoch auf eine zentrale ausgebende Stelle angewiesen, die Doppelausgaben verhinderte.

Stuart Haber und W. Scott Stornetta veröffentlichten 1991 ein Verfahren, um Dokumente durch verkettete Hashwerte fälschungssicher mit einem Zeitstempel zu versehen. Jeder neue Eintrag verwies auf den vorherigen, sodass eine nachträgliche Änderung sofort auffiel.

Adam Back stellte 1997 mit Hashcash ein Verfahren gegen E-Mail-Spam vor. Der Absender musste vor dem Versand eine Rechenaufgabe lösen, deren Ergebnis leicht zu prüfen, aber aufwendig zu erzeugen war. Dieses Konzept des Arbeitsnachweises wurde später zur Grundlage des Bitcoin-Minings.

Vom Konzept zum funktionierenden System

Nick Szabo skizzierte 1998 mit Bit Gold ein digitales Geldsystem, das Rechenaufgaben mit einer dezentralen Kette von Eigentumsnachweisen verband. Wenig später beschrieb Wei Dai mit b-money ein verwandtes Konzept. Beide Entwürfe blieben theoretisch und wurden nie vollständig umgesetzt.

2004 baute Hal Finney mit RPOW, einem wiederverwendbaren Arbeitsnachweis, direkt auf Hashcash auf. Nutzer konnten digitale Werteinheiten untereinander weiterreichen. Auch dieses System benötigte weiterhin einen zentralen Server, der jede Übertragung bestätigte.

Genau hier blieb Bitcoins Vorgeschichte über Jahre stecken: Niemand fand eine Lösung dafür, wie ein Netzwerk aus fremden Teilnehmern ohne zentrale Instanz feststellen kann, welche Zahlung zuerst erfolgte. Das Problem der Doppelausgabe verlangte nach einem dezentralen Konsens.

Über das Konzept von Wei Dai, das eine der letzten Zutaten für dieses Konsensproblem lieferte, berichteten wir bereits gesondert im vorherigen Teil dieser Serie zu Bitcoins Vorgeschichte.

Wie b-money Kontostände öffentlich bestätigt, dezentrale Geldschöpfung an Rechenaufgaben koppelt und Transaktionen nur bei Einigung aller Teilnehmer zustande kommen.

Kontostände öffentlich bestätigen

Eine Datenbank, die niemandem allein gehört, klingt zunächst widersprüchlich. Wenn keine zentrale Instanz die Kontostände verwaltet, muss jeder Teilnehmer selbst prüfen können, ob die Zahlen stimmen. Genau hier setzt das b-money Konsens-Modell an, das Wei Dai 1998 skizzierte.

Die Idee ist einfach formuliert: Alle Teilnehmer führen eine eigene Kopie der Kontostände und veröffentlichen regelmäßig ihren Stand. Stimmen die Meldungen überein, gilt der Kontostand als bestätigt. Weicht eine Meldung ab, muss das Netzwerk klären, welche Version korrekt ist. Erst wenn genügend Teilnehmer denselben Stand melden, gilt er als gesichert.

An die Stelle von Bank oder Zahlungsdienstleister als Kontrollinstanz tritt diese öffentliche Bestätigung. Vertrauen entsteht nicht durch eine Institution, sondern durch den Abgleich vieler unabhängiger Kopien. Das war 1998 ein ungewöhnlicher Gedanke, weil digitales Geld bis dahin fast immer einen Betreiber im Zentrum hatte.

Ohne diesen laufenden Abgleich könnte jeder Teilnehmer behaupten, über beliebig viel Guthaben zu verfügen. Die regelmäßige Veröffentlichung macht solche Behauptungen überprüfbar und damit wertlos.

Dezentrale Geldschöpfung durch Rechenaufgaben

Ohne Zentralbank stellt sich sofort die Frage, wer neues Geld schöpfen darf und nach welcher Regel. Wei Dais Antwort war radikal: Dezentrale Geldschöpfung sollte an eine Rechenaufgabe gekoppelt werden, die jeder Teilnehmer lösen kann, aber niemand beliebig oft.

Wer die Aufgabe löst, erschafft eine festgelegte Menge Geld und veröffentlicht das Ergebnis zusammen mit dem Beweis der Rechenarbeit. Das Original-Dokument beschreibt dieses Verfahren im Detail (b-money-Papier) und macht deutlich, dass Aufwand die einzige Eintrittskarte zur Geldschöpfung sein sollte.

Im Kern der dezentralen Geldschöpfung bei b-money steht diese Kopplung an Rechenaufwand. Sie ersetzt eine politische Entscheidung durch eine mathematische Regel. Niemand kann per Beschluss mehr Geld schöpfen, als die Rechenaufgabe erlaubt.

Damit die dezentrale Geldschöpfung nicht zu Chaos führt, muss jede neu geschöpfte Menge ebenfalls veröffentlicht und von den anderen Teilnehmern akzeptiert werden. Erst die Bestätigung durch das Netzwerk macht aus einer gelösten Rechenaufgabe tatsächlich neues Geld.

Ohne Einigung keine Transaktion

Eine Transaktion von A zu B klingt banal, verlangt aber in einem dezentralen System einiges an Koordination. Bevor B das Geld akzeptiert, prüfen die übrigen Teilnehmer, ob A tatsächlich über ausreichend Guthaben verfügt.

Diese Prüfung läuft über einen Hash der Transaktion, der an das Netzwerk verteilt wird. Jeder Teilnehmer vergleicht den Hash mit seiner eigenen Kopie der Kontostände und meldet Zustimmung oder Widerspruch zurück.

Kommt keine Einigung zustande, wird die Transaktion schlicht verworfen. Es gibt keine übergeordnete Instanz, die im Streitfall entscheidet. Das Konsensprinzip von b-money macht die Zustimmung der Teilnehmer zur Voraussetzung für jede Bewegung von Geld.

Dieses Prinzip war ein früher Entwurf für das, was später als Konsensmechanismus bekannt wurde. Die Grundfrage blieb dieselbe: Wie einigen sich Fremde ohne Vermittler auf einen gemeinsamen Kontostand.

Wie berichteten wir über Das b-money Protokoll: Geld durch Rechenaufwand.

Wei Dais b-money Protokoll von 1998 beschreibt, wie Teilnehmer über eigene Datenbanken und Rechenaufwand dezentral Geld erzeugen, ganz ohne Zentralbank.

Eigene Datenbank für jeden Teilnehmer

Das b-money Protokoll entstand 1998, als der Informatiker Wei Dai einen Vorschlag für ein digitales Geldsystem auf einer Cypherpunk-Mailingliste veröffentlichte. Anders als bei einer Bank mit zentralem Kontobuch sollte jeder Teilnehmer eine eigene, vollständige Datenbank führen, in der alle Kontostände des Netzwerks vermerkt sind.

In dieser Datenbank steht, wie viele Geldeinheiten jeder Teilnehmer im Netzwerk besitzt. Findet eine Transaktion statt, tragen alle Teilnehmer die Änderung gleichzeitig in ihre eigene Kopie ein. Niemand muss einer einzelnen Instanz vertrauen, weil jeder die Kontostände selbst nachvollziehen und prüfen kann.

Diese Idee einer verteilten Buchführung ist einer der Kerngedanken, die das b-money Protokoll später für die Entwicklung digitalen Geldes so bedeutsam gemacht haben. Wer Geld senden wollte, musste seine Anweisung an alle anderen Teilnehmer verbreiten, damit jeder seine Datenbank aktualisieren konnte.

Geldschöpfung im b-money Protokoll

Neben der Kontoführung beschreibt das b-money Protokoll auch, wie neues Geld überhaupt entsteht. Die Grundregel ist einfach: Ein Teilnehmer löst ein rechenintensives Problem, das bisher ungelöst war, und veröffentlicht die Lösung samt Nachweis gegenüber den anderen Teilnehmern im Netzwerk.

Die Menge der neu erzeugten Geldeinheiten richtet sich dabei nach den Kosten des Rechenaufwands, der für die Lösung nötig war. Wer mehr Rechenleistung investiert, erzeugt mehr Geld. Wer weniger investiert, entsprechend weniger. Dieser Mechanismus sorgt für eine dezentrale Geldschöpfung, ohne dass eine Zentralbank oder ein Emittent über die Menge entscheidet.

Für das b-money Protokoll war das ein Weg, Knappheit ohne Institution herzustellen. Die Kosten der Rechenarbeit setzen der Geldmenge eine natürliche Grenze, da niemand beliebig viel Rechenleistung kostenlos zur Verfügung hat. Details zum ursprünglichen Vorschlag lassen sich im Originaltext von Wei Dai nachlesen, den er 1998 veröffentlichte.

Server und Sicherheiten als zweiter Weg

Wei Dai skizzierte im b-money Protokoll noch eine zweite Variante, weil die erste in der Praxis kaum umsetzbar war. Alle Teilnehmer müssten dafür permanent online sein und jede Transaktion jedes anderen Teilnehmers verarbeiten, was bei vielen Nutzern schnell an Grenzen stößt.

In der zweiten Variante übernehmen ausgewählte Teilnehmer mit eigenen Servern die Verarbeitung der Transaktionen. Damit diese Server nicht betrügen, mussten sie zuvor Geld als Sicherheit hinterlegen, die bei nachweisbarem Fehlverhalten verloren ging und an ehrliche Teilnehmer verteilt wurde.

Im Ergebnis blieb der Grundgedanke des b-money Protokolls erhalten: Jeder Teilnehmer kann durch eigene Arbeit Geld erzeugen, unabhängig davon, ob er über die einfache oder die serverbasierte Variante am Netzwerk teilnimmt. Beide Wege verzichten auf eine zentrale Ausgabestelle.

Wei Dais Entwurf blieb ein theoretisches Papier und wurde nie vollständig umgesetzt. Dennoch griffen spätere Konzepte zentrale Bausteine des b-money Protokolls auf, etwa die Kopplung von Geldschöpfung an nachweisbaren Rechenaufwand. Zuvor berichteten wir über Digitale Knappheit: BitGold und der Arbeitsnachweis.

Wie Hal Finneys BitGold-Konzept mit Zeitstempeln erstmals digitale Knappheit und begrenzte Produktionskosten für digitale Token nachweisbar machte.

Hal Finney und der wiederverwendbare Arbeitsnachweis

HashCash von Adam Back löste das Spam-Problem, hatte aber eine Schwäche: Jeder berechnete Arbeitsnachweis war nur einmal verwendbar und danach wertlos. Der Kryptograf Hal Finney griff diese Lücke 2004 auf und veröffentlichte ein System namens RPOW, kurz für Reusable Proofs of Work. Es sollte den einmaligen Arbeitsnachweis in ein wiederverwendbares, handelbares Gut verwandeln.

Die Idee dahinter: Ein einmal berechneter Arbeitsnachweis sollte nicht verfallen, sondern als Token weitergereicht und erneut eingelöst werden können. Damit näherte sich Finney einem Konzept, das später als BitGold bekannt wurde und digitale Knappheit erstmals technisch greifbar machte.

Entscheidend war, dass der Code für die Ausgabe und Prüfung der Token nicht bei Finney selbst lag, sondern auf einem entfernten, für Dritte einsehbaren Server lief. Niemand, auch nicht der Betreiber, sollte die Ausgabe neuer Token nach Belieben manipulieren können. Diese Kontrolle durch Dritte war für ein digitales System dieser Zeit neu.

Zeitstempel als Nachweis digitaler Knappheit

Ein zentrales Element von BitGold war der Zeitstempel. Jeder Arbeitsnachweis wurde mit dem Zeitpunkt seiner Berechnung versehen, sodass sich im Nachhinein rekonstruieren ließ, wann ein Token entstanden ist und welcher Schwierigkeitsgrad zu diesem Zeitpunkt galt. Der BitGold-Zeitstempel verband so Herstellungszeit und Aufwand in einem einzigen Datensatz.

Diese Verknüpfung von Zeitstempel und Schwierigkeitsgrad war mehr als eine technische Fußnote. Sie erlaubte es, den tatsächlichen Rechenaufwand hinter einem digitalen Token nachzuweisen, ohne einer zentralen Stelle vertrauen zu müssen. Wer den Zeitstempel prüfte, konnte die Produktionskosten des Tokens gut einschätzen.

Damit rückte digitale Knappheit in greifbare Nähe: Ein Token war nicht mehr beliebig kopierbar und wertlos, sondern an einen nachweisbaren, zeitlich verorteten Aufwand gebunden. Für rein digitale Güter war das ein neuer Ansatz, denn bis dahin ließ sich digitale Knappheit kaum glaubhaft herstellen.

Begrenzte Inflation durch Produktionskosten

Aus dem Zeitstempel-Mechanismus ergab sich ein weiterer Effekt: Weil sich Herstellungszeitpunkt und Schwierigkeitsgrad jedes Tokens nachvollziehen ließen, konnte auch der Zufluss neuer Token erstmals über nachweisbare Produktionskosten begrenzt werden.

Wollte jemand viele Token gleichzeitig erzeugen, musste er auch entsprechend viel Rechenaufwand tatsächlich erbringen. Ein Ausweichen auf billigere Abkürzungen ließ sich über den Zeitstempel und den dokumentierten Schwierigkeitsgrad erkennen. So entstand ein System, in dem Inflation nicht durch Regeln allein, sondern durch echten, nachprüfbaren Aufwand begrenzt war.

BitGold selbst wurde nie als laufendes Netzwerk umgesetzt und blieb ein Konzept auf dem Papier und in Finneys Code-Entwürfen. Spätere Systeme griffen die zugrunde liegenden Bausteine auf: Arbeitsnachweis, Zeitstempel und darüber begrenzte Produktionskosten, um digitale Knappheit ohne zentrale Ausgabestelle zu erzeugen.

Bereits berichteten wir über den HashCash-Arbeitsnachweis: Adam Backs Antwort auf Spam.

1997 entwickelte Adam Back mit HashCash ein System gegen E-Mail-Spam, das Rechenleistung als Nachweis nutzte und den Proof-of-Work Ursprung markiert.

Adam Backs Kampf gegen E-Mail-Spam

1997 veröffentlichte der britische Kryptograf Adam Back eine Idee, die auf den ersten Blick nichts mit Geld zu tun hatte. Er suchte eine Lösung gegen ein Problem, das damals viele Nutzer des frühen Internets nervte: E-Mail-Spam, der mit wachsender Netzverbreitung rasant zunahm.

Back stellte sein Konzept am 28. März 1997 auf der Cypherpunks-Mailingliste vor. Der Grundgedanke war einfach: Wer eine Nachricht verschicken will, muss zuvor eine kleine Rechenaufgabe lösen. Für einen einzelnen Absender kostet das kaum Zeit, für Massenversender mit Millionen Nachrichten wird der Aufwand schnell unpraktikabel.

Back nannte seine Lösung HashCash. Der Name verweist auf zwei Dinge zugleich: die kryptografische Hashfunktion, die für die Berechnung genutzt wird, und das Bild von Cash, also Bargeld, das erst durch Aufwand entsteht. Anders als klassisches Geld lässt sich dieser Aufwand jedoch von jedem beliebigen Rechner aus erbringen.

Rechenleistung als HashCash Arbeitsnachweis

Technisch funktioniert der HashCash Arbeitsnachweis über sogenannte partielle Hash-Kollisionen. Ein Absender muss einen Wert finden, dessen Hash mit einer bestimmten Anzahl von Nullen beginnt. In der ursprünglichen Version legte Back die Schwelle auf 20 Bit fest, was im Schnitt rund eine Million Rechenschritte erfordert.

Das Prinzip lässt sich mit einer Lotterie vergleichen: Es gibt keinen schnelleren Weg zum passenden Wert als einfaches Ausprobieren. Diese Eigenschaft macht den HashCash Arbeitsnachweis überprüfbar mit einem einzigen Rechenschritt, aber teuer in der Erzeugung. Details dazu beschrieb Back später in seinem Paper, das die Methode formal ausarbeitet.

Für E-Mails bedeutete das: Jede Nachricht trägt einen Stempel, der beweist, dass CPU-Zeit investiert wurde. Ein Mailserver kann diesen Stempel in Millisekunden prüfen und Nachrichten ohne gültigen HashCash Arbeitsnachweis automatisch aussortieren.

Für Privatnutzer mit wenigen E-Mails pro Tag blieb der Aufwand unbemerkbar. Für Spam-Versender, die auf Masse angewiesen sind, summierte sich die Rechenzeit dagegen zu einem echten Hindernis.

Vom Spamschutz zum Proof-of-Work

Was als Werkzeug gegen lästige Werbemails begann, erwies sich als Vorlage für ein deutlich größeres Konzept. Der Proof-of-Work Ursprung liegt genau in dieser Idee: Zugang oder Ressourcen werden an nachweisbare Rechenarbeit gekoppelt, statt an Vertrauen oder eine zentrale Instanz.

Spätere Systeme griffen dieses Muster auf und übertrugen es auf andere Probleme, etwa auf die Frage, wie ein Netzwerk ohne zentrale Kontrolle Einigkeit über die Reihenfolge von Transaktionen herstellen kann. Der Grundmechanismus blieb dabei erstaunlich nah am Original: Rechenaufwand als Filter, der billig zu prüfen und teuer zu fälschen ist.

Bemerkenswert ist, wie lange dieser Gedanke unbemerkt blieb, bevor er zur Grundlage eines globalen Netzwerks wurde. Back selbst hat die Idee nie patentiert, sondern frei zur Verfügung gestellt.

Wie stark dezentrale Systeme schon vor diesem Schritt experimentierten, zeigten frühere Netzwerke abseits von HashCash. So berichteten wir über Dezentrale Netzwerke vor Bitcoin: Napster, Gnutella, Tor.