Taproot komplett erklärt: Von Schnorr-Signaturen bis Citrea

Am 14. November 2021 aktivierte das Bitcoin-Netzwerk kurz nach 05:15 UTC das bislang letzte große Konsens-Upgrade seines Protokolls: Taproot. Fast fünf Jahre später ist aus der damaligen Fachdiskussion über Schnorr-Signaturen und Merkle-Bäume die unsichtbare Grundlage für einen wachsenden Teil dessen geworden, was auf Bitcoin passiert, von privaten Multisig-Wallets über Ordinals und Runes bis zu neuen Rollup-Konstruktionen wie Citrea. Dieser Artikel ordnet ein, wie Taproot technisch funktioniert, wie weit die Adoption Mitte 2026 tatsächlich ist und warum sich Entwickler gerade wieder heftig über Bitcoins nächsten Schritt streiten. Wer selbst Bitcoin hält, kann direkt anhand des Adressformats erkennen, ob eine eigene oder fremde Adresse bereits auf Taproot setzt, ein guter Ausgangspunkt für alles, was danach folgt.

Was ist Taproot? Die Kurzfassung

Taproot ist kein einzelnes Feature, sondern ein Bündel aus drei zusammenhängenden Bitcoin Improvement Proposals (BIPs), die am 14. November 2021 im Block 709.632 gemeinsam aktiviert wurden, wie unter anderem CoinDesk zur Aktivierung berichtete. Im Kern löst Taproot ein einfaches Problem: Komplexe Ausgabebedingungen wie Mehrfachsignaturen oder Zeitschlösser sollen auf der Blockchain möglichst genauso aussehen wie eine simple Standardzahlung, günstiger in der Gebühr und ohne unnötige Informationen preiszugeben. Die drei BIPs im Überblick:

• BIP 340 (Schnorr-Signaturen): definiert ein neues, lineares Signaturschema als Ersatz für ECDSA. Autoren: Pieter Wuille, Jonas Nick, Tim Ruffing.
• BIP 341 (Taproot / MAST): definiert das Ausgabeformat Pay-to-Taproot (P2TR) und die Struktur der Merkleized Alternative Script Trees. Autoren: Wuille, Nick, Anthony Towns.
• BIP 342 (Tapscript): definiert die aktualisierte Skriptsprache für den Script Path. Gleiche Autoren wie BIP 341.

Zusammengenommen ersetzen diese drei BIPs weder Bitcoins Konsensregeln zur Geldmenge noch die grundsätzliche Blockstruktur, sie verändern ausschließlich, wie einzelne Ausgaben kryptografisch abgesichert und ausgegeben werden können, eine bewusst eng begrenzte Änderung, die die spätere Zustimmung der Miner erheblich erleichterte. Nach außen erkennbar ist eine Taproot-Ausgabe an ihrem Adresspräfix bc1p, im Unterschied zu bc1q bei SegWit-Adressen oder der führenden 1 bei klassischen Legacy-Adressen. Die technische Spezifikation selbst liegt offen im bitcoin/bips-Repository auf GitHub.

Das Problem vor Taproot: Sichtbarkeit und Ineffizienz

Vor Taproot verrieten komplexere Bitcoin-Adressen auf der Blockchain fast immer, was in ihnen steckte. Eine 2-von-3-Multisig-Adresse mit dem klassischen OP_CHECKMULTISIG-Opcode musste beim Ausgeben alle drei öffentlichen Schlüssel und das vollständige Skript offenlegen, unabhängig davon, ob es sich um ein Firmen-Treasury, ein Börsen-Cold-Wallet oder eine private Erbschaftsregelung handelte. Für Ermittler, Steuerbehörden oder schlicht neugierige Blockchain-Beobachter war das ein Segen, für Nutzer mit einem legitimen Interesse an Diskretion, etwa Unternehmen, die ihre Treasury-Struktur nicht offenlegen wollten, ein strukturelles Problem. Das hatte drei Nachteile. Erstens Kosten: Jedes zusätzliche Signaturfeld vergrößert die Transaktion in Byte und damit die Gebühr. Zweitens Privatsphäre: Beobachter der Blockchain konnten allein am Transaktionsmuster ablesen, welche Wallet-Software oder welches Sicherheitsmodell jemand nutzt, ein Fingerabdruck, der sich für gezielte Angriffe ausnutzen lässt. Drittens ein kryptografisches Problem: Das bis dahin verwendete ECDSA-Signaturverfahren ist nicht linear, mehrere Signaturen lassen sich nicht einfach mathematisch zu einer einzigen kombinieren. Genau an diesem dritten Punkt setzt Schnorr an. Ein plastisches Beispiel für die Folgen lieferte schon in den früheren 2010er-Jahren die sogenannte Transaktionsmalleabilität, bei der sich die Transaktions-ID durch geringfügige Änderungen an einer Signatur verändern ließ, ohne die eigentliche Zahlung ungültig zu machen, ein Problem, das SegWit 2017 strukturell entschärfte und das mit den festen, deterministischen 64-Byte-Signaturen aus BIP 340 endgültig an Relevanz verlor. Auch die Idee, Skriptbedingungen in einem Baum zu verstecken, ist älter als Taproot selbst: Bereits 2016 und 2017 schlug der Entwickler Johnson Lau mit den BIPs 114, 116 und 117 frühe MAST-Varianten vor, die technisch noch nicht mit Schnorr-Signaturen kombiniert waren und sich in der Praxis nicht durchsetzten. Erst die Verschmelzung beider Ideen, Schnorr-Signaturen und Baumstruktur, in einem einzigen, aufeinander abgestimmten Vorschlag machte Taproot ab 2018 zu einem mehrheitsfähigen Kandidaten.

Schnorr-Signaturen: Warum Linearität alles verändert

BIP 340 ersetzt ECDSA im Taproot-Kontext durch Schnorr-Signaturen, benannt nach dem deutschen Mathematiker Claus-Peter Schnorr, dessen Verfahren lange patentgeschützt war, das Patent aber bereits vor der eigentlichen Taproot-Entwicklung auslief. Dass Bitcoin dennoch bis 2021 auf das ältere, patentfreie ECDSA setzte, lag weniger an rechtlichen als an praktischen Gründen: ECDSA war 2009 bereits gut getestete Standardtechnologie, während Schnorr-Signaturen erst nach Jahren öffentlicher Forschung, unter anderem am Blockstream-Forschungsteam um Pieter Wuille, so weit ausgereift waren, dass eine Konsensänderung vertretbar erschien. Der entscheidende Vorteil ist Linearität: Mehrere Schnorr-Signaturen und die dazugehörigen öffentlichen Schlüssel lassen sich mathematisch zu einer einzigen Signatur und einem einzigen Schlüssel aggregieren, ohne dass eine Partei die privaten Schlüssel der anderen kennen muss. Der mathematische Grund: Eine ECDSA-Signatur enthält einen Term, bei dem eine Zufallszahl invertiert werden muss, eine Operation, die sich nicht verlustfrei über mehrere Teilnehmer hinweg addieren lässt. Schnorr-Signaturen kommen dagegen ohne diese Inversion aus, weshalb sich mehrere Signaturen einfach durch Addition kombinieren lassen, mathematisch der Kern von MuSig2 und verwandten Verfahren. Genau diese Eigenschaft macht Protokolle wie MuSig2 (dazu später mehr) überhaupt erst praktikabel, wobei die Sicherheit der Aggregation selbst über Jahre kryptografischer Begutachtung nachgewiesen wurde, bevor BIP 340 als aktivierungsreif galt. Ein weiterer, unscheinbarerer Vorteil: Schnorr-Signaturen haben eine feste Größe von 64 Byte, während klassische DER-kodierte ECDSA-Signaturen zwischen 71 und 73 Byte variieren, ein kleiner Unterschied, der sich über Millionen Transaktionen zu spürbaren Netzwerk- und Gebühreneinsparungen summiert.

MAST: Wie ein Merkle-Baum unnötige Daten verbirgt

BIP 341 führt zusätzlich zur Schnorr-Signatur das Konzept Merkleized Alternative Script Trees ein, kurz MAST. Die Grundidee: Statt alle denkbaren Ausgabebedingungen einer Adresse in ein einziges, immer vollständig sichtbares Skript zu packen, werden sie als einzelne Blätter in einen Merkle-Baum gehängt. Nur die Wurzel dieses Baums, ein einzelner 32-Byte-Hash, landet in der öffentlichen Adresse. Eine Wallet könnte zum Beispiel drei Bedingungen definieren: ein 2-von-2-Multisig für den Alltag, ein 3-von-5-Backup-Schema für den Notfall und ein Zeitschloss, das nach zwei Jahren Inaktivität einem Erben Zugriff gewährt. Ohne MAST müssten alle drei Zweige bei jeder Ausgabe offengelegt werden. Mit MAST bleibt beim Ausgeben nur der tatsächlich genutzte Zweig plus ein kryptografischer Nachweis (der Merkle-Pfad) sichtbar, die beiden ungenutzten Zweige bleiben für immer verborgen. Das reduziert sowohl die Transaktionsgröße als auch die Menge an Information, die ein Beobachter über die Sicherheitsarchitektur einer Wallet gewinnen kann. Kryptografisch ist die Wahl eines Merkle-Baums dabei kein Zufall: Die Größe des Nachweises wächst nur logarithmisch mit der Zahl der Blätter, selbst eine Adresse mit hundert alternativen Ausgabebedingungen benötigt beim Ausgeben nur wenige zusätzliche Hash-Werte, nicht hundert vollständige Skripte.

Key Path und Script Path: Eine Taproot-Transaktion im Detail

Technisch verschmilzt Taproot die Schnorr-Signatur und den MAST-Baum zu einem einzigen öffentlichen Schlüssel Q. Dieser ergibt sich aus einem internen Schlüssel P, der mit einem Hash aus P und der Merkle-Wurzel des Skriptbaums verrechnet (getweakt) wird. Nach außen ist Q ein ganz gewöhnlich aussehender Punkt, nichts an ihm verrät, ob überhaupt ein Skriptbaum dahintersteckt. Daraus ergeben sich zwei Wege, eine Taproot-Ausgabe zu verwenden. Der Key Path ist der Normalfall: Alle Beteiligten kooperieren, erzeugen gemeinsam (etwa via MuSig2) eine einzige Schnorr-Signatur für den getweakten Schlüssel Q, und die Transaktion sieht auf der Blockchain exakt so aus wie eine simple Ein-Signatur-Zahlung, ganz ohne Hinweis auf ein möglicherweise sehr komplexes Regelwerk im Hintergrund. Der Script Path ist der Ausweichpfad: Funktioniert die Kooperation nicht, etwa weil ein Signer nicht erreichbar ist, wird stattdessen das passende Skriptblatt, der zugehörige Kontrollblock und der Merkle-Nachweis offengelegt und ausgeführt. Aus Sicht von Minern und Mempool ist eine Key-Path-Ausgabe zudem einfacher zu validieren als ein komplexer Script Path, was in der Praxis leicht niedrigere Grenzkosten für die Validierung bedeutet, ein Detail, das in Diskussionen um Bitcoins langfristige Skalierung gelegentlich übersehen wird. Praktisch bedeutet das: Selbst wer alle Transaktionen einer Adresse über Jahre verfolgt, kann nicht unterscheiden, ob dahinter eine simple Ein-Personen-Wallet oder ein aufwendig abgesichertes Firmen-Treasury mit mehreren Backup-Ebenen steckt, solange nur der Key Path genutzt wird. Für Fälle, in denen gar kein sinnvoller Key Path existieren soll, etwa bei reinen Skript-Konstruktionen, definiert BIP 341 zusätzlich einen sogenannten NUMS-Punkt (Nothing-Up-My-Sleeve): einen Schlüssel, der nachweislich aus einer öffentlich nachvollziehbaren Konstante abgeleitet ist und für den niemand einen privaten Schlüssel kennen kann, was ausschließt, dass der Key Path heimlich als Hintertür missbraucht wird. Für Endnutzer sichtbar wird der Unterschied vor allem am Adressformat: Taproot-Adressen nutzen die Bech32m-Kodierung aus BIP 350 und beginnen mit bc1p, während SegWit-Adressen (Bech32, BIP 173) mit bc1q beginnen.

Tapscript: Bitcoins erweiterte Skriptsprache

Wird der Script Path genutzt, kommt die in BIP 342 definierte Skriptsprache Tapscript zum Einsatz, technisch als eigene Leaf-Version (0xc0) im Skriptbaum markiert. Tapscript ersetzt den alten OP_CHECKMULTISIG-Opcode durch OP_CHECKSIGADD, eine sauberere und recheneffizientere Art, mehrere Signaturen gegen mehrere Schlüssel zu prüfen. Zusätzlich lockert Tapscript einige historische Beschränkungen wie die alte Obergrenze für die Zahl der Opcodes pro Skript, was komplexere Konstruktionen praktikabler macht und Wallet-Implementierungen insgesamt weniger Sonderfälle beschert. Wichtiger für die Zukunft ist aber eine andere Designentscheidung: Tapscript reserviert eine ganze Reihe bislang ungültiger Opcodes als sogenannte OP_SUCCESS-Codes. Praktisch bedeutet das, künftige Skript-Erweiterungen lassen sich per Soft Fork aktivieren, ohne dass dafür wieder ein komplett neues Adressformat nötig wäre. Genau über diese Tür sollen Vorschläge wie OP_CTV oder OP_CAT später einziehen, dazu weiter unten mehr.

Speedy Trial: Wie Bitcoin 2021 den letzten großen Streit vermied

Die Aktivierung von Taproot verlief bewusst anders als der sogenannte Blocksize War der Jahre 2015 bis 2017, der schließlich zur Abspaltung von Bitcoin Cash führte. Damals hatten Teile der Community sogar mit einem User Activated Soft Fork (UASF) gedroht, einem Mechanismus, bei dem Nutzer und Node-Betreiber ein Upgrade notfalls auch gegen den Willen der Miner-Mehrheit durchsetzen. Für Taproot einigten sich Entwickler und Miner auf einen Mechanismus namens Speedy Trial: ein vergleichsweise kurzes, rund dreimonatiges Signalisierungsfenster, in dem Miner in ihren Blöcken Zustimmung markieren konnten. Weil Taproot als reines Effizienz- und Privatsphäre-Upgrade ohne kontroverse Auswirkung auf Bitcoins Geldpolitik oder Blockgröße galt, verlief die Signalisierung praktisch reibungslos: Das Lock-in erfolgte am 12. Juni 2021 im Block 687.284 mit über 90 Prozent Zustimmung der Hashrate, die eigentliche Aktivierung folgte turnusgemäß gut fünf Monate später am 14. November 2021. Dass eine derart tiefgreifende Änderung an Bitcoins Kryptografie am Ende so unspektakulär verlief, gilt in der Community bis heute als Beleg dafür, dass technische Qualität allein nicht ausreicht, ein Konsensverfahren muss auch politisch tragfähig sein, eine Lektion, die die aktuelle Covenant-Debatte prägt. Dass Miner überhaupt in dieser Form abstimmen, hängt eng mit ihren wirtschaftlichen Anreizen zusammen; wie eng die Margen im Mining-Geschäft mittlerweile kalkuliert sind, zeigt unsere Analyse zu Bitcoins Mining-Margen 2026. Wie der Abschnitt zur Covenant-Debatte weiter unten zeigt, ist diese Art von reibungsloser Einigkeit 2026 bei neuen Vorschlägen wie OP_CTV keineswegs mehr selbstverständlich.

Adoption in Zahlen: Von der Nische zum Alltagswerkzeug

Direkt nach der Aktivierung 2021 blieb die Nutzung von Taproot zunächst gering, viele Wallets und Börsen brauchten Zeit für die Integration. Einen ersten großen Schub brachten ab 2023 Ordinals und ab April 2024 Runes (siehe unten), die Taproots Skriptraum für die Speicherung beliebiger Daten nutzten und den Taproot-Transaktionsanteil laut Glassnode-Daten zeitweise auf über 40 Prozent trieben. Mit dem Abkühlen der reinen Inschriften-Spekulation sank der Anteil wieder, lag Anfang 2026 aber weiterhin bei rund 15 bis 20 Prozent, nun stärker getragen von organischer Wallet- und Protokoll-Nutzung als von kurzfristiger Spekulation. Zum Vergleich: Mindestens ein SegWit-Input steckt inzwischen in rund 85 bis 90 Prozent aller Transaktionen, SegWit bleibt also der mit Abstand dominante Adresstyp. Auf der Wallet-Seite ist die Unterstützung inzwischen praktisch flächendeckend: Bitcoin Core selbst unterstützt Taproot-Deskriptoren nativ in seiner eigenen Wallet, Hardware-Wallets wie Ledger und Trezor bieten den Adresstyp vollständig an, und auch leichtgewichtige Wallets wie Sparrow oder BlueWallet stellen bc1p-Adressen als Option bereit. Größere Handelsplätze zogen beim Auszahlungspfad tendenziell langsamer nach, was mit ein Grund dafür ist, warum die Adoption über die Jahre eher schrittweise als sprunghaft verlief. Eine ausführlichere Fünf-Jahres-Bilanz mit weiteren Kennzahlen haben wir in Taproot fünf Jahre später zusammengefasst.

MuSig2 und FROST: Multisig wird unsichtbar und günstig

BIP 327 (MuSig2) übersetzt die Linearität von Schnorr-Signaturen in ein praktisches Protokoll: Mehrere Teilnehmer erzeugen gemeinsam einen einzigen öffentlichen Schlüssel und, beim Signieren, eine einzige Signatur, ohne dass nach außen erkennbar wird, wie viele Parteien beteiligt waren. Ein Praxisbericht von BitGo beziffert den Effekt konkret: Ein MuSig2-Key-Path-Input kommt auf rund 57,5 virtuelle Byte, verglichen mit 104,5 vByte für natives SegWit-Multisig und 107,5 vByte für die Taproot-Script-Path-Alternative, macht eine Gebührenersparnis von rund 45 Prozent gegenüber klassischem Multisig. BitGos Beitrag zur finalen BIP-327-Spezifikation war zudem die Erkenntnis, dass allein der letzte Unterzeichner einer Runde eine deterministische Nonce verwenden kann, was stateless Signieren über Hardware-Sicherheitsmodule praktikabel macht. MuSig2 selbst benötigt für eine vollständige Signatur zwei Kommunikationsrunden zwischen den Teilnehmern: In der ersten tauschen alle Beteiligten Nonce-Commitments aus, erst in der zweiten die eigentlichen Teilsignaturen, ein bewusster Kompromiss zwischen Interaktivität und Sicherheit gegenüber älteren, verwundbareren Multisignatur-Ansätzen. Wallets und Dienste, die MuSig2 mittlerweile einsetzen, reichen von Ledgers Bitcoin-App (Version 2.4.0, April 2025) über BitGo und Nunchuk bis zu LND, wo Taproot-Kanäle Multisig-Funding standardmäßig per MuSig2 abwickeln. Für Nutzer heißt das konkret: Ein 3-von-5-Firmen-Multisig über Nunchuk und ein 2-von-2-Zahlungskanal über LND erzeugen auf der Blockchain exakt dieselbe Signaturgröße wie eine einzelne Privatperson, die von ihrer Handy-Wallet aus Kaffee bezahlt. FROST (Flexible Round-Optimized Schnorr Threshold Signatures), das echte t-von-n-Schwellenwertsignaturen ermöglicht, steckt dagegen noch früher in der Standardisierung: Eine konkrete Variante wurde erst im Januar 2026 als Entwurf BIP 445 zugewiesen, produktiv im Einsatz ist das Verfahren bislang vor allem im Betreiber-Schwellenwertmodell des Bitcoin-Layers Spark. Was diese Signaturaggregation für Nutzer konkret bedeutet, brachte Jameson Lopp, CTO des Selbstverwahrungs-Anbieters Casa, auf den Punkt: Wallets müssten „nicht mehr offenlegen, welche Schlüssel beteiligt waren“ und könnten sich so „in der Masse verstecken“. Eine dritte Anwendung der Schnorr-Linearität, neben MuSig2 und FROST, sind sogenannte Adaptor-Signaturen, wie sie Discreet Log Contracts (DLCs) zugrunde liegen: Zwei Parteien können damit eine Wette auf einen externen Orakel-Wert abschließen, ohne dass der Vertrag oder das Orakel-Ergebnis als separates on-chain-Skript sichtbar wird, die Auszahlung sieht am Ende wieder wie eine normale Taproot-Transaktion aus. DLCs bleiben 2026 eine Nische im Vergleich zu MuSig2, gelten unter Bitcoin-Entwicklern aber als eines der saubersten Beispiele dafür, wie viel Funktionalität sich allein aus der Linearität von Schnorr-Signaturen ableiten lässt, ganz ohne neue Opcodes oder Soft Forks.

Ordinals und Runes: Taproots ungeplante Killer-Applikation

Kaum jemand, der 2021 an Taproot mitarbeitete, plante das Upgrade als Grundlage für digitale Sammelobjekte. Doch genau das geschah: Im Januar 2023 startete Entwickler Casey Rodarmor das Ordinals-Protokoll, das beliebige Daten wie Bilder, Text oder kleine Programme über den erweiterten Witness-Bereich von Tapscript direkt in einzelne Satoshis einschreibt. Im April 2024, am Tag des vierten Halvings, folgte von demselben Entwickler Runes, ein schlankeres Fungible-Token-Format, das Zustände nativ im UTXO-Modell statt als Text innerhalb von Inschriften speichert und dadurch weniger UTXOs verschwendet als das ältere BRC-20-Format. BRC-20, das erste experimentelle Fungible-Token-Format auf Basis von Ordinals, kodierte Zustände noch als reinen Text innerhalb einzelner Inschriften und erforderte aufwendiges externes Indexieren, einen Umweg, den Runes durch die native UTXO-Integration von vornherein vermeidet. Die Größenordnung ist mittlerweile beachtlich: Tracker wie Dune und Ordiscan zählten bis Januar 2026 über 107 Millionen Inschriften, allein im vierten Quartal 2025 kamen mehr als 7,7 Millionen hinzu, und das, obwohl der Bitcoin-Kurs im selben Zeitraum um rund 23 Prozent fiel, ein Hinweis darauf, dass die Nutzung inzwischen weniger rein spekulativ getrieben ist als beim ersten Boom. Technisch macht das vor allem der Witness-Rabatt aus SegWit und Taproot möglich: Daten im Witness-Bereich einer Transaktion zählen für die Gebührenberechnung nur zu einem Bruchteil ihres eigentlichen Gewichts, was das Einschreiben größerer Dateien relativ günstig macht und genau der Mechanismus ist, über den die BIP-110-Debatte weiter unten geführt wird. Kritiker dieser Nutzung verweisen darauf, dass der eigentliche Zweck des Rabatts die Förderung von Signaturdaten war, nicht beliebiger Nutzdaten, Befürworter halten dagegen, dass ein UTXO-basiertes System grundsätzlich nicht zwischen beiden Datentypen unterscheiden kann, ohne die Zensurresistenz des Netzwerks insgesamt infrage zu stellen. Steuerlich ist das für deutsche Halter keineswegs trivial: Ob eine Inschrift eher wie ein NFT oder wie ein gewöhnliches Fungible Token zu behandeln ist, gehört zu den ungeklärten Fragen, die wir in DeFi- und NFT-Steuern in Deutschland ausführlicher einordnen. Der Grundsatzstreit, ob Bitcoin überhaupt für solche Anwendungsfälle da sein soll, ist 2026 keineswegs beigelegt: Anfang Juli näherte sich mit BIP-110 (offiziell „Reduced Data Temporary Soft Fork“, nicht zu verwechseln mit den Covenant-Vorschlägen im nächsten Abschnitt) eine Frist zur Begrenzung von OP_RETURN-Daten und bestimmten datenlastigen Skriptformaten, laut CoinDesk bei praktisch null Miner-Unterstützung. Strategy-Gründer Michael Saylor warnte, der Vorschlag „verwandle einen Spam-Streit in eine Konsensänderung“, während Blockstream-Mitgründer Adam Back Gegner auf eine eigene Fork verwies: „Bitcoin sagt respektvoll Nein zu dem, was du willst.“

Die Covenant-Debatte: OP_CTV, OP_CAT und der Streit um Bitcoins Zukunft

Ein Covenant schränkt ein, wie ein Coin in Zukunft ausgegeben werden darf, etwa nur an eine vorab festgelegte Adresse oder erst nach einer bestimmten Bedingung. Solche Konstruktionen könnten Vaults (Coins, die bei Diebstahl automatisch in ein Sicherheitsschema zurückfallen), effizientere Kongestionskontrolle oder nicht-custodiale Pool-Konstruktionen ermöglichen, klassische Anwendungsfälle, die auf Ethereum längst über Smart Contracts laufen und auf Bitcoin bislang fehlen. Wie eine Analyse von BlockEden im April 2026 zusammenfasste, konkurrieren dafür mehrere Vorschläge, von denen keiner wirklich neu erfunden ist: Jeremy Rubin veröffentlichte einen ersten CTV-Entwurf bereits 2019, lange vor der heutigen Aktivierungsdiskussion, und auch die Grundidee von Covenants reicht in Bitcoin-Fachdiskussionen bis in die frühen 2010er-Jahre zurück. Was sich 2026 geändert hat, ist weniger die Technik als die Bereitschaft eines Teils der Miner- und Entwicklerlandschaft, überhaupt wieder über eine Aktivierung zu sprechen:

Am weitesten fortgeschritten ist OP_CTV: Ein Aktivierungsclient mit konkreten Parametern (90 Prozent Miner-Zustimmung, 1.815 von 2.016 Blöcken) ist seit Februar 2026 veröffentlicht, die Signalisierung begann am 30. März 2026 mit einem ein Jahr späteren Timeout. Ob die nötige Schwelle erreicht wird, ist offen, Monitoring-Dashboards zeigten über weite Strecken des Frühjahrs 2026 kaum messbare Unterstützung. OP_CAT gilt technisch als mächtiger, weil es in Kombination mit Schnorr auch rekursive, zustandsbehaftete Covenants ermöglicht, wirft damit aber auch mehr Fragen zur Fungibilität auf und hat bislang keinerlei Aktivierungsfahrplan. Auch das verbreitete Argument, Covenants seien vor allem für institutionelle Nutzer relevant, etwa für Verwahrer, die Vaults für Kundengelder bauen wollen, ist Teil dieser älteren Debatte und keine Erfindung des Jahres 2026. Kritiker beider Vorschläge vertreten eine Position, die in der Szene häufig als Ossifikationismus bezeichnet wird: Bitcoin solle als möglichst stabiles, unveränderliches Geldprotokoll gelten und Änderungen nur in absoluten Ausnahmefällen zulassen. Andrew Poelstra von Blockstream, selbst Mitautor mehrerer Taproot-BIPs, widersprach dem 2026 öffentlich und verwies auf Ordinals als Beleg, dass Bitcoin sich ohnehin längst weiterentwickle; Entwickler müssten laut seinen in der Bitcoin Magazine zitierten Worten „leidenschaftlich und korrekt“ für sinnvolle Änderungen argumentieren.

Citrea und BitVM2: Wird Taproot zum Fundament für Bitcoin-Rollups?

Der vielleicht überraschendste Nebeneffekt von Taproot ist keine neue Opcode-Debatte, sondern eine ganz neue Kategorie von Bitcoin-Layer-2-Netzwerken. Die Konstruktion BitVM2 braucht, anders als OP_CTV oder OP_CAT, überhaupt keinen weiteren Soft Fork; sie kombiniert Taproots Tapscript mit sogenannten Bit-Commitments und optimistischen Challenge-Response-Beweisen, bei denen im Streitfall ein einziger ehrlicher Teilnehmer ausreicht, um Betrug aufzudecken. Das baut auf einem 2023 von Robin Linus veröffentlichten Konzept namens BitVM auf, dessen erste Version noch voraussetzte, dass alle möglichen Verifizierer von vornherein feststehen. BitVM2 hebt genau diese Einschränkung auf und erlaubt es im Prinzip jedem, zur Laufzeit als Verifizierer aufzutreten, ein Unterschied, der die Konstruktion erst praxistauglich für offene, permissionless Bridges wie Clementine machte. Auf dieser Grundlage aktivierte Citrea am 27. Januar 2026 nach Angaben von The Block sein Mainnet, nach eigener Darstellung der erste produktive ZK-Rollup, der direkt auf Bitcoin abrechnet. Technisch nutzt Citrea ein zkEVM auf Basis von RISC Zero, dessen STARK-Beweise für die On-Chain-Verifikation zu kompakteren Groth16-Beweisen komprimiert werden, dazu eine Bridge namens Clementine, die dank BitVM2 mit einem vergleichsweise schwachen 1-von-N-Vertrauensmodell auskommt, es genügt ein einziger ehrlicher Teilnehmer unter den Bridge-Betreibern. Zum Start standen mehr als 30 dApps sowie ein Stablecoin namens ctUSD bereit, unterstützt von Investoren wie Founders Fund, Galaxy und Maven11. Dass hier sowohl klassisches Risikokapital als auch krypto-native Investoren gemeinsam einsteigen, liest die Szene als Signal dafür, dass Bitcoin-Rollups 2026 nicht mehr nur ein Nischenexperiment für Bitcoin-Maximalisten sind, sondern zunehmend als eigene Anlagekategorie wahrgenommen werden. Die zugrunde liegenden Beweissysteme, STARKs, Groth16-Kompression und die Frage, wem in solchen Konstruktionen tatsächlich zu trauen ist, behandeln wir grundsätzlicher in Verifiable Compute: Wie Krypto KI-Rechenleistung beweisbar macht. Ergänzend arbeiten mehrere kleinere Teams an eigenen BitVM2-Anwendungen jenseits von Citrea, etwa für spezialisierte Bridges einzelner Stablecoin-Emittenten, auch wenn Citrea bislang das mit Abstand am weitesten fortgeschrittene Projekt in dieser Kategorie ist. Ob sich Citreas Ansatz gegenüber älteren, stärker föderierten Bitcoin-Sidechains durchsetzt, dürfte 2026 eine der spannendsten Nebenfragen der gesamten Taproot-Geschichte bleiben.

Regulatorischer Rahmen: Was BaFin und MiCA mit Taproot zu tun haben

Für deutsche Leser lohnt sich eine Klarstellung: Weder die BaFin noch die europäische MiCA-Verordnung regulieren das Bitcoin-Protokoll oder dessen Konsensmechanismus selbst. MiCA adressiert Krypto-Dienstleister (CASPs) und Emittenten bestimmter Token, ein Soft Fork wie Taproot oder eine mögliche künftige Aktivierung von BIP-360 ist dagegen keine Maßnahme, die irgendeine Behörde genehmigen, verbieten oder auch nur kommentieren müsste, das Protokoll entwickelt sich über offene, dezentrale Signalisierung durch Miner und Nutzer weiter. Für Halter direkt relevant ist dagegen die steuerliche Seite: Nach Paragraf 23 Einkommensteuergesetz kommt es für die einjährige Haltefrist ausschließlich auf den Zeitpunkt des wirtschaftlichen Zugangs an, nicht auf das verwendete Adressformat. Wer eigene Coins von einer SegWit- in eine Taproot-Wallet verschiebt, tätigt keine Veräußerung und reißt die Haltefrist nicht neu an, solange es sich um dieselbe wirtschaftliche Berechtigung handelt. Wie stabil dieser Rahmen selbst bleibt, ist allerdings eine offene Frage für sich, siehe dazu unsere Einordnung zu den Plänen des Kabinetts, die Haltefrist für Bitcoin zu kippen. Anders sieht es aus, sobald Taproot-Funktionalität für Anwendungen genutzt wird, die klassische Finanzdienstleistungen nachbilden, etwa verzinste Einlagen oder derivateähnliche Konstruktionen auf einem Rollup wie Citrea: Sobald ein Anbieter dazwischentritt, greifen je nach Ausgestaltung MiCA-Vorgaben für CASPs oder sogar MiFID-II-Regeln für Derivate, das Protokoll selbst bleibt unreguliert, der Vermittler davor in der Regel nicht.

Das Quantencomputer-Risiko: Ein nüchterner Ausblick

Der jüngste Stresstest für Taproot kommt nicht aus der Bitcoin-Community selbst, sondern aus einem Forschungspapier von Google Quantum AI, das laut CoinDesk Ende März 2026 veröffentlicht wurde. Die Kernaussage: Das Brechen von Bitcoins Signaturverfahren könnte mit weniger als 500.000 physischen (rund 1.200 bis 1.450 hochwertigen, logischen) Qubits gelingen, deutlich weniger als frühere Schätzungen im zweistelligen Millionenbereich nahelegten. Das Besondere an Taproot in diesem Zusammenhang: Weil eine P2TR-Adresse den vollständigen öffentlichen Schlüssel standardmäßig schon bei ihrer Erstellung offenlegt, anders als SegWit- oder Legacy-Adressen, die den Schlüssel bis zur ersten Ausgabe hinter einem Hash verstecken, ist jede Taproot-Ausgabe potenziell von der ersten Sekunde an quantenexponiert. Nach diesen Schätzungen sitzen bereits heute rund 6,9 Millionen BTC, etwa ein Drittel des Gesamtangebots, auf Adressen mit offenliegendem Schlüssel, macht bei einem Bitcoin-Kurs von rund 56.000 Euro laut CoinGecko einen groben Gegenwert von rund 386 Milliarden Euro. Die Reaktionen fielen unterschiedlich aus: Ethereum-Foundation-Forscher Justin Drake erklärte, seine Zuversicht in ein „Q-Day“ bis 2032 sei „deutlich gestiegen“, während Binance-Gründer Changpeng Zhao gelassener reagierte: „Alles, was Krypto tun muss, ist auf quantenresistente Algorithmen umzusteigen. Also kein Grund zur Panik.“ Als technische Antwort liegt seit dem 11. Februar 2026 mit BIP-360 ein formeller, aber noch nicht aktivierter Vorschlag für ein neues, post-quantensicheres Adressformat (Präfix bc1r) auf Basis der NIST-standardisierten ML-DSA-Signaturen vor, ergänzt durch das im April 2026 vorgestellte BIP-361, das einen mehrjährigen, phasenweisen Ausstieg aus alten, quantenverwundbaren Signaturen regeln soll. Ein ungelöstes technisches Detail begleitet BIP-360 dabei von Anfang an: Post-quantensichere Signaturen wie ML-DSA sind um ein Vielfaches größer als Schnorr-Signaturen, was bei einer breiten Migration die alte Blockgrößendebatte in neuer Form zurückbringen könnte, ein Kompromiss, über den innerhalb der Community bislang keine Einigkeit besteht. Für die eigentliche Bitcoin-Basis ändert das kurzfristig wenig: Weder BIP-360 noch BIP-361 sind aktiviert, beide sind Vorschläge, keine beschlossene Sache, und die meisten hier zitierten Fachleute rechnen selbst im vorsichtigen Szenario eher mit einem Zeithorizont von Jahren als Monaten. Für die laufende 2026er-Debatte um Bitcoins nächsten Schritt sind ohnehin die Covenant-Vorschläge und Rollups wie Citrea die unmittelbarere Geschichte, das Quantenrisiko bleibt vorerst ein Planungsthema, kein akutes. Für die meisten privaten Halter bedeutet das im Alltag: Wer Coins ohnehin regelmäßig bewegt oder in modernen, aktiv gepflegten Wallets hält, ist bereits heute besser positioniert als jemand, der Guthaben seit Jahren unbewegt auf ein und derselben, öffentlich bekannten Adresse liegen lässt.

Häufig gestellte Fragen zu Taproot

Was ist Taproot bei Bitcoin einfach erklärt?

Taproot ist ein Bündel aus drei Bitcoin Improvement Proposals (BIP 340, 341, 342), das am 14. November 2021 aktiviert wurde. Es führt Schnorr-Signaturen und eine Baumstruktur namens MAST ein, wodurch komplexe Ausgabebedingungen wie Multisig oder Zeitschlösser auf der Blockchain genauso aussehen können wie eine einfache Standardzahlung, günstiger, privater und flexibler als zuvor. Nach außen erkennbar sind entsprechende Adressen am Präfix bc1p.

Wann wurde Taproot aktiviert und warum hat es so lange gedauert?

Das Lock-in erfolgte am 12. Juni 2021 im Block 687.284 mit über 90 Prozent Miner-Zustimmung, die eigentliche Aktivierung folgte am 14. November 2021 im Block 709.632. Der Aktivierungsmechanismus Speedy Trial war bewusst kurz gehalten, weil Taproot als unkontroverses Effizienz-Upgrade galt, anders als die kontroverseren Covenant-Vorschläge, die 2026 diskutiert werden. Bitcoin-typisch lief die gesamte Umstellung dabei ohne zentrale Ankündigung, sondern rein über Code, Signalisierung und offene Diskussion.

Was unterscheidet eine Taproot-Adresse (bc1p) von einer SegWit-Adresse (bc1q)?

Beide nutzen die Bech32-Adressfamilie. SegWit-Adressen (bc1q) basieren auf Bech32 nach BIP 173 und referenzieren ein einzelnes, offen sichtbares Skript. Taproot-Adressen (bc1p) basieren auf Bech32m nach BIP 350 und einem Schnorr-Schlüssel, der optional einen ganzen Baum alternativer Ausgabebedingungen verbergen kann, ohne dass das nach außen sichtbar wird. In der Praxis empfehlen die meisten Wallets mittlerweile Taproot-Adressen für neue Transaktionen.

Macht Taproot Bitcoin anfälliger für Quantencomputer?

Taproot selbst schafft keine neue kryptografische Schwachstelle, verschärft aber ein bestehendes Problem: Weil eine P2TR-Adresse den öffentlichen Schlüssel schon bei der Erstellung offenlegt statt erst beim Ausgeben, sind Taproot-Guthaben potenziell länger einem theoretischen Quantenangriff ausgesetzt als SegWit-Guthaben. Nach aktuellen Schätzungen liegt ein praktisch relevanter Angriff aber noch Jahre entfernt, an Gegenmaßnahmen wie BIP-360 wird bereits gearbeitet. Wer besonders vorsichtig sein will, kann Guthaben nach jeder Ausgabe in eine neue, ungenutzte Adresse verschieben.

Ermöglicht Taproot Smart Contracts auf Bitcoin?

Taproot selbst ist kein Smart-Contract-System, legt aber mit Tapscript und dessen reservierten OP_SUCCESS-Opcodes das technische Fundament, über das spätere Vorschläge wie OP_CTV, OP_CAT oder Konstruktionen wie BitVM2 programmierbarere Bedingungen auf Bitcoin nachrüsten können. Rollups wie Citrea nutzen genau diese Grundlage bereits heute für vollständige Smart-Contract-Umgebungen, die auf Bitcoin abrechnen. Für klassische Bitcoin-Zahlungen ändert das im Alltag nichts.

Dieser Beitrag wurde von der Bitcoin-Layer-1-Redaktion von HOGE Wire recherchiert und verfasst.