Taproot fünf Jahre später: Bilanz eines stillen Upgrades

Bitcoins leises Upgrade wird erwachsen

Am 9. Juli 2026 handelt Bitcoin bei rund 55.000 Euro (CoinGecko), und kaum jemand denkt beim Klick auf „Senden“ noch an das Upgrade, das die Adresse in der Wallet erzeugt hat. Genau das war der Plan. Taproot, Bitcoins bislang letztes großes Protokoll-Upgrade, aktivierte am 14. November 2021 bei Block 709.632 und sollte, anders als frühere Kontroversen um Blockgröße oder SegWit, möglichst geräuschlos im Hintergrund wirken.

Fast fünf Jahre später lässt sich Bilanz ziehen: Taproot hat Lightning-Kanäle kompakter gemacht, Multisig-Wallets günstiger und, ungeplant, den gesamten Ordinals- und Inscriptions-Boom erst ermöglicht. Gleichzeitig bleibt die tatsächliche Nutzung auf der Bitcoin-Basisebene hinter den ursprünglichen Erwartungen zurück, und 2026 diskutiert die Entwicklergemeinschaft erneut über Taproots Grenzen, diesmal im Kontext von Quantencomputern. Dieser Artikel ordnet ein, was Taproot technisch leistet, wie sich die Adoption seit der Aktivierung entwickelt hat, welche Kontroversen das Upgrade bis heute begleiten und was das für Nutzer in Deutschland regulatorisch bedeutet.

Der Weg zu Taproot: Von SegWit zu Block 709.632

Die Idee zu Taproot reicht weiter zurück als die Aktivierung selbst. Im Januar 2018 skizzierte Bitcoin-Core-Entwickler Gregory Maxwell in einer Nachricht an die bitcoin-dev-Mailingliste ein Konzept, das kooperative Mehrparteien-Ausgaben optisch nicht mehr von einer gewöhnlichen Ein-Schlüssel-Zahlung unterscheidbar machen sollte, er nannte es Taproot. Aus dieser Skizze entwickelten Pieter Wuille, Jonas Nick und Anthony Towns in den folgenden zwei Jahren drei zusammenhängende Bitcoin Improvement Proposals: BIP 340 für Schnorr-Signaturen, BIP 341 für das neue Taproot-Ausgabeformat und BIP 342 für Tapscript, die zugehörige Skriptsprache. Wuille, unter seinem GitHub-Kürzel sipa bekannt, implementierte die Validierungsregeln in Pull Request 19953 für Bitcoin Core, der Ende 2020 nach monatelangem Review zusammengeführt wurde. Wer die Vorgeschichte und die technische Verbindung zu SegWit ausführlicher nachlesen möchte, findet eine Einordnung in unserem Artikel Taproot erklärt: Bitcoins größtes Upgrade seit SegWit.

Die eigentliche Hürde war nicht die Technik, sondern die Aktivierung. Die Einführung von SegWit 2017 war von einem monatelangen, teils erbittert geführten Streit über Bitcoins Blockgröße begleitet, der zeitweise in einen drohenden User Activated Soft Fork mündete, bei dem Teile der Community Minern faktisch ein Ultimatum stellten. Diese Erfahrung wollte die Community bei Taproot nicht wiederholen. Die Lösung hieß Speedy Trial: Zwischen April und August 2021 konnten Miner ihre Unterstützung per Signalisierung ausdrücken, mit einer Schwelle von 90 Prozent. Bereits im Juni 2021 war diese Schwelle erreicht, das Upgrade galt als beschlossen (locked in). Als zusätzliche Absicherung standardisierte BIP 343 einen verbindlichen Aktivierungsmechanismus (BIP8 mit LOT=true, Lock-in-on-Timeout) zwischen Block 681.408 und Block 760.032, der eine Aktivierung notfalls auch gegen zögerliche Miner erzwungen hätte. Gebraucht wurde diese Reserve nicht: Am 14. November 2021 aktivierte Taproot regulär bei Block 709.632, dem ersten Konsens-Upgrade seit SegWit im Jahr 2017.

Schnorr-Signaturen: Die kryptografische Basis (BIP 340)

Der Kern von Taproot ist ein Wechsel des Signaturverfahrens. Seit seiner Entstehung 2009 sichert Bitcoin Transaktionen mit dem Elliptic Curve Digital Signature Algorithm (ECDSA) ab. BIP 340 ergänzt dieses Verfahren um Schnorr-Signaturen auf derselben Kurve, secp256k1. Schnorr-Signaturen sind älter als ECDSA (das zugrunde liegende Patent von Claus-Peter Schnorr lief erst 2008 aus, was ihre späte Aufnahme in Bitcoin miterklärt), gelten aber als mathematisch einfacher und in mehrfacher Hinsicht überlegen.

