Schnorr-Signaturen und Multisig-Aggregation

Im vorherigen Artikel sind wir durchgegangen, wie SSP tatsächlich eine Multisig-Wallet on-chain konstruiert: BIP48-Pfade, zwei xpubs in lexikographischer Reihenfolge, ein Redeem-Skript, gegen das die Chain prüft. Diese gesamte Mechanik ist auf einem bestimmten Signaturschema aufgebaut — ECDSA auf der Kurve secp256k1, dem gleichen Schema, mit dem Bitcoin 2009 startete und das die meisten Chains geerbt haben.

Dieser Artikel handelt vom anderen Signaturschema — Schnorr — und davon, was sich ändert, wenn du Multisig darauf aufbaust. Die Schlagzeile: Schnorr unterstützt Aggregation — unter dem richtigen Protokoll können n Signaturen von n Cosignern zu einer einzigen Signatur kombiniert werden, die on-chain aussieht wie eine normale Signatur eines einzelnen Schlüssels. Die Wallet verhält sich wie eine Multisig-Wallet, aber die Chain sieht die Multi-Eigenschaft nie. Das hat reale Folgen für Gebühren, Privatsphäre und welche Arten von Multisig wirtschaftlich tragfähig werden.

TL;DR

• ECDSA ist das, womit der meiste aktuelle Multisig (einschließlich SSP heute) signiert. Jeder Cosigner produziert eine separate Signatur; die Chain prüft alle. Kosten und Footprint skalieren mit n.
• Schnorr ist ein anderes Signaturschema, das auf Bitcoin durch das Taproot-Upgrade 2021 aktiviert wurde. Es hat eine mathematische Eigenschaft — Linearität —, die ECDSA fehlt. Linearität erlaubt es, mehrere Schnorr-Signaturen zu addieren, um eine einzelne gültige Signatur für einen kombinierten Schlüssel zu erhalten.
• MuSig2 ist das moderne, praktikable Protokoll, das diese mathematische Eigenschaft in ein nutzbares Multisig-Protokoll verwandelt. n Cosigner führen ein kurzes interaktives Protokoll aus, jeder steuert eine Nonce-Runde und eine Teilsignatur bei; das Ergebnis ist eine einzelne Schnorr-Signatur, die nicht von einer Signatur eines einzelnen Schlüssels zu unterscheiden ist.
• Das ist ein klarer Gewinn auf der Verifikationsseite — Gebühren, Blockchain-Aufblähung und Privatsphäre profitieren alle. Es ist kein Gratis-Gewinn auf der Signierseite: Aggregation braucht sorgfältige Nonce-Behandlung, und eine fehlerhafte Implementierung kann private Schlüssel leaken.
• SSP nutzt heute BIP48 + ECDSA-Multisig auf den unterstützten Chains. Die Roadmap sieht vor, Schnorr/MuSig2-Pfade dort hinzuzufügen, wo die Chain sie unterstützt, ohne das bestehende 2-of-2-Modell zu brechen, das Nutzer bereits haben.

Eine kurze Auffrischung: was eine Signatur leistet

Eine digitale Signatur beweist einem Verifizierer zwei Dinge: diese exakte Nachricht wurde von jemandem signiert, der den privaten Schlüssel zu diesem öffentlichen Schlüssel hält. On-chain ist die „Nachricht" ein Transaktions-Hash, der „öffentliche Schlüssel" ist die Adresse (oder das, was die Adresse ableitet), und der „Verifizierer" ist jeder Knoten im Netzwerk. Stimmt die Signatur, ist die Transaktion gültig; sonst wird sie abgelehnt.

ECDSA — das Schema, das Bitcoin und die meisten EVM-Chains nutzen — ist gut verstanden, konservativ und funktioniert gut für den Fall eines einzelnen Signierers. Das Problem ist, was passiert, wenn du mehrere Signierer haben willst, die dieselbe Transaktion autorisieren. ECDSA hat keine Möglichkeit, Signaturen zu kombinieren. Willst du two-of-two, muss die Chain beide Signaturen speichern und beide prüfen. Three-of-five, fünf Signaturen. Die Transaktion wächst mit der Cosigner-Zahl.

What is multisig beschreibt den Protokoll-Teil — m von n Schlüsseln, Redeem-Regeln, die Chain setzt die Schwelle durch. Worüber dieser frühere Beitrag nicht verweilt, sind die Kosten: unter ECDSA leben all diese Signaturen in der Transaktion. Eine 2-of-2 P2WSH-Transaktion ist wirklich größer und teurer zu broadcasten als eine Single-Sig-Transaktion mit dem gleichen Effekt.

Was Schnorr ändert

