Allerdings meldete Claus Schnorr (im Juni 2025 verstorben) 1989 ein Patent auf sein System an. Um es kommerziell oder in großen Projekten zu nutzen, hätten Entwickler und Standardisierungsorganisationen gigantische Lizenzgebühren zahlen müssen.

Die Notlösung: DSA und ECDSA (1991)#

Weil Regierungen und die Tech-Industrie dringend einen Standard für digitale Signaturen brauchten, aber nicht für das Schnorr-Patent zahlen wollten, entwickelte die US-Behörde NIST (National Institute of Standards and Technology) eine eigene Variante: den sogenannten DSA (Digital Signature Algorithm).

DSA basierte zwar grob auf ähnlichen Konzepten wie Schnorr, wurde aber absichtlich umständlicher konstruiert (durch das Hinzufügen der berüchtigten modularen Division, die alles nicht-linear und klobig macht), um das Patent von Claus Schnorr zu umgehen.

Als dann später die Elliptischen Kurven (Elliptic Curves) als revolutionär neue Basis für Kryptografie entdeckt wurden, passte man diesen umständlichen Standard einfach daran an. Das Resultat war ECDSA (Elliptic Curve DSA). ECDSA erbte die mathematische Klobigkeit von DSA, war aber durch die Elliptischen Kurven zumindest sehr speichereffizient. Da das Verfahren frei von Patenten war, wurde es der weltweite Standard.

Warum Satoshi Nakamoto kein Schnorr nutzte#

Das Schnorr-Patent lief im Februar 2008 ab – also wenige Monate bevor Satoshi Nakamoto das Bitcoin-Whitepaper (Ende 2008) veröffentlichte und den Code (Anfang 2009) ins Netz stellte.

Warum hat Satoshi also nicht direkt das frisch befreite, viel elegantere Schnorr-Verfahren für Bitcoin genutzt?

• Fehlende Infrastruktur: Weil Schnorr fast 20 Jahre lang unter Patentverschluss stand, war es quasi nicht erforscht und nicht standardisiert worden.
• Kein fertiger Code: Es gab 2008 schlichtweg keine erprobten Standard-Bibliotheken (wie z. B. in OpenSSL), die Schnorr-Signaturen reibungslos unterstützten.
• ECDSA war etabliert: ECDSA hingegen war quelloffen, von tausenden Kryptografen über Jahre hinweg auf Sicherheitslücken geprüft worden und in OpenSSL völlig trivial und sicher als fertiger Codebaustein verfügbar.

Satoshi nahm ganz pragmatisch das, was verfügbar und kampferprobt war: ECDSA.

Hätte Claus Schnorr sein Verfahren damals Open-Source gemacht, hätte ECDSA in der Kryptografie wahrscheinlich nie existiert. Wir hätten von Tag 1 an lineare, leicht kombinierbare Signaturen gehabt und elegante Multisig-Lösungen (wie Threshold Signatures oder FROST) wären der absolute Standard seit den frühen Tagen des Internets.

Heute, da das Patent lange abgelaufen ist und neue Bitcoin-Projekte Zeit hatten, sich von den Altlasten zu befreien, kehrt die Welt endlich zur mathematisch überlegenen Schnorr-Signatur zurück (wie etwa durch das Taproot-Update von Bitcoin im Jahr 2021).

Die Blockade für elegante Verteilung#

Weil ein einzelner Schlüssel ein Risiko darstellen, will man dieses Risiko auf mehrere Parteien aufteilen (Multi-Party Computation / Threshold Signatures). Und hier**** wird ECDSA zum Albtraum:

Die Mathematik hinter ECDSA ist nicht-linear (sie nutzt die sogenannte modulare Inversion). Wenn man einen ECDSA-Schlüssel in mehrere Fragmente zerlegt, ist es unglaublich kompliziert und rechenintensiv, diese Fragmente dezentral wieder zu einer gültigen Signatur zusammenzufügen. Das System muss unzählige Male hin und her kommunizieren (7+ Runden) und schwerfällige mathematische Beweise austauschen.

Die Folge von ECDSA: Klobiges „On-Chain“ Multisig#

Da sich ECDSA offline so schwer aufteilen ließ, griffen Netzwerke (wie Bitcoin vor dem Taproot-Update oder Ethereum) auf eine Notlösung zurück: das klassische On-Chain-Multisig. Dabei generiert das System keine gemeinsame Maske, sondern schreibt einfach mehrere völlig separate ECDSA-Signaturen auf die Blockchain.

Das wiederum verursacht Probleme:

• Hohe Kosten: Anstatt einer einzigen Signatur müssen beispielsweise bei einem 3-of-5-Setup drei separate Signaturen auf der Blockchain validiert und gespeichert werden.
• Fehlende Privatsphäre: Jeder Beobachter auf der Blockchain kann genau sehen: „Das ist ein Multisig-Wallet und Person A, B und C haben gerade signiert.“

FROST#

FROST (was für Flexible Round-Optimized Schnorr Threshold steht) ist im Grunde die Erlösung von all den Kopfschmerzen, die uns ECDSA bereitet hat. Es kombiniert die Eleganz der Schnorr-Signatur mit schlauem Netzwerk-Design.

Um zu verstehen, warum FROST wie pure Magie wirkt, müssen wir uns ansehen, wie es die alten Probleme löst:

Der Super-Schlüssel existiert nie im Ganzen#

Bei alten Systemen musste oft eine Person (oder ein Programm) den privaten Schlüssel erst erstellen und dann in Stücke hacken, um ihn an andere zu verteilen. Das war ein massives Risiko: Wer den Schlüssel erstellt, könnte sich heimlich eine Kopie speichern.

FROST nutzt sogenannte Multi-Party Computation (genauer: Distributed Key Generation). Die Teilnehmer generieren den privaten Schlüssel gemeinsam. Jeder erstellt nur einen mathematischen Bruchteil, und diese Bruchteile werden miteinander verknüpft. Der komplette, "echte" private Schlüssel existiert zu keinem einzigen Zeitpunkt als Ganzes auf irgendeinem Computer. Ein Hacker müsste also gleichzeitig in mehrere, weltweit verteilte Geräte einbrechen, um etwas stehlen zu können.

Mathematisches "Lego" statt Klobigkeit#

Wie zuvor besprochen, war das Zusammenbauen einer ECDSA-Signatur aus mehreren Teilen ein mathematischer Albtraum. FROST hingegen basiert auf Schnorr.

Weil Schnorr linear ist, funktioniert das Signieren im Grunde wie einfache Addition. Person A nimmt ihr Schlüsselfragment und berechnet eine Teilsignatur. Person B tut dasselbe. Um die finale Signatur zu erhalten, werden Teilsignatur A und Teilsignatur B einfach mathematisch addiert. Keine komplexen Inversionen, keine Fehleranfälligkeit. Es passt wie Lego zusammen.

Die "Runden-Optimierung" (Das RO in FROST)#

Das war der eigentliche Durchbruch dieses spezifischen Protokolls (das 2020 von Chelsea Komlo und Ian Goldberg vorgestellt wurde).

Um gemeinsam eine Multisig-Transaktion zu berechnen, müssen die Teilnehmer Daten austauschen. Bei ECDSA-basierten Threshold-Signaturen brauchte man 7 bis 9 Kommunikationsrunden – ein ständiges Hin und Her. Wenn ein Teilnehmer in der Zwischenzeit das Internet verlor, brach alles ab. FROST drückt diesen Prozess auf nur 2 Runden herunter. Wenn die Teilnehmer sogar kleine "Vorabrechnungen" machen, während sie ohnehin online sind, kann der eigentliche Signaturprozess in 1 einzigen Runde (asynchron) ablaufen. E-Mail-ähnliche Kommunikation reicht dafür völlig aus.

Ultimative Privatsphäre (Das "On-Chain"-Wunder)#

Erinnerst du dich an die klobigen Smart-Contract-Multisigs, bei denen jeder auf der Blockchain sehen kann, wer wann mit wem signiert hat?

FROST löst dieses Problem komplett offline (Off-Chain). Die Teilnehmer rechnen ihre Teilsignaturen unter sich zusammen. Was am Ende auf die Blockchain hochgeladen wird, ist genau eine einzige, völlig gewöhnlich aussehende Signatur. Für einen Beobachter auf der Blockchain ist nicht erkennbar, ob diese Signatur von einer Einzelperson erstellt wurde, oder ob sich dahinter ein FROST-Setup mit 100 Mitgliedern einer Organisation verbirgt.

Drastisch geringere Kosten#

Da das Endresultat einer FROST-Transaktion nur eine einzige Signatur ist, muss das Netzwerk auch nur eine einzige Signatur überprüfen und speichern.

Das bedeutet:

• Ein 1-von-1 Wallet kostet Summe X an Gebühren.
• Ein 7-von-10 Multi-Signatur-Wallet kostet exakt dieselbe Summe X an Gebühren.

FROST ermöglicht also institutionelle Sicherheit und Dezentralisierung für Bruchteile von Cents, während es gleichzeitig die Privatsphäre aller beteiligten Parteien schützt.