ECDSA- vs. Schnorr-Signaturen: was Taproot geändert hat

ECDSA vs. Schnorr ist heute vor allem eine Bitcoin-Frage: Taproot (BIPs 340–342, aktiviert im November 2021) hat Schnorr-Signaturen neben ECDSA auf derselben Kurve secp256k1 eingeführt. Beide Verfahren verwenden dieselben Schlüssel und beruhen auf demselben schweren Problem, doch dank der linearen Struktur von Schnorr lassen sich Multisignaturen, Schwellenwertsignaturen und Batch-Verifikation ganz natürlich umsetzen, während die Struktur von ECDSA sie umständlich macht.

Auf einen Blick

Wie sie sich unterscheiden

Beide signieren mit einer geheimen Nonce k und ihrem Punkt R = k·G. ECDSA verknüpft den Hash z, den privaten Schlüssel d und r (die x-Koordinate von R) über das modulare Inverse von k. Schnorr bildet stattdessen aus dem Commitment, dem öffentlichen Schlüssel und der Nachricht per Hash eine Challenge e und antwortet mit s = k + e·d; der Verifizierer prüft das als s·G = R + e·P.

Diese eine Konstruktionsentscheidung bestimmt alles Weitere:

• Linearität. Schnorr-Signaturen lassen sich addieren. Mehrere Signierer können Nonces und Teilantworten zu einer einzigen Signatur kombinieren, die mit der Summe ihrer Schlüssel die Prüfung besteht. MuSig2 (BIP-327) erledigt das in zwei Runden für n-von-n-Signaturen, FROST (RFC 9591) liefert t-von-n-Schwellenwertsignaturen. Bei ECDSA zerstört das Inverse von k die Linearität, deshalb erfordert Schwellenwert-ECDSA aufwendige Mehrparteienprotokolle, die Wallets und Verwahrer zwar einsetzen, in denen aber schon schwerwiegende Fehler steckten.
• Batch-Verifikation. Viele Schnorr-Signaturen lassen sich gemeinsam schneller prüfen als einzeln, was bei der Validierung von Blöcken zählt. ECDSA kennt keine solche Abkürzung.
• Bindung an den Schlüssel. Weil der öffentliche Schlüssel in den Hash e eingeht, lässt sich eine Schnorr-Signatur nicht unter einem anderen Schlüssel wiederverwenden, und der Schlüssel lässt sich nicht aus der Signatur wiederherstellen. ECDSA erlaubt die Wiederherstellung des öffentlichen Schlüssels, auf die Ethereum angewiesen ist, um Bytes zu sparen; bei Schnorr musst du den Schlüssel übertragen oder kennen.
• Malleability. Bei ECDSA bestehen (r, s) und (r, n − s) beide die Prüfung, deshalb erzwingt Bitcoin Low-S und striktes DER. BIP-340 legt eine einzige Kodierung fest, sodass Dritte eine gültige Signatur nicht verändern können.
• Geschichte. Das Verfahren von Claus Schnorr aus dem Jahr 1989 war patentiert, und DSA (später auch ECDSA) wurde so konstruiert, dass es das Patent umgeht; das Patent lief 2008 aus, als ECDSA bereits fest etabliert war. EdDSA (2011) ist eine deterministische Schnorr-Variante auf Edwards-Kurven.

Was Taproot in der Praxis geändert hat

Eine Taproot-Ausgabe legt sich auf einen einzigen x-only-Schlüssel mit 32 Byte fest. Das Ausgeben über den Key-Path braucht genau eine Schnorr-Signatur mit 64 Byte, ob dieser Schlüssel nun einer einzelnen Person gehört oder ein MuSig2-Aggregat aus mehreren Schlüsseln ist. Eine 2-von-2- oder 3-von-3-Multisig-Transaktion sieht on-chain deshalb aus wie jede Transaktion mit einer einzigen Signatur. Alternative Ausgabebedingungen liegen in einem Merkle-Baum aus Skripten, der erst bei Verwendung offengelegt wird. Beim entsprechenden Ausgeben mit einem einzelnen Schlüssel in SegWit v0 enthält der Witness eine DER-kodierte ECDSA-Signatur von bis zu 72 Byte plus ein Sighash-Byte und einen öffentlichen Schlüssel mit 33 Byte.

Das folgende Skript, ausgeführt mit @noble/curves 2.3.0 unter Node.js 26.10, zeigt den Größenunterschied für denselben geheimen Schlüssel.

import { secp256k1, schnorr } from "@noble/curves/secp256k1.js";
import { sha256 } from "@noble/hashes/sha2.js";
import { utf8ToBytes } from "@noble/hashes/utils.js";

const secretKey = secp256k1.utils.randomSecretKey();
const msg = sha256(utf8ToBytes("pay 0.01 BTC to bc1p..."));

// ECDSA: 33-byte compressed public key, 64-byte compact (r, s) signature.
const ecdsaPub = secp256k1.getPublicKey(secretKey, true);
const ecdsaSig = secp256k1.sign(msg, secretKey, { prehash: false });

// BIP-340 Schnorr: 32-byte x-only public key, 64-byte (R.x, s) signature.
const schnorrPub = schnorr.getPublicKey(secretKey);
const schnorrSig = schnorr.sign(msg, secretKey);

console.log("ECDSA   public key:", ecdsaPub.length, "bytes, signature:", ecdsaSig.length, "bytes, valid:", secp256k1.verify(ecdsaSig, msg, ecdsaPub, { prehash: false }));
console.log("Schnorr public key:", schnorrPub.length, "bytes, signature:", schnorrSig.length, "bytes, valid:", schnorr.verify(schnorrSig, msg, schnorrPub));

ECDSA   public key: 33 bytes, signature: 64 bytes, valid: true
Schnorr public key: 32 bytes, signature: 64 bytes, valid: true

Auch die kompakte ECDSA-Form hat 64 Byte, doch Bitcoin-Skripte transportieren ECDSA als DER, und Ethereum hängt ein Recovery-Byte an; die Schnorr-Form landet unverändert on-chain.

Gemeinsame Fallstricke

Keines der beiden Verfahren verzeiht eine schlechte Nonce: Wer k für zwei Nachrichten wiederverwendet oder wiederholt ein paar Bits davon preisgibt, legt bei beiden den privaten Schlüssel offen. BIP-340 empfiehlt, die Nonce aus Schlüssel und Nachricht abzuleiten und dabei 32 Byte frischen zusätzlichen Zufall einzumischen. Schnorr mit mehreren Parteien bringt eine neue Regel mit: MuSig2-Nonces dürfen nie allein aus der Nachricht deterministisch abgeleitet werden, denn ein Angreifer, der einen anderen Teilnehmer steuert, kann dieselbe Nonce zwei verschiedene aggregierte Challenges signieren lassen. Verwende auditierte Implementierungen wie das MuSig2-Modul von libsecp256k1, statt Primitive selbst zusammenzusetzen.

Wann welches Verfahren passt

• Neue Bitcoin-Wallets und -Ausgaben: Ausgeben über den Taproot-Key-Path mit Schnorr; MuSig2 für Schlüssel mehrerer Parteien, wenn sich die Beteiligten abstimmen können, Script-Paths als Rückfallebene.
• Signieren von Bitcoin-Nachrichten: BIP-322 für Taproot-Adressen, denn das ältere Format BIP-137 kennt nur ECDSA.
• Ethereum und EVM-Chains: ECDSA, weil Transaktionen, ecrecover und Wallets darauf ausgelegt sind; Smart Accounts können andere Verfahren im Contract-Code prüfen.
• Nostr: BIP-340-Schnorr, wie NIP-01 es vorschreibt.
• Verwahrung mit Schwellenwertsignaturen: FROST, wo Verifizierer Schnorr- oder EdDSA-Signaturen akzeptieren; Schwellenwert-ECDSA nur, wo die Ziel-Chain ECDSA verlangt.
• Systeme außerhalb von Blockchains: Ed25519 bietet dir die Schnorr-Konstruktion mit einem Standard (RFC 8032), Unterstützung in Bibliotheken und deterministischen Nonces.

Hinweise zur Migration

In Bitcoin kann derselbe geheime Schlüssel beide Arten von Signaturen erzeugen, doch welche verlangt wird, bestimmen die Ausgaben: Die Migration besteht darin, Guthaben von P2WPKH- oder P2PKH-Ausgaben auf P2TR-Ausgaben zu verschieben.

1. Aktualisiere Wallet-Software und -Hardware auf Versionen, die Taproot (Ableitungspfad m/86'/0'/0' nach BIP-86) und die Taproot-Felder von PSBT unterstützen.
2. Verwende x-only-Schlüssel richtig: BIP-340-Schlüssel verzichten auf das Paritätsbyte, und Schlüssel werden per Tweak mit dem Commitment auf den Skriptbaum verändert; verwende keine Kodierungen öffentlicher ECDSA-Schlüssel wieder.
3. Stelle das Signieren von Nachrichten auf BIP-322 um, damit sich auch für Taproot-Adressen der Besitz nachweisen lässt.
4. Bei Multisig entscheide dich zwischen Key-Path-Aggregation mit MuSig2 (am privatesten und günstigsten, aber interaktiv) und Script-Paths mit OP_CHECKSIGADD in Tapscript (nicht interaktiv, legt die Policy bei Verwendung offen).
5. Prüfe ECDSA weiterhin für ältere Ausgaben; die Konsensregeln unterstützen beide auf unbestimmte Zeit.

Quellen

• BIP-340, Schnorr-Signaturen für secp256k1
• BIP-341, Taproot
• BIP-327, MuSig2
• RFC 9591, FROST
• FIPS 186-5, ECDSA
• SEC 1 v2, §4.1 ECDSA
• RFC 8032, EdDSA
• BIP-146, Low-S