Schnorr-Signaturen, ursprünglich Ende der 1980er vorgeschlagen, wurden im ursprünglichen Bitcoin-Design wegen damaliger Patentunsicherheiten gemieden. Sie sind in einem bestimmten Punkt mathematisch sauberer als ECDSA: sie sind linear. Ist s1 eine gültige Signatur auf einer Nachricht unter dem Schlüssel P1, und s2 eine gültige Signatur auf derselben Nachricht unter dem Schlüssel P2, dann ist s1 + s2 eine gültige Signatur auf dieser Nachricht unter P1 + P2. Sowohl Schlüssel als auch Signaturen addieren sich.

Warum das zählt: Es wird plötzlich möglich, Signaturen zu kombinieren, bevor sie die Chain treffen. Statt zwei Signaturen in der Transaktion zu speichern, speicherst du eine — die Summe. Der Verifizierer prüft die eine Signatur gegen die Summe der beiden öffentlichen Schlüssel, die beide Signierer im Voraus berechnen können. Aus Chain-Sicht ist die resultierende Transaktion nicht von einer mit einem einzelnen Schlüssel signierten Transaktion zu unterscheiden.

ECDSA kann das nicht. Die Mathematik von ECDSA enthält ein multiplikatives Inverses, das die Linearität bricht; Summen von ECDSA-Signaturen sind keine gültigen Signaturen. Deshalb muss ECDSA-basiertes Multisig alle Einzelsignaturen on-chain mitschicken. Die Chain inspiziert jede einzelne separat.

Bitcoin lieferte Schnorr-Signaturen (über BIP340) als Teil des Taproot-Soft-Forks 2021 aus. Die Signaturen selbst sind etwas kleiner als ECDSA-Signaturen (64 Bytes gegenüber ~71), aber der viel größere Punkt ist, was diese Linearität ermöglicht, wenn du sie mit Multisig kombinierst.

MuSig2 — Multisig, das on-chain wie eine einzelne Signatur aussieht

Die ehrliche Version von „du kannst Schnorr-Signaturen addieren" ist, dass du das sorgfältig tun musst. Der naive Ansatz — jeden Cosigner einen Nonce wählen lassen, seine Teilsignatur teilen, alles addieren — leakt Schlüsselmaterial bei wiederholter Signierung und ist verwundbar gegen eine Klasse von „Rogue-Key"-Angriffen. Ein praktikables Aggregationsprotokoll muss sich gegen beides absichern.

MuSig2 ist das Ergebnis von etwa einem Jahrzehnt der Verfeinerung an diesem Problem. Es ist der De-facto-Standard für n-of-n Schnorr-Multisig: zur Signierzeit tauschen die Cosigner zwei Runden von Nonces aus, jeder produziert eine Teilsignatur, und einer von ihnen summiert die Teilsignaturen zu einer endgültigen aggregierten Signatur. Das Ergebnis ist eine einzelne Schnorr-Signatur, gültig gegen einen einzelnen aggregierten öffentlichen Schlüssel, on-chain nicht von einer Single-Key-Signatur zu unterscheiden.

Einige wichtige Punkte zu MuSig2:

• Es ist derzeit n-of-n. Um echtes m-of-n (z. B. 2-of-3) unter Aggregation zu bekommen, brauchst du zusätzliche Maschinerie — FROST ist der führende Vorschlag — und das wird noch produktionsreif gemacht. 2026 würde SSP daher sauber das 2-of-2-Default aggregieren. Die 2-of-3- und höheren Konfigurationen aus dem Picker-Artikel nutzen meist immer noch ECDSA-artige On-Chain-Sichtbarkeit.
• Es benötigt immer noch beide Cosigner online, um zu signieren. Aggregation reduziert die Anzahl benötigter Signierer nicht; sie komprimiert nur die endgültige Ausgabe. Die UX ist die gleiche wie heute — zwei Geräte signieren dieselbe Transaktion — aber der On-Chain-Footprint des Ergebnisses ist kleiner.
• Eine fehlerhafte MuSig2-Implementierung kann Schlüssel leaken. Die Nonce-Behandlung ist subtil. Produktions-Deployments stützen sich aus diesem Grund auf gut auditierte Bibliotheken (das MuSig2-Modul von libsecp256k1, der rust-bitcoin-Stack usw.).

Was das für SSP heute bedeutet

SSP nutzt heute auf jeder unterstützten Chain BIP48-abgeleitetes ECDSA-Multisig. Zwei Geräte, zwei private Schlüssel, zwei separate Signaturen on-chain. Das ist korrekt, auditiert (von Halborn — siehe die Referenz inside-ssp-2025-halborn-audits im bestehenden 2-of-2-Beitrag) und interoperabel mit jeder anderen BIP48-konformen Wallet. Der Nachteil ist, dass du die vollen On-Chain-Kosten von 2-of-2 zahlst.

