Unsichtbares Multisig: Taproot, MuSig2 und FROST 2026

Wenn über Taproot gesprochen wird, geht es meist um Ordinals, um Rollups wie Citrea oder um die Frage, ob Bitcoin überhaupt noch einen Soft Fork aktivieren kann. Der praktisch wichtigste Effekt des Upgrades vom November 2021 steht dagegen selten im Rampenlicht: Taproot hat verändert, wie Schlüssel sich zu einer Signatur verbinden. Mehrere Unterschriften lassen sich seither zu einer einzigen verschmelzen, die auf der Blockchain aussieht wie eine ganz normale Zahlung von einer einzelnen Person.

Das klingt nach Kryptografie-Detail, hat aber handfeste Folgen für jeden, der Bitcoin selbst verwahrt, zu mehreren verwahrt oder für Kunden verwahrt. Multisig, also die Absicherung über mehrere Schlüssel, war vor Taproot teuer, gut sichtbar und ein Datenschutzproblem. Mit zwei Verfahren namens MuSig2 und FROST wird daraus ein Werkzeug, das kaum noch Spuren hinterlässt. Bei einem Bitcoin-Kurs von rund 71.600 Euro am 25. Oktober 2026 (CoinGecko), gut ein Drittel unter dem Allzeithoch von etwa 107.662 Euro aus dem Oktober 2025, ist die Frage, wer die Schlüssel hält und wie, wichtiger als jede Kursprognose.

Dieser Text erklärt, wie aus vielen Schlüsseln eine Signatur wird, welche Wallets das 2026 bereits können, wo die Fallstricke liegen und was BaFin, MiCA und das deutsche Steuerrecht dazu sagen. Es ist die Geschichte des Key-Pfads, nicht die der Token, die Taproot nebenbei ermöglicht hat.

Warum Multisig vor Taproot teuer und sichtbar war

Multisig gibt es in Bitcoin seit Langem. Eine 2-von-3-Wallet verlangt, dass zwei von drei Schlüsseln eine Ausgabe unterschreiben; das schützt vor einem verlorenen Gerät, vor einem einzelnen Dieb und vor dem eigenen Fehler. Umgesetzt wurde das über den Opcode OP_CHECKMULTISIG, verpackt in eine P2SH- und später eine P2WSH-Adresse (SegWit). Technisch funktioniert das bis heute.

Der Preis dafür war hoch, in jeder Hinsicht. Beim Ausgeben schrieb die Wallet alle beteiligten öffentlichen Schlüssel und die Regel (etwa zwei von drei) offen in die Transaktion. Jede Beobachterin konnte daran ablesen, dass hier kein einzelner Nutzer zahlt, sondern ein Tresor, eine Firma oder ein Gemeinschaftskonto. Chain-Analyse-Firmen nutzen genau solche Muster, um Adressen zu gruppieren. Zweitens kostete jeder zusätzliche Schlüssel Platz im Block und damit Gebühren; ein 3-von-5-Setup war spürbar teurer als eine einfache Zahlung. Drittens war das Ganze ein Datenschutzleck: Wer Multisig nutzte, verriet, dass er etwas zu schützen hatte.

Der tiefere Grund lag in der Signatur selbst. Bitcoin nutzte bis Taproot ECDSA, und ECDSA lässt sich nicht einfach zusammenrechnen. Es gibt zwar aufwendige Mehrparteien-Verfahren für ECDSA, doch im Protokoll blieb nur der Weg, jeden Schlüssel und jede Unterschrift einzeln aufzuführen. Multisig war also die sicherheitsbewusste Wahl, aber sie machte den Nutzer auf der Blockchain nackt und kostete ihn bei jeder Ausgabe extra.

Schnorr: die Mathematik hinter der Aggregation

Taproot brachte mit BIP 340 die Schnorr-Signatur nach Bitcoin, und damit eine Eigenschaft, die ECDSA fehlt: Linearität. Vereinfacht heißt das, man kann Signaturen und Schlüssel addieren. Die Spark-Research-Erklärung bringt es auf den Punkt: Addiert man zwei Schnorr-Signaturen für dieselbe Nachricht, erhält man eine gültige Signatur zur Summe der beiden öffentlichen Schlüssel (Spark).

Diese eine Eigenschaft ist der Hebel für alles Folgende. Weil sich Schlüssel addieren lassen, können mehrere Personen einen gemeinsamen öffentlichen Schlüssel berechnen, der genauso aussieht wie der Schlüssel einer einzelnen Person: 32 Byte lang, nicht von einem gewöhnlichen Schlüssel zu unterscheiden. Und sie können gemeinsam eine Signatur erzeugen, die zu diesem Schlüssel passt und ebenfalls die normale Größe von 64 Byte hat. Die Blockchain sieht am Ende einen Schlüssel und eine Signatur, egal ob eine Person oder fünf unterschrieben haben.

ECDSA konnte das nicht, weil ihm genau diese additive Struktur fehlt; ein naives Zusammenrechnen bricht die Sicherheitsgarantien. Deshalb musste altes Multisig jeden Schlüssel offenlegen, während Schnorr-Multisig ihn verstecken kann. Die beiden Protokolle, die diese Idee praktisch nutzbar machen, heißen MuSig2 und FROST. Bevor wir sie anschauen, lohnt ein kurzer Blick darauf, wie Taproot überhaupt zwischen sichtbarem und unsichtbarem Ausgeben unterscheidet.

Taproot in drei Bausteinen und zwei Wegen

Taproot besteht aus drei Bausteinen: BIP 340 (Schnorr-Signaturen, von Pieter Wuille, Jonas Nick und Tim Ruffing), BIP 341 (Taproot selbst, also der Ausgabetyp P2TR samt MAST, von Wuille, Nick und Anthony Towns) und BIP 342 (Tapscript, die Skriptsprache für den Zweigfall). Aktiviert wurde das Paket am 14. November 2021 bei Block 709.632, nachdem im Juni 2021 bei Block 687.284 über 90 Prozent der Miner signalisiert hatten; das Verfahren hieß Speedy Trial (CoinDesk). Taproot-Adressen beginnen mit bc1p, SegWit-Adressen mit bc1q.

Entscheidend für das Thema hier ist, dass eine Taproot-Ausgabe zwei Wege kennt, ausgegeben zu werden. Der Key-Pfad bedeutet: Man unterschreibt direkt mit dem Ausgabe-Schlüssel. Das ist der billigste und privateste Weg, denn auf der Blockchain erscheint nur ein Schlüssel und eine Signatur. Der Script-Pfad bedeutet: Man legt einen Zweig eines versteckten Skriptbaums (MAST) offen und erfüllt dessen Bedingung. Der Ausgabe-Schlüssel ist dabei der innere Schlüssel plus ein kleiner Zusatz, der den Skriptbaum einbindet, ohne ihn zu zeigen.

Der Clou: Der innere Schlüssel darf selbst schon eine Summe vieler Schlüssel sein. Dann ist der Key-Pfad das Multisig, und zwar unsichtbar. Wie breit Taproot sonst eingesetzt wird und warum sein On-Chain-Anteil trotzdem schrumpft, haben wir an anderer Stelle beleuchtet (siehe Taproot nach fünf Jahren); auch die Token-Welt aus Ordinals und Runes sitzt am Script-Pfad. Hier folgen wir konsequent dem Key-Pfad.

Drei Wege zum Multisig nach Taproot

Nach Taproot gibt es drei Arten, mehrere Schlüssel zu verlangen, und sie unterscheiden sich vor allem darin, wie viel sie verraten. Erstens das klassische Script-Multisig mit OP_CHECKMULTISIG in P2SH oder P2WSH, der Weg aus der Zeit vor Taproot; er funktioniert in nahezu jeder Wallet und braucht keine Abstimmung zwischen den Unterzeichnern, zeigt aber alles. Zweitens das Taproot-Script-Multisig: In Tapscript ist OP_CHECKMULTISIG deaktiviert, an seine Stelle tritt OP_CHECKSIGADD, das Signaturen einzeln zählt. Nutzt man einen solchen Skriptzweig, wird nur dieser eine Zweig sichtbar, ungenutzte Bedingungen bleiben verborgen. Drittens das Key-Pfad-Multisig über MuSig2 oder FROST, bei dem gar nichts von der Mehrparteien-Natur zu sehen ist.

Diese Tabelle ist das Gerüst des gesamten Artikels. Der Script-Pfad bleibt für alles unverzichtbar, was ungleiche Bedingungen braucht, etwa ein Zeitschloss, über das nach einem Jahr ein Ersatzschlüssel freigeschaltet wird. Der Key-Pfad dagegen ist die Antwort auf die Frage: Wie bekomme ich die Sicherheit von Multisig, ohne dass es jemand merkt und ohne Aufpreis bei der Gebühr?

MuSig2: n-von-n in einer einzigen Signatur

MuSig2 geht auf eine Arbeit von Jonas Nick, Tim Ruffing und Yannick Seurin aus dem Jahr 2020 zurück, veröffentlicht auf der Kryptografie-Konferenz CRYPTO 2021, und ist heute als BIP 327 standardisiert. Es ist ein n-von-n-Verfahren: Alle Unterzeichner müssen jedes Mal mitmachen. Der Fortschritt gegenüber dem Vorgänger MuSig war, dass statt drei nur noch zwei Kommunikationsrunden nötig sind.

Der Ablauf hat drei Schritte. Zuerst die Schlüssel-Aggregation: Jeder öffentliche Schlüssel wird mit einem Koeffizienten multipliziert, der aus dem Hash aller beteiligten Schlüssel entsteht. Das verhindert den sogenannten Rogue-Key-Angriff, bei dem ein böswilliger Teilnehmer seinen Schlüssel so wählt, dass er allein über das Konto verfügen könnte. In Runde eins tauschen die Unterzeichner öffentliche Nonces aus, je zwei pro Person; das kann sogar geschehen, bevor die zu unterschreibende Zahlung feststeht. In Runde zwei liefert jeder eine Teilsignatur, die zur gemeinsamen Nonce passt, und alle Teilsignaturen werden zu einer einzigen 64-Byte-Signatur addiert.

Ein wichtiger Vorteil: Die Schlüssel-Aggregation ist nicht interaktiv. Jeder Teilnehmer erzeugt einfach ein normales Schlüsselpaar, eine Zeremonie braucht es nicht. Das Ergebnis auf der Blockchain ist von einer gewöhnlichen Key-Pfad-Zahlung nicht zu unterscheiden. MuSig2 steckt bereits in der Referenzbibliothek libsecp256k1, in der Lightning-Software LND und in der Ledger-Hardware; es ist also kein Laborprojekt mehr.

Was das praktisch bedeutet, zeigt ein Firmenbeispiel. Eine 3-von-3-Kasse, bei der Geschäftsführung, Finanzabteilung und ein externer Treuhänder je einen Schlüssel halten, sieht nach außen aus wie eine gewöhnliche Privat-Wallet. Weder Wettbewerber noch Chain-Analyse-Firmen noch potenzielle Angreifer erkennen, dass hier ein Mehraugenprinzip greift. Der Schutz steigt, während die öffentlich sichtbare Angriffsfläche sinkt; genau diese Kombination war mit dem alten OP_CHECKMULTISIG unmöglich.

FROST und ChillDKG: Schwellenwert fürs echte Leben

MuSig2 hat eine harte Grenze: n-von-n heißt, fällt ein einziger Schlüssel aus, lässt sich nichts mehr bewegen. Für einen Tresor, der zwei von drei oder drei von fünf verlangt und bei dem einzelne Beteiligte offline sein dürfen, braucht es ein Schwellenwert-Verfahren. Genau das ist FROST, kurz für Flexible Round-Optimized Schnorr Threshold, ursprünglich von Chelsea Komlo und Ian Goldberg beschrieben.

FROST erlaubt, dass beliebige t von n Teilnehmern gemeinsam unterschreiben, während die übrigen nicht erreichbar sein müssen. Der Preis dafür ist eine einmalige, interaktive Schlüsselzeremonie, die verteilte Schlüsselerzeugung (Distributed Key Generation, DKG), bei der nie eine einzelne Partei den gesamten Schlüssel in der Hand hält. Ein Standard dafür heißt ChillDKG aus der Blockstream-Forschung. FROST kennt zudem identifizierbare Abbrüche: Liefert jemand eine ungültige Teilsignatur, lässt sich der Verursacher benennen. Die Standardisierung läuft über BIP 445 (die FROST3-Variante, als Entwurf seit Januar 2026, kompatibel mit Taproot), begleitet von einer auditierten Referenzimplementierung und der Spezifikation RFC 9591 von 2024 (bitcoin/bips PR 2070). In Produktion nutzt es bisher vor allem die Statechain-Lösung Spark für ihr Betreibermodell.

Ein greifbares Beispiel ist der klassische 2-von-3-Tresor. Mit FROST liegen drei Schlüsselanteile bei drei Personen oder Geräten; zwei beliebige davon genügen, um zu unterschreiben, der dritte darf verloren gehen oder offline bleiben. Auf der Blockchain bleibt davon nichts sichtbar, und anders als bei MuSig2 blockiert ein einzelner Ausfall nicht das ganze Konto. Der Preis ist die anfängliche Zeremonie, in der die Anteile erzeugt werden, ohne dass je ein vollständiger Schlüssel an einem Ort existiert.

Ein verwandtes Verfahren namens ROAST baut um FROST eine Robustheitsschicht, sodass t ehrliche Unterzeichner garantiert zu einer gültigen Signatur kommen, selbst wenn Störer das Netz bremsen; es bleibt bislang ein Forschungsprototyp. Die folgende Tabelle ordnet die Verfahren ein, inklusive des klassischen Script-Multisig und der institutionellen MPC-Verwahrung (Spark).

Die Nonce-Falle: der eine Fehler, der alles kostet

Aggregation ist nicht gratis. Sie erkauft Privatsphäre und niedrige Gebühren mit zwei Dingen: Die Unterzeichner müssen in zwei Runden miteinander reden, und sie müssen mit den Nonces extrem sorgfältig umgehen. Eine Nonce ist der frische Zufallswert, den jede Signatur braucht. Bei Schnorr gilt: Verwendet ein Unterzeichner dasselbe Nonce-Paar in zwei verschiedenen Sitzungen, lässt sich sein geheimer Schlüssel rein rechnerisch rekonstruieren (Spark). Nonce-Wiederverwendung ist also kein Schönheitsfehler, sondern der Totalverlust.

Deshalb ist MuSig2 zweirundig aufgebaut, und deshalb muss die Software oder Hardware garantieren, dass Nonces frisch sind, sicher gespeichert und danach gelöscht werden; vor allem darf sie sich nicht dazu verleiten lassen, Teile einer Sitzung unbemerkt zu wiederholen. Es gibt eine Variante mit deterministischen Nonces, MuSig-DN, die gegen diesen Wiederholungsangriff immun ist, aber deutlich aufwendiger zu bauen.

Genau diese Zustandsverwaltung erklärt, warum MuSig2 erst spät auf Hardware-Wallets ankam und warum manche Anbieter es vorsichtig einführen. Die Kryptografie ist elegant; die Buchführung über offene Sitzungen ist die eigentliche Ingenieursarbeit. Wer einen Chip baut, der niemals eine Nonce doppelt herausgibt, hat das schwierige Stück gelöst.

Wer MuSig2 und FROST 2026 schon ausliefert

Die erste große Hardware-Wallet mit MuSig2 war Ledger, eingeführt am 24. April 2025 mit Version 2.4.0 der Bitcoin-App. Bemerkenswert ist die Autorenschaft des Ankündigungstexts: Verfasst haben ihn der Bitcoin-Ingenieur Salvatore Ingala und der Kryptograf Yannick Seurin, einer der Erfinder von MuSig2, der inzwischen bei Ledger arbeitet. Mehrere Schlüssel würden, so die beiden, zu einem einzigen aggregierten Schlüssel verschmolzen, und eine Zahlung über diesen Schlüssel sei von jeder anderen Key-Pfad-Zahlung nicht zu unterscheiden; der zusätzliche Mitunterzeichner sei „totally invisible to people“ und das Verfahren fast ohne Interaktion nutzbar (Ledger). Die App kann bis zu acht solcher MuSig2-Transaktionen gleichzeitig unterschreiben.

Auf der Software-Seite bietet Nunchuk ein Taproot-Multisig an, das Schnorr, MuSig2 und Taproot kombiniert. Es nutzt einen Key-Pfad für den optimalen Schlüssel-Satz und den Script-Pfad als Rückfallebene. Taproot mache Multisig-Aktivität von Single-Sig auf der Blockchain ununterscheidbar, heißt es in der Dokumentation; Beobachter könnten nicht erkennen, wie viele Parteien beteiligt waren (Nunchuk). Allerdings ist die Funktion ausdrücklich Beta: vorerst nur mit Hot Keys statt Hardware, maximal fünf Schlüssel und mit zwei Signaturrunden; die Firma rät davon ab, größere Summen hineinzulegen, bis die Funktion reift. Im Lightning-Netzwerk wiederum nutzt LND MuSig2 für die neuen Taproot-Kanäle, deren Eröffnung und Schließung dadurch günstiger und unauffälliger werden.

So ermutigend das klingt: Key-Pfad-Aggregation ist 2026 noch die Ausnahme. Das meiste Multisig läuft weiter über klassisches Script-Multisig, weil es überall unterstützt wird und keine Abstimmung zwischen offline liegenden Schlüsseln verlangt. Wer seine Schlüssel selbst betreibt, weiß ohnehin, dass Souveränität Arbeit ist, ähnlich wie beim Solo-Staking am heimischen Validator; die unsichtbare Variante kommt, ist aber noch nicht überall.

Collaborative Custody: ein Schlüssel beim Anbieter

Zwischen vollständiger Selbstverwahrung und einem Verwahrer, der alles kontrolliert, liegt ein Mittelweg: die kollaborative Verwahrung. Dabei hält der Nutzer die Mehrheit der Schlüssel, während ein Dienstleister einen einzelnen Schlüssel als Notfallreserve verwahrt. Der Anbieter kann die Bitcoin niemals allein bewegen; er kann nur mitunterschreiben, wenn der Nutzer einen Schlüssel verliert oder Hilfe bei der Wiederherstellung braucht (Unchained).

Die Preise sind umgerechnete Richtwerte, denn die Anbieter rechnen in US-Dollar ab. Wichtig ist eine Einschränkung, die in den Marketingtexten gern untergeht: Die meisten dieser Dienste setzen bislang auf klassisches Script-Multisig, nicht auf MuSig2-Key-Pfad. Die Setups sind also sicher, aber auf der Blockchain als Multisig erkennbar. Die unsichtbare Variante ist der nächste Schritt, nicht der heutige Standard.

Für viele Privatanleger ist der eigentliche Gewinn nicht die Mehrfachsignatur an sich, sondern die geregelte Wiederherstellung. Geht ein Schlüssel verloren, springt der Anbieter als Mitunterzeichner ein, statt dass das gesamte Vermögen unerreichbar wird; einige Dienste koppeln daran eine Nachlassregelung, über die benannte Erben nach einem definierten Prozess Zugriff erhalten. Der Preis ist ein Stück Vertrauen und ein Stück Privatsphäre, denn der Anbieter kennt die Struktur des Tresors. Wer das nicht möchte, baut dasselbe mit offener Software wie Sparrow oder dem DIY-Zweig von Nunchuk selbst nach und bleibt alleiniger Herr über alle Schlüssel.

MuSig2, FROST oder doch klassisches Script-Multisig?

Welches Verfahren passt, hängt vom Bedrohungsmodell ab, nicht von der Mode. Key-Pfad-Aggregation lohnt sich, wenn Privatsphäre und niedrige Gebühren zählen und alle Unterzeichner koordiniert online sein können (MuSig2) oder wenn man einen Schwellenwert mit teils offline liegenden Schlüsseln braucht und die DKG-Zeremonie stemmen kann (FROST). Der Script-Pfad mit Miniscript ist die bessere Wahl, sobald ungleiche Bedingungen ins Spiel kommen: Zeitschlösser, ein nach Monaten freiwerdender Ersatzschlüssel, ein Erbe-Zweig, eine Wiederherstellung ohne Abstimmung. Und das schlichte Script-Multisig bleibt sinnvoll, wenn maximale Wallet-Kompatibilität und einfache Wiederherstellung wichtiger sind als Unauffälligkeit.

Dazu passt eine Warnung aus berufenem Munde. Ledger-Technikchef Charles Guillemet riet nach dem Coldcard-Vorfall im Sommer 2026 ausdrücklich davon ab, reflexartig auf Multisig umzusteigen; zusätzliche Komplexität schaffe neue Fehlerquellen, statt alte zu beseitigen. Als Mittelweg nannte er Miniscript, mit dem sich Erbregeln, zeitverzögerte Ersatzschlüssel und 2-von-3-Richtlinien abbilden lassen, ohne den vollen Aufwand eines klassischen Multisig; eine funktionierende Miniscript-Wallet habe er in wenigen Stunden gebaut. MuSig2 bezeichnete er als kryptografische Alternative, die mehrere Schlüssel zu einer Signatur bündelt, und verwies darauf, dass Ledger bislang die einzige Hardware mit dieser Funktion sei. Für die meisten Menschen aber bleibe eine gut gesicherte Single-Sig-Hardware-Wallet die praktischste Lösung (Cryptonomist). Aggregation ist ein Werkzeug, kein Upgrade, das man sich schuldet.

Das Problem, das Aggregation nicht löst: Blind Signing

MuSig2 macht die Signatur unsichtbar. Es prüft aber nicht, wohin die Bitcoin gehen. Die größten Multisig-Verluste der jüngeren Geschichte beruhten nicht auf gebrochener Kryptografie oder gestohlenen Schlüsseln, sondern darauf, dass Unterzeichner etwas anderes freigaben, als sie zu sehen glaubten. Beim Bybit-Diebstahl vom 21. Februar 2025, mit rund 1,3 Milliarden Euro der größte Krypto-Raub überhaupt, hatten Angreifer die Oberfläche der verwendeten Multisig-Software manipuliert; die Unterzeichner sahen eine harmlose Zahlung und signierten in Wahrheit die Übergabe der Kasse (The Block). Die Schlüssel waren nie kompromittiert; das Multisig funktionierte tadellos, nur eben an der falschen Transaktion.

Daran ändert Aggregation nichts. Weiterhin gilt: Man muss Ziel und Betrag auf einem Gerät prüfen, dem man vertraut (Clear Signing), außerhalb des Kanals bestätigen und verdächtige Vorgänge überwachen. Die Security Alliance (SEAL) fasst die operative Hygiene für Multisig in klaren Leitplanken zusammen (SEAL):

• Mindestens drei Unterzeichner und eine Schwelle von wenigstens der Hälfte; keine n-von-n-Konstruktion als einzige Absicherung.
• Ab Werten über einer Million Euro eher sieben oder mehr Schlüssel.
• Verschiedene Hardware-Modelle und -Hersteller, geografisch getrennt aufbewahrt, möglichst mit einem externen Mitunterzeichner.
• Immer die rohen Transaktionsdaten prüfen, nicht nur die hübsche Oberfläche.
• Verzögerungen (Timelocks) und aktive Überwachung einbauen, dazu eine Bestätigung über einen zweiten Kanal.

Ein feiner Nebeneffekt der Aggregation verdient Beachtung: Sie entfernt die Nachvollziehbarkeit auf der Kette. Beim Script-Multisig steht in der Transaktion, welche Schlüssel unterschrieben haben; bei MuSig2 steht das nicht mehr drin. Für die Privatsphäre ist das großartig, für Audits, Streitfälle oder den Nachweis, wer eine Firmenausgabe autorisiert hat, ist es unpraktisch. Wer Rechenschaft braucht, wählt bewusst den Script-Pfad.

BaFin, MiCA und die Frage der Verwahrung

Regulierer fassen das Protokoll nicht an. Ein Soft Fork wie Taproot oder ein Verfahren wie MuSig2 ist nichts, was die BaFin genehmigt oder blockiert. Was MiCA und die BaFin erfassen, sind Krypto-Dienstleister (CASPs) und Emittenten, nicht die Konsensregeln (BaFin). Die Kryptoverwahrung, also das Verwahren von Kundenvermögen, ist eine erlaubnispflichtige Dienstleistung; ein Anbieter mit kontrollierenden Schlüsseln fällt voll darunter, samt Haftungsregime nach MiCA-Artikel 75 und den Betriebsstabilitäts-Vorgaben der DORA-Verordnung.

Spannend ist der Grenzfall der kollaborativen Verwahrung, bei der ein Anbieter nur einen einzelnen, nicht kontrollierenden Schlüssel hält. Kann er die Mittel nicht allein bewegen, verwahrt er sie dann überhaupt im rechtlichen Sinn? Die Trennlinie ist die Verfügungsgewalt: Ein reiner Mitunterzeichner ohne Alleinzugriff ist argumentierbar keine Verwahrung, doch gerichtlich geklärt ist das in Deutschland nicht. Reine Selbstverwahrung über mehrere eigene Schlüssel liegt dagegen klar außerhalb von MiCA: kein CASP, kein Regulierer, keine Beschwerdestelle. Die eigenen Routinen sind die einzige Verteidigung. Das ist zugleich der Preis und der Sinn der Souveränität.

Praktisch heißt das für Anleger: Wer über eine Börse oder einen lizenzierten Verwahrer hält, hat im Schadensfall einen regulierten Ansprechpartner und ein Haftungsregime im Rücken, zahlt dafür aber mit Gegenparteirisiko. Wer selbst verwahrt, ob Single-Sig oder MuSig2, trägt das Risiko allein, gewinnt aber die volle Kontrolle. MuSig2 und FROST verschieben diese Abwägung nicht, sie machen nur die selbst getragene Variante sicherer und unauffälliger.

Steuer und Erbfall: Schlüssel tauschen ist kein Verkauf

Für deutsche Anleger stellt sich sofort die Steuerfrage. Private Veräußerungsgeschäfte mit Bitcoin fallen unter Paragraf 23 Einkommensteuergesetz, mit der bekannten Haltefrist von einem Jahr. Nach der vorherrschenden Auslegung ist das Verschieben eigener Coins zwischen eigenen Adressen oder Wallet-Typen, etwa von bc1q auf bc1p oder in ein Multisig, das man selbst kontrolliert, keine Veräußerung und setzt die Haltefrist nicht zurück, solange man die Verfügungsgewalt behält. Das Umziehen in ein unsichtbares MuSig2-Setup ist also steuerlich ein Nicht-Ereignis; wer rund um den Jahreswechsel umschichtet, sollte dennoch die Fristenlogik kennen, wie wir sie beim Bestandsschutz zum 31. Dezember beschrieben haben.

Heikler ist der Erbfall. Bitcoin gehört zum Nachlass und wird mit dem Wert zum Todeszeitpunkt der Erbschaftsteuer unterworfen; die Erben müssen aber erst einmal an die Schlüssel kommen. Ein reines n-von-n-MuSig2 ist dafür spröde: Fehlt ein einziger Mitunterzeichner, sind die Coins für immer gesperrt. Genau deshalb greifen Nachlasslösungen meist zum Script-Pfad mit Zeitschlössern, bei dem nach einer Frist ein Ersatz- oder Erbschlüssel allein ausgeben darf. Key-Pfad-Aggregation und zeitgesteuerte Vererbung sind also keine Konkurrenten, sondern die zwei Hälften dessen, was Taproot bietet.

Der Quanten-Vorbehalt

Ein Haken bleibt beim Key-Pfad. Weil der aggregierte öffentliche Schlüssel offen in der Ausgabe steht, ist eine MuSig2- oder FROST-Taproot-Ausgabe von Anfang an für einen hypothetischen Quantenangreifer exponiert, genau wie jede andere Key-Pfad-Zahlung. Forscher haben zuletzt gewarnt, dass leistungsfähige Quantencomputer Signaturverfahren eines Tages brechen könnten; Vorschläge für quantensichere Ausgabetypen existieren, sind aber nicht aktiviert und noch Zukunftsmusik. Für die nächsten Jahre ist das ein Horizontrisiko, kein Grund, auf die Vorteile der Aggregation zu verzichten. Wer sehr langfristig denkt, kann besonders große Bestände vorsichtshalber auf Adresstypen verteilen, die den Schlüssel erst beim Ausgeben zeigen.

Fazit: die leise Hälfte von Taproot

Taproot wird gern über seine lauten Kinder erzählt, über Ordinals, Runes und Rollups. Die ruhigere Geschichte ist die der Schlüssel. Schnorr hat es möglich gemacht, dass viele Unterschriften zu einer werden, und MuSig2 wie FROST machen daraus Werkzeuge, mit denen sich Sicherheit ohne Aufpreis und ohne Schaufenster bauen lässt. 2026 ist das noch die Ausnahme, nicht die Regel, aber die Richtung steht fest. Wer Bitcoin ernsthaft verwahrt, sollte verstehen, welchen der drei Wege er geht und warum, denn am Ende entscheidet nicht der Kurs über die eigene Souveränität, sondern die Frage, wer die Schlüssel hält.

Frequently Asked Questions

Was ist MuSig2 einfach erklärt?

MuSig2 (BIP 327) ist ein Verfahren, mit dem mehrere Personen gemeinsam eine einzige Bitcoin-Signatur erzeugen. Dank Taproot und Schnorr sieht diese Signatur auf der Blockchain aus wie die einer einzelnen Person, obwohl mehrere Schlüssel beteiligt waren.

Was ist der Unterschied zwischen MuSig2 und FROST?

MuSig2 ist ein n-von-n-Verfahren, bei dem jeder Schlüssel jedes Mal mitsignieren muss. FROST erlaubt t-von-n, also etwa drei von fünf Schlüsseln, sodass einzelne Mitunterzeichner offline sein dürfen; dafür verlangt FROST eine einmalige Schlüsselzeremonie.

Sieht man Taproot-Multisig auf der Blockchain?

Beim Key-Pfad mit MuSig2 oder FROST nicht; eine solche Zahlung ist von einer gewöhnlichen Single-Sig-Transaktion nicht zu unterscheiden. Nur wenn der Script-Pfad genutzt wird, wird der jeweils verwendete Zweig sichtbar.

Welche Wallets unterstützen MuSig2 im Jahr 2026?

Ledger führte MuSig2 im April 2025 mit Version 2.4.0 der Bitcoin-App ein und ist bislang die einzige große Hardware-Wallet mit dieser Funktion. Nunchuk bietet ein Taproot-Multisig als Beta an, und die Lightning-Software LND nutzt MuSig2 für die neuen Taproot-Kanäle.

Ist Bitcoin-Multisig in Deutschland reguliert?

Das Bitcoin-Protokoll und Verfahren wie MuSig2 sind nicht reguliert. MiCA und die BaFin erfassen Krypto-Dienstleister, die Kundenvermögen verwahren; reine Selbstverwahrung über mehrere eigene Schlüssel fällt nicht darunter.

Marcus Okafor schreibt für HOGE Wire über Bitcoin, Selbstverwahrung und die Technik hinter dem Protokoll.