Der entscheidende Vorteil ist Linearität: Mehrere Signaturen lassen sich zu einer einzigen aggregieren, die auf der Chain nicht mehr von der Signatur eines einzelnen Schlüssels zu unterscheiden ist, bei ECDSA ist das nicht ohne Weiteres möglich. Zusätzlich erlauben Schnorr-Signaturen Batch-Validierung: Full Nodes können mehrere Signaturen gemeinsam statt einzeln prüfen, was die Validierung ganzer Blöcke beschleunigt. In der Praxis bedeutet das kleinere Transaktionen, niedrigere Gebühren und, in Kombination mit Protokollen wie MuSig2, eine deutlich verbesserte Privatsphäre bei Mehrfachsignaturen. Eine tiefere technische Einordnung von BIP 340 und seinen Konsequenzen bietet unser Artikel Taproot erklärt: Was Bitcoins Schnorr-Upgrade wirklich bringt.

Ein Adressformat für alles: Taproot-Outputs und MAST (BIP 341)

BIP 341 definiert den eigentlichen Taproot-Output, technisch eine neue SegWit-Version (Version 1, kurz P2TR für Pay-to-Taproot), erkennbar an Adressen, die mit bc1p statt bc1q beginnen und im Bech32m-Format kodiert sind. Jeder Taproot-Output verknüpft einen öffentlichen Schlüssel mit optional einem Skriptbaum. Ausgegeben werden kann er auf zwei Arten.

Der Key-Path-Spend ist der Normalfall: Der Empfänger signiert direkt mit dem hinterlegten Schlüssel, die Transaktion sieht aus wie jede gewöhnliche Ein-Signatur-Zahlung, unabhängig davon, ob im Hintergrund eine einzelne Person oder ein komplexes Mehrparteien-Setup steht. Der Script-Path-Spend kommt zum Einsatz, wenn eine der hinterlegten Bedingungen erfüllt werden muss, etwa ein Zeitschloss, eine Mehrfachsignatur oder eine komplexere Vertragslogik. Dabei wird nur der tatsächlich genutzte Skriptzweig offengelegt, alle anderen möglichen Zweige bleiben unsichtbar.

Möglich macht das MAST, Merkelized Alternative Script Trees. Statt ein komplettes Skript mit allen möglichen Bedingungen auf der Chain zu veröffentlichen, wird nur die Merkle-Wurzel eines Baums aus beliebig vielen Teilskripten im Output hinterlegt. Beim Ausgeben legt der Sender lediglich den genutzten Zweig plus den dazugehörigen Merkle-Pfad offen, der Rest des Baums bleibt für Beobachter unsichtbar und spart zugleich Blockplatz. Ein Beispiel verdeutlicht den Nutzen: Eine Wallet könnte einen Taproot-Output erzeugen, dessen Schlüssel-Pfad eine gewöhnliche Zahlung an den Empfänger erlaubt, während im Hintergrund zusätzlich ein Erbfall-Zweig (auslösbar nach zwölf Monaten Inaktivität über einen Zweitschlüssel) und ein Notfall-Zweig (auslösbar sofort über drei von fünf Backup-Unterschriften) hinterlegt sind. Solange niemand diese Zusatzbedingungen benötigt, sieht die Adresse wie jede andere Ein-Schlüssel-Adresse aus, die zusätzliche Komplexität kostet weder Gebühren noch Privatsphäre.

Tapscript: Bitcoins neue Skriptsprache (BIP 342)

Wo BIP 341 das Adressformat regelt, definiert BIP 342 die Sprache, in der die einzelnen Skriptzweige geschrieben werden: Tapscript. Gegenüber dem klassischen Bitcoin Script gibt es mehrere Anpassungen. OP_CHECKSIG und OP_CHECKSIGVERIFY prüfen jetzt Schnorr- statt ECDSA-Signaturen, die alten Mehrfachsignatur-Opcodes OP_CHECKMULTISIG und OP_CHECKMULTISIGVERIFY sind deaktiviert und werden durch den effizienteren Opcode OP_CHECKSIGADD ersetzt, der sich besser mit Schnorrs Linearitätseigenschaft verträgt. Neu sind zudem reservierte OP_SUCCESS-Opcodes: Bislang ungenutzte Opcodes gelten automatisch als gültig, was zukünftige Softfork-Erweiterungen erleichtert, ohne dass ältere Software die neuen Regeln verstehen muss, sie darf sie nur nicht mehr blockieren. Dieses Design war später der Hebel, mit dem Ordinals und Inscriptions in Tapscript-Zweigen beliebige Daten unterbringen konnten, dazu mehr im Abschnitt zur Ordinals-Lücke weiter unten.

Zusätzlich führt Tapscript feste Ressourcengrenzen ein: Die maximale Zahl an Signaturprüfungen pro Skript hängt jetzt von dessen Größe ab, was Denial-of-Service-Angriffe über absichtlich rechenintensive Skripte erschwert. Für Entwickler war das die Grundlage, um komplexere Vertragslogik, etwa für Lightning oder Discreet Log Contracts, sicher und vorhersagbar auf Bitcoin abzubilden.

Privatsphäre in der Praxis: Was Taproot verbirgt, und was nicht

Taproots Privatsphäre-Versprechen wird oft vereinfacht wiedergegeben mit dem Satz, alle Taproot-Transaktionen sähen gleich aus. Das stimmt nur für den Idealfall. Ein kooperativer Key-Path-Spend, etwa eine gewöhnliche Zahlung oder ein per MuSig2 aggregierter Mehrparteien-Spend, ist tatsächlich von jeder anderen Ein-Schlüssel-Zahlung nicht zu unterscheiden. Sobald aber ein Script-Path-Spend nötig wird, wird der genutzte Skriptzweig sichtbar, und Chain-Analysten erkennen das Muster. Taproot verbirgt also die Existenz alternativer Bedingungen, nicht zwingend deren Nutzung im Streit- oder Sonderfall.

Ein konkretes Beispiel: Schließt ein Lightning-Nutzer seinen Kanal nicht kooperativ, sondern erzwungen, etwa weil der Kanalpartner offline ist, muss die Commitment-Transaktion den entsprechenden Tapscript-Zweig offenlegen. Chain-Analysten erkennen an diesem Muster zuverlässig, dass es sich um einen Lightning-Kanal-Schluss handelte, selbst wenn sie die Zahlungen innerhalb des Kanals selbst nicht einsehen können. Taproot verbirgt die Lightning-Nutzung also nicht vollständig, es reduziert nur den Anteil der Fälle, in denen so etwas sichtbar wird, auf den unkooperativen Sonderfall.

Weitere Grenzen bleiben bestehen: Taproot ändert nichts an sichtbaren Transaktionsbeträgen, dafür bräuchte es Techniken wie Confidential Transactions, die auf Bitcoin-Ebene nicht existieren, nichts an der grundsätzlichen Graphstruktur von Eingaben und Ausgaben, und nichts an der Adresswiederverwendung, die nach wie vor die häufigste Ursache für De-Anonymisierung ist. Wer eine Taproot-Adresse mehrfach für eingehende Zahlungen nutzt, verschenkt den Privatsphäre-Vorteil ebenso wie bei jedem anderen Adressformat. CoinJoin-Implementierungen und andere Mischverfahren bleiben deshalb auch nach Taproot relevant, Taproot senkt lediglich die Kosten und erhöht die Anonymitätsmenge für den Sonderfall kooperativer Mehrparteien-Ausgaben, es ersetzt keine dedizierte Privatsphäre-Lösung.

MuSig2 und die Multisig-Revolution

Eine der praktisch wichtigsten Anwendungen von Schnorrs Linearität ist MuSig2, spezifiziert in BIP 327 von Jonas Nick, Tim Ruffing und Elliot Jin, aufbauend auf einer 2021 auf der Kryptografie-Konferenz CRYPTO vorgestellten Konstruktion. MuSig2 erlaubt es mehreren Unterzeichnern, in nur zwei Kommunikationsrunden eine einzelne aggregierte Signatur zu erzeugen, die on-chain nicht von einer gewöhnlichen Einzel-Signatur zu unterscheiden ist.

Der Effekt für Multisig-Wallets ist erheblich. Klassisches Bitcoin-Multisig (P2SH oder P2WSH) verrät sich selbst: Jeder öffentliche Schlüssel und jede Signatur landet sichtbar auf der Chain, eine Drei-von-fünf-Konfiguration erzeugt entsprechend große, teure Transaktionen. Ein Taproot-Multisig mit MuSig2 verhält sich im kooperativen Fall dagegen wie eine einzelne Signatur mit fester, kleiner Größe, unabhängig davon, ob zwei oder zwölf Parteien beteiligt sind. Wallet-Anbieter mit Fokus auf institutionelle und fortgeschrittene Privatnutzer bewerben ihre Taproot-Multisig-Produkte entsprechend mit spürbar niedrigeren Gebühren gegenüber klassischen Setups. Eine wichtige Einschränkung bleibt: MuSig2 deckt nur den Fall ab, in dem wirklich alle Schlüssel mitwirken. Echte Schwellenwert-Konfigurationen wie „zwei von drei Schlüsseln reichen“ benötigen weiterhin den Script-Path als Rückfalloption, wodurch der volle Privatsphäre-Vorteil nur greift, solange alle Parteien kooperieren und mitsignieren.

Neue Anwendungen: Lightning, PTLCs und Discreet Log Contracts

Auch abseits der Basisebene verändert Taproot, wie Bitcoin genutzt wird. Lightning Labs brachte mit LND 0.17 im Oktober 2023 Simple Taproot Channels: Kanal-Finanzierungs- und Commitment-Transaktionen nutzen seither P2TR-Outputs und, sofern beide Kanalpartner online und kooperativ sind, MuSig2-Signaturaggregation. Ein kooperativ geschlossener Lightning-Kanal sieht dadurch auf der Chain aus wie eine gewöhnliche Zahlung, kleiner und günstiger als ein klassischer Kanal-Schluss.

Der nächste Schritt sind Point Time-Locked Contracts (PTLCs), die die heute noch dominierenden Hash Time-Locked Contracts (HTLCs) ablösen sollen. HTLCs hinterlassen bei jedem Hop entlang eines Zahlungspfads denselben Hash-Wert, was es Beobachtern erlaubt, verkettete Zahlungen zu korrelieren. PTLCs nutzen stattdessen bei jedem Hop unterschiedliche, kryptografisch geblindete Werte und erschweren diese Korrelation erheblich. Die anfängliche LND-Implementierung von Simple Taproot Channels arbeitet noch ausschließlich mit HTLCs, damit Zahlungen weiterhin über Knoten ohne Taproot-Unterstützung geroutet werden können, PTLCs gelten als eine der nächsten Ausbaustufen. Auch andere Lightning-Implementierungen rüsteten 2025 zusätzliche MuSig2-Funktionalität nach.

Abseits von Lightning ermöglichte Taproot erstmals praktikable Discreet Log Contracts (DLCs): Zwei oder mehr Parteien schließen eine Wette auf den Ausgang eines Ereignisses ab, dessen Ergebnis ein Orakel signiert, ohne dass die eigentlichen Vertragsbedingungen jemals sichtbar auf der Chain landen. Möglich machen das Adaptor-Signaturen, eine weitere Anwendung der Schnorr-Linearität. Nach außen sieht ein DLC wie eine gewöhnliche Mehrfachsignatur-Zahlung aus. Sollten künftig automatisierte Handelsagenten eigenständig Bitcoin-Positionen verwalten, wie es unser Artikel KI-Agenten on-chain: Wenn Bots ihre eigene Wallet steuern für andere Chains beschreibt, wären DLCs eine der wenigen bitcoin-nativen Vertragsformen, auf die sich ein solcher Agent ohne zusätzliche Sidechain oder Federation stützen könnte.

Die Ordinals-Lücke: Wie Taproot zum Datenspeicher wurde

Kein Aspekt von Taproot löste mehr Kontroversen aus als eine Nebenwirkung, die in keinem der drei BIPs beabsichtigt war. Im Januar 2023 veröffentlichte Entwickler Casey Rodarmor das Ordinals-Protokoll: Es nummeriert einzelne Satoshis durch und erlaubt es, beliebige Daten, Bilder, Text, sogar kleine Programme, an einen bestimmten Satoshi zu inskribieren. Technisch nutzen Inscriptions einen Kunstgriff: Die Daten werden in einem Tapscript-Zweig versteckt, der mit OP_FALSE OP_IF eingeleitet wird, ein Codeblock, der beim Ausführen sofort übersprungen wird und dessen Inhalt Bitcoin Core deshalb nie inhaltlich prüft.

Der eigentliche Auslöser war eine Lücke in der Relay-Policy: Die alten Datenträger-Grenzen für OP_RETURN, ursprünglich eingeführt, um Spam-Daten in einen kontrollierten, kostengünstigen Container zu verbannen, wurden nie auf Taproot-Zeugendaten ausgeweitet. Wer Daten stattdessen in einem Tapscript-Zweig versteckte, umging die Begrenzung komplett und profitierte zugleich vom sogenannten Witness-Discount, der Zeugendaten günstiger gewichtet als reguläre Transaktionsdaten. Bitcoin-Core-Entwickler und Ocean-Mining-Verantwortlicher Luke Dashjr bezeichnete das als Bug und registrierte die Lücke im Dezember 2023 offiziell in der NIST-Schwachstellendatenbank als CVE-2023-50428 mit einem mittleren Schweregrad von 5,3.

Ob Bug oder cleverer Gebrauch einer offen dokumentierten Funktion, blieb umstritten, die Wirkung war messbar. Die Taproot-Nutzungsrate, die 2022 im niedrigen einstelligen Prozentbereich verharrt hatte, kletterte laut mehreren Auswertungen bis Januar 2024 auf rund 39 Prozent aller Transaktionen. Als Casey Rodarmor im April 2024 zum Halving bei Block 840.000 zusätzlich das Runes-Protokoll für fungible Token auf Bitcoin-Basis startete, das ebenfalls auf OP_RETURN- und Taproot-Strukturen aufbaut, beanspruchten Runes-Transaktionen binnen weniger Stunden den überwiegenden Teil aller Netzwerkgebühren. Für Miner war das ein unerwarteter Gebührensegen, für Verfechter eines rein monetären Bitcoin ein Alarmsignal. Wie stark Blockspace-Nachfrage und Mining-Wirtschaftlichkeit zusammenhängen, zeigt unser Artikel Hashprice erklärt: Bitcoin-Mining am Rekordtief 2026.

Der Streit um OP_RETURN und BIP-110

Der Streit um Bitcoins Blockspace verlagerte sich 2025 auf eine neue Front. Im April 2025 reichte Bitcoin-Core-Mitentwickler Peter Todd Pull Request 32359 ein und schlug vor, sämtliche Größenbeschränkungen für OP_RETURN ersatzlos zu streichen, samt der Konfigurationsoptionen datacarrier und datacarriersize, mit denen einzelne Node-Betreiber die Grenzen bislang selbst festlegen konnten. Sein Argument: Wer Daten unbedingt unterbringen wolle, umgehe die Relay-Policy ohnehin über direkte Miner-Mempools oder alternative Relay-Software, die Beschränkung schütze also längst niemanden mehr, sondern verzerre nur noch, wo die Daten landen. Der Pull Request wurde im Mai 2025 wieder geschlossen, Reviewer bevorzugten einen moderateren Weg. Kritiker wie Jason Hughes, Bitcoin-Entwickler und Leiter der Entwicklung beim Mining-Pool Ocean, forderten, eine so grundlegende Änderung müsse „mit derselben Sorgfalt behandelt werden wie ein Hard Fork“.

Am Ende setzte sich ein Kompromiss durch: Bitcoin Core 30, veröffentlicht im Oktober 2025, hob das Standardlimit für einzelne OP_RETURN-Ausgaben von 83 auf 100.000 Byte an und erlaubt seither auch mehrere OP_RETURN-Ausgaben pro Transaktion, behielt die Konfigurationsoption für Node-Betreiber aber bei, die die Grenze weiterhin selbst absenken können. Die Entscheidung kostete Bitcoin Core Marktanteile: Alternative Implementierungen wie Bitcoin Knots, das striktere Standardwerte durchsetzt, gewannen spürbar an Node-Betreibern hinzu.

Ruhe kehrte damit nicht ein. 2026 brachte ein Entwickler unter dem Namen Dathon Ohm mit BIP-110 einen deutlich schärferen Gegenentwurf ins Spiel: einen zeitlich befristeten Softfork, der Skript-Ausgaben wieder auf wenige Dutzend Byte begrenzen, einzelne Datenpushes und Zeugendaten deckeln und mehrere der für Inscriptions genutzten Tapscript-Mechanismen gezielt einschränken soll. Luke Dashjr unterstützt den Vorstoß, für ihn ist damit die seit 2023 dokumentierte Lücke endlich zu schließen. Adam Back, Mitgründer und Chef von Blockstream, lehnt BIP-110 dagegen scharf ab. Anders als bei SegWit, wo am Ende ein breiter Konsens stand, fehle BIP-110 der Rückhalt sowohl unter Entwicklern als auch bei wirtschaftlichen Akteuren, eine erzwungene Aktivierung riskiere lediglich eine kleine, folgenlose Abspaltung. Auf X kommentierte er zugespitzt: „Vielleicht hassen die Befürworter des Filter-BIP Spam mehr, als ihnen Bitcoins Unveränderlichkeit und Wertspeicher-Funktion am Herzen liegen, ähnlich wie die Big Blocker, die billige Skalierung wichtiger fanden als Unveränderlichkeit und Wertspeicher.“ Der Streit zeigt, wie sehr eine einzelne, ursprünglich rein technische Entscheidung in BIP 342, nämlich welche Opcodes künftige Softforks ohne Störung bestehender Nutzer einführen können, zum politischen Dauerthema in der Bitcoin-Entwicklung geworden ist.

Adoption 2026: Zahlen, Dashboards und Wallet-Support

Wie viele Bitcoin-Transaktionen heute tatsächlich Taproot nutzen, hängt spürbar davon ab, wen man fragt. Verschiedene On-Chain-Dashboards kommen je nach Methodik, zählt man alle Inputs oder nur Outputs, kumulativ seit der Aktivierung oder gleitend im Monatsdurchschnitt, auf unterschiedliche Werte für denselben Zeitraum. Ein Vergleich mehrerer Tracker ergab für einen einzelnen Stichtag gleichzeitig Werte von 13, 16 und 20 Prozent, je nach Berechnungsart.

Zum Vergleich: SegWit, 2017 eingeführt, wird inzwischen von schätzungsweise 85 bis 90 Prozent aller Transaktionen mindestens teilweise genutzt. Taproot bleibt trotz der zusätzlichen Marktzeit deutlich dahinter zurück. Ein Grund liegt am Wallet-Support: Zwar unterstützen inzwischen praktisch alle relevanten Wallets, von Bitcoin Core über Sparrow, Electrum und Wasabi auf dem Desktop bis zu Muun und BlueWallet auf Mobilgeräten, den Empfang und Versand über P2TR-Adressen, doch längst nicht jede Wallet setzt Taproot standardmäßig als Adressformat, wenn ein Nutzer eine neue Adresse erzeugt. Ohne diesen Standardwechsel bleibt ein großer Teil der Nutzerbasis technisch kompatibel, aber praktisch inaktiv.

Der Preis der langsamen Adoption lässt sich auch in Euro und Cent ausdrücken: Wer weiterhin über ein älteres SegWit- oder gar Legacy-Format sendet, zahlt bei gleicher Netzwerkauslastung spürbar höhere Gebühren als über einen Taproot-Output, weil Letzterer weniger Byte auf der Chain benötigt. Bei den niedrigen Netzwerkgebühren, wie sie 2026 überwiegend herrschen, fällt der Unterschied kaum auf, in Phasen hoher Auslastung, etwa während vergangener Inscription-Wellen, machte er dagegen mehrere Euro pro Transaktion aus.

Regulatorischer Rahmen: BaFin, MiCA und ein Protokoll ohne Lizenzpflicht

Für deutsche Leser stellt sich regelmäßig die Frage, wer ein Protokoll-Upgrade wie Taproot eigentlich genehmigt. Die Antwort: niemand, und das ist kein Zufall. Bitcoin hat keinen Emittenten, kein Unternehmen und keine Rechtsperson, die für ein Update haftbar gemacht oder um Erlaubnis gebeten werden könnte, Änderungen wie Taproot entstehen durch Konsens unter Entwicklern, Minern und Nutzern, wie in den vorigen Abschnitten beschrieben. Weder die Verordnung über Märkte für Kryptowerte (MiCA) noch nationales Aufsichtsrecht adressieren deshalb das Bitcoin-Protokoll selbst.

Reguliert wird stattdessen, wer Zugang zu Bitcoin vermittelt. Seit BaFin Bitcoin 2013 erstmals als Rechnungseinheit im Sinne des Kreditwesengesetzes einstufte, eine Auslegung, die ein Berliner Gericht 2020 in einem Einzelfall zwar in Frage stellte, die BaFin aber grundsätzlich beibehielt, unterliegt das Kryptoverwahrgeschäft einer eigenen Erlaubnispflicht. MiCA hat diesen Rahmen ab 2024 europaweit vereinheitlicht und ergänzt: Anbieter, die deutschen Kunden Handel, Verwahrung oder den Tausch von Bitcoin anbieten, benötigen seither eine CASP-Zulassung (Crypto-Asset Service Provider), erteilt und beaufsichtigt von der BaFin. Die Übergangsfrist für Bestandsunternehmen ist inzwischen ausgelaufen, in Deutschland über das Kryptomärkteaufsichtsgesetz (KMAG) bereits zum 31. Dezember 2025, EU-weit spätestens zum 1. Juli 2026. Anbieter ohne gültige Zulassung dürfen seither keine neuen deutschen Kunden mehr annehmen und müssen bestehende Geschäfte geordnet abwickeln.

Für Selbstverwahrer, die ihre Coins in einer eigenen Wallet mit Taproot-Adresse halten, ändert das nichts, MiCA reguliert Dienstleister, nicht die private Verwahrung eigener Schlüssel. Steuerlich bleibt Taproot ebenfalls neutral: Ob eine Bitcoin-Adresse mit bc1p oder bc1q beginnt, hat auf die einkommensteuerliche Behandlung nach Paragraf 23 EStG keinen Einfluss, insbesondere nicht auf die einjährige Haltefrist. Details zu Haltefrist, Freigrenze und der ab 2027 greifenden DAC8-Meldepflicht für Kryptodienstleister erklärt unser Artikel Krypto-Steuer 2026: DAC8-Meldepflicht und das Ende der Haltefrist?.

Der nächste Testfall: Quantencomputer, BIP-360 und die Flexibilität von Taproot

Die nächste große Debatte um Taproot dreht sich nicht um Ordinals, sondern um Quantencomputer. Sowohl der Key-Path-Spend, eine gewöhnliche Schnorr-Signatur, als auch ältere Adressformate beruhen auf der Schwierigkeit des diskreten Logarithmus-Problems auf elliptischen Kurven, ein Problem, das ein ausreichend leistungsfähiger, fehlerkorrigierter Quantencomputer mit Shors Algorithmus lösen könnte. Aktuelle Quantencomputer sind davon nach übereinstimmender Einschätzung vieler Experten noch weit entfernt, doch die Bitcoin-Entwicklerszene diskutiert die Vorsorge bereits intensiv, gerade weil eine nachträgliche Migration von Guthaben in alten Adressen Jahre dauern würde.

Blockstream-Mitgründer Adam Back vertritt dabei eine bemerkenswerte These: Ausgerechnet Taproots Architektur mache die Migration einfacher als befürchtet. Weil Tapscript über die OP_SUCCESS-Opcodes von Anfang an auf zukünftige, heute noch unbekannte Skriptbedingungen ausgelegt wurde, lassen sich neue, quantenresistente Signaturverfahren als zusätzliche Skriptzweige einführen, ohne bestehende Nutzer zu stören oder ihre Guthaben anzutasten. Back plädierte bei der Paris Blockchain Week dafür, schon jetzt mit optionalen, freiwilligen Upgrades zu beginnen, statt einen starren Einfrier-Fahrplan festzulegen, auch wenn heutige Quantencomputer seiner Einschätzung nach noch „im Wesentlichen Laborexperimente“ mit „schrittweisem“ Fortschritt seien. Konkreter wird bereits BIP 360 (Pay-to-Merkle-Root, P2QRH) von Hunter Beast, Ethan Heilman und Isabel Foxen Duke, im März 2026 offiziell ins BIP-Repository aufgenommen: Es beschreibt einen neuen, Taproot-artigen Output-Typ auf Basis von Post-Quanten-Signaturverfahren wie FALCON und CRYSTALS-Dilithium, bei dem allerdings der heute übliche, quantenverwundbare Key-Path-Spend entfällt.

Nicht jeder teilt Backs Zuversicht, dass eine freiwillige, schrittweise Migration ausreicht. Bitcoin-Entwickler Jameson Lopp schlug im April 2026 mit BIP 361 einen deutlich härteren Ansatz vor: einen auf fünf Jahre befristeten, verbindlichen Sunset-Mechanismus, nach dessen Ablauf nicht migrierte Guthaben in quantenverwundbaren Altadressen dauerhaft eingefroren würden. Nach seiner Rechnung stecken allein in klassischen P2PK-Adressen rund 1,7 Millionen BTC, zählt man alle Adresstypen mit potenziell exponierten öffentlichen Schlüsseln zusammen, kommen manche Schätzungen auf bis zu 5,6 Millionen BTC im Gegenwert von rund 420 Milliarden US-Dollar zum jeweiligen Berichtszeitpunkt. Lopps Begründung, pointiert zusammengefasst: „Von Quantencomputern wiederhergestellte Coins machen die Guthaben aller anderen nur weniger wert. Man kann es sich als Diebstahl an allen vorstellen.“ Kritiker halten dagegen, ein derart eingreifender Schritt widerspreche Bitcoins Kernversprechen bedingungsloser Verfügungsgewalt über die eigenen Schlüssel und schaffe einen gefährlichen Präzedenzfall. Der Streit ist unentschieden, zeigt aber, dass Taproots Flexibilität, MAST, Tapscript, die OP_SUCCESS-Reserve, fünf Jahre nach der Aktivierung zum entscheidenden Werkzeug für Bitcoins nächste große Weichenstellung werden könnte.

Fazit: Bilanz nach fast fünf Jahren

Taproot war als leises Upgrade gedacht, und technisch ist es das auch geblieben: kein Hard Fork, kein Streit über die Blockgröße, keine gespaltene Chain. Trotzdem hat es mehr verändert, als die vergleichsweise niedrige direkte Nutzungsrate von aktuell rund 15 bis 20 Prozent aller Transaktionen vermuten lässt.

• Kleinere, günstigere Lightning-Kanäle durch Simple Taproot Channels und MuSig2
• Günstigere, diskretere Multisig-Wallets für Unternehmen und Privatnutzer
• Erstmals praktikable Discreet Log Contracts als bitcoin-native Smart Contracts
• Unbeabsichtigt: die technische Grundlage für Ordinals, Inscriptions und Runes
• Ein möglicher Ausweg aus der Quantencomputer-Bedrohung über neue Tapscript-Zweige

Dieselbe Flexibilität, die all das ermöglichte, öffnete unbeabsichtigt die Tür für Ordinals, Inscriptions und Runes, was bis heute in Form von BIP-110 und dem Streit um OP_RETURN nachwirkt. Und ausgerechnet die Architektur, die Kritiker einst für unnötig kompliziert hielten, gilt Entwicklern wie Adam Back heute als bester Ausweg aus der nächsten Bedrohung, der Quantencomputer. Ob Taproot am Ende eher als Datenschutz-Upgrade, als Grundlage für Bitcoins Skalierungs-Werkzeuge oder als Blaupause für die nächste, weit größere Migration in Erinnerung bleibt, lässt sich Mitte 2026 noch nicht abschließend sagen. Sicher ist nur, dass Bitcoins Protokollentwicklung mit BIP-110 und der Quantenfrage 2026 alles andere als abgeschlossen ist.

Häufig gestellte Fragen

Was ist Taproot bei Bitcoin einfach erklärt?

Taproot ist ein Bitcoin-Softfork-Upgrade, das am 14. November 2021 aktiviert wurde und drei technische Neuerungen bündelt: Schnorr-Signaturen (BIP 340), ein neues Adressformat namens Pay-to-Taproot (BIP 341) und eine erweiterte Skriptsprache namens Tapscript (BIP 342). Im Kern sorgt Taproot dafür, dass komplexe Zahlungsbedingungen, etwa Mehrfachsignaturen oder Zeitschlösser, auf der Chain genauso aussehen können wie eine gewöhnliche Ein-Schlüssel-Zahlung, solange alle Beteiligten kooperieren.

Wann wurde Taproot aktiviert und was war Block 709.632?

Taproot aktivierte am 14. November 2021 bei Blockhöhe 709.632, nachdem Miner die nötige Zustimmung von über 90 Prozent bereits im Juni 2021 über den Speedy-Trial-Mechanismus erreicht hatten. Es war das erste Bitcoin-Konsens-Upgrade seit Segregated Witness (SegWit) im Jahr 2017.

Macht Taproot Bitcoin-Transaktionen komplett anonym?

Nein. Taproot verbessert die Privatsphäre nur für den kooperativen Key-Path-Spend, bei dem eine Transaktion wie eine gewöhnliche Ein-Schlüssel-Zahlung aussieht. Sobald ein Script-Path-Spend nötig wird, etwa bei einem einseitig geschlossenen Lightning-Kanal, wird der genutzte Bedingungszweig sichtbar. Transaktionsbeträge, die Struktur des Zahlungsgraphen und die Folgen von Adresswiederverwendung bleiben von Taproot unberührt, für echte Anonymität sind weiterhin zusätzliche Techniken wie CoinJoin nötig.

Warum ist die Taproot-Adoption Jahre nach der Aktivierung noch relativ niedrig?

Mehrere Gründe kommen zusammen: Viele Wallets unterstützen Taproot-Adressen zwar, setzen sie aber nicht automatisch als Standardformat, wenn Nutzer eine neue Adresse erzeugen. Zudem lag ein Großteil der bisherigen Nutzungsspitzen, etwa Anfang 2024 mit Werten um 39 Prozent, an Ordinals- und Runes-Aktivität und nicht an organischer Zahlungsnutzung, weshalb die Rate seit Abklingen dieses Hypes wieder auf schätzungsweise 15 bis 20 Prozent gesunken ist.

Was haben Ordinals und Inscriptions mit Taproot zu tun?

Ordinals nutzen einen Tapscript-Zweig, der mit OP_FALSE OP_IF eingeleitet wird, um beliebige Daten wie Bilder oder Text an einzelne Satoshis anzuhängen. Weil die alten Größenbeschränkungen für Daten in Bitcoin-Transaktionen nie auf Taproot-Zeugendaten ausgeweitet wurden, konnten Nutzer diese Lücke seit dem Start von Ordinals im Januar 2023 nutzen, um deutlich mehr Daten unterzubringen als über den klassischen OP_RETURN-Weg erlaubt war. Die Lücke ist bis heute Gegenstand hitziger Debatten, zuletzt rund um den Vorschlag BIP-110.

Redaktion HOGE Wire, Ressort Bitcoin und Layer-1-Protokolle.