Die Roadmap ab hier im Klartext: einen Schnorr/MuSig2-Codepfad für Bitcoin hinzufügen (wo Taproot live und stabil ist), der dieselbe 2-of-2-Wallet stattdessen per Aggregation signiert. Die Schwellen-Semantik der Wallet ändert sich nicht — beide Geräte müssen weiterhin signieren. Die On-Chain-Bytes schrumpfen, und die resultierende Transaktion sieht aus wie eine Single-Sig-Spend.

Für den Nutzer würde sich das vor allem so zeigen:

• Leicht niedrigere Bitcoin-Gebühren pro Transaktion.
• Bessere Privatsphäre — die Wallet hört auf, „ich bin eine Multisig-Wallet" an Chain-Analytics zu broadcasten.
• Schnellere Abgleiche für die Wallet-UI (etwas weniger Daten pro Adresse zu holen und zu parsen).

Es ist kein — und das ist wert, klar zu sagen — Sicherheits-Upgrade. Die Kryptographie ist vergleichbar hart, nur anders strukturiert. Der Grund, es zu übernehmen, ist Effizienz und Privatsphäre, nicht rohe Sicherheit.

Was das für Kosten, Privatsphäre und UX bedeutet

Drei Stellen, an denen das landet, sobald Aggregation auf einer Chain breit ausgerollt ist:

Kosten. Bitcoin rechnet Gebühren grob nach Transaktionsgröße in vbytes ab. Eine 2-of-2 ECDSA P2WSH-Transaktion ist deutlich größer als die äquivalente Taproot-MuSig2-Transaktion. Für Wallets mit kleinem Saldo, die kleine Beträge senden, kann die relative Gebührenersparnis 20–30 % betragen. Für Unternehmen mit hohem Durchsatz sind die absoluten Ersparnisse bei den jährlichen Gebühren echtes Geld.

Privatsphäre. Heute, wenn eine Wallet eine 2-of-2 P2WSH-Ausgabe broadcastet, ist diese Tatsache jedem sichtbar, der einen Block-Explorer betreibt. Anspruchsvolle Chain-Analytics-Firmen clustern Adressen nach Spending-Mustern, und „diese Adresse ist Multisig" ist ein starkes Cluster-Signal. Eine Schnorr-aggregierte Ausgabe sieht identisch zu einer Single-Sig-Ausgabe aus. Das Cluster-Signal verschwindet.

UX. Die Signatur-UX in SSP — auf dem Browser signieren, dann auf dem Handy bestätigen — ändert sich nicht. Beide Geräte produzieren weiterhin Teilsignaturen; die Wallet kombiniert sie nur vor dem Broadcast, statt beide zu broadcasten. Aus Nutzersicht ist die einzige sichtbare Änderung „die Wallet fühlt sich günstiger zu benutzen an".

Am Horizont liegt auch ein tieferer UX-Gewinn. Sobald m-of-n-Aggregation (über FROST oder Ähnliches) produktionsreif ist, könntest du dir eine 2-of-3 SSP-Wallet vorstellen — wie das Solo-Recovery-Setup, das der vorherige Artikel beschreibt —, die on-chain aussieht wie eine normale Single-Sig-Wallet. Der dritte „Recovery"-Schlüssel ist wirklich ein dritter Signaturschlüssel, aber die Chain muss das nie wissen.

Was das für dich bedeutet

Drei Kernpunkte:

1. Du musst nicht an Schnorr denken, um SSP korrekt zu nutzen. Das 2-of-2-Setup, das du heute hast, ist auf gut auditiertes ECDSA-Multisig gebaut, und das bleibt so, unabhängig davon, wie Aggregation landet. Der nächste Artikel der Serie (social recovery vs multisig) ignoriert bewusst die Aggregation, weil die Frage wer ausgeben kann unabhängig davon ist, wie die Signatur on-chain aussieht.
2. Aggregation ist ein „Gebühren-und-Privatsphäre"-Upgrade, kein „Sicherheits"-Upgrade. Solltest du je eine Wallet sehen, die „MuSig2 = sicherer" vermarktet, sei skeptisch. Die kryptographische Sicherheit eines gut implementierten MuSig2 ist vergleichbar mit gut implementiertem ECDSA-Multisig; die Gewinne liegen woanders.
3. Schau auf die Chain-Unterstützung, nicht aufs Wallet-Marketing. Schnorr ist auf Bitcoin live und wird über Account Abstraction in der EVM-Welt übernommen. Die Chains, die es gut unterstützen, sind die, auf denen SSP zuerst aggregiertes Multisig ausrollen wird; überall sonst bleibt BIP48 + ECDSA das richtige und sichere Default.

Der nächste Artikel dieser Serie, Social recovery vs multisig, verschiebt den Fokus von der Kryptographie zur Operativen: wann greifst du zu Multisig und wann schlägt Social Recovery es? Beide schützen vor Schlüsselverlust; sie beantworten unterschiedliche Fragen. Für eine schnelle Auffrischung, welche Geräte SSP heute nutzt und warum, bleibt Meet SSP Wallet der Ausgangspunkt.