Am 14. November 2021 aktivierte das Bitcoin-Netzwerk kurz nach 05:15 UTC das bislang letzte gro\u00dfe Konsens-Upgrade seines Protokolls: Taproot. Fast f\u00fcnf Jahre sp\u00e4ter ist aus der damaligen Fachdiskussion \u00fcber Schnorr-Signaturen und Merkle-B\u00e4ume die unsichtbare Grundlage f\u00fcr einen wachsenden Teil dessen geworden, was auf Bitcoin passiert, von privaten Multisig-Wallets \u00fcber 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\u00e4chlich ist und warum sich Entwickler gerade wieder heftig \u00fcber Bitcoins n\u00e4chsten Schritt streiten. Wer selbst Bitcoin h\u00e4lt, kann direkt anhand des Adressformats erkennen, ob eine eigene oder fremde Adresse bereits auf Taproot setzt, ein guter Ausgangspunkt f\u00fcr alles, was danach folgt.<\/p>
Taproot ist kein einzelnes Feature, sondern ein B\u00fcndel aus drei zusammenh\u00e4ngenden Bitcoin Improvement Proposals (BIPs), die am 14. November 2021 im Block 709.632 gemeinsam aktiviert wurden, wie unter anderem CoinDesk<\/a> zur Aktivierung berichtete. Im Kern l\u00f6st Taproot ein einfaches Problem: Komplexe Ausgabebedingungen wie Mehrfachsignaturen oder Zeitschl\u00f6sser sollen auf der Blockchain m\u00f6glichst genauso aussehen wie eine simple Standardzahlung, g\u00fcnstiger in der Geb\u00fchr und ohne unn\u00f6tige Informationen preiszugeben. Die drei BIPs im \u00dcberblick:<\/p> Zusammengenommen ersetzen diese drei BIPs weder Bitcoins Konsensregeln zur Geldmenge noch die grunds\u00e4tzliche Blockstruktur, sie ver\u00e4ndern ausschlie\u00dflich, wie einzelne Ausgaben kryptografisch abgesichert und ausgegeben werden k\u00f6nnen, eine bewusst eng begrenzte \u00c4nderung, die die sp\u00e4tere Zustimmung der Miner erheblich erleichterte. Nach au\u00dfen erkennbar ist eine Taproot-Ausgabe an ihrem Adresspr\u00e4fix bc1p, im Unterschied zu bc1q bei SegWit-Adressen oder der f\u00fchrenden 1 bei klassischen Legacy-Adressen. Die technische Spezifikation selbst liegt offen im bitcoin\/bips-Repository auf GitHub<\/a>.<\/p> 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 \u00f6ffentlichen Schl\u00fcssel und das vollst\u00e4ndige Skript offenlegen, unabh\u00e4ngig davon, ob es sich um ein Firmen-Treasury, ein B\u00f6rsen-Cold-Wallet oder eine private Erbschaftsregelung handelte. F\u00fcr Ermittler, Steuerbeh\u00f6rden oder schlicht neugierige Blockchain-Beobachter war das ein Segen, f\u00fcr 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\u00e4tzliche Signaturfeld vergr\u00f6\u00dfert die Transaktion in Byte und damit die Geb\u00fchr. Zweitens Privatsph\u00e4re: Beobachter der Blockchain konnten allein am Transaktionsmuster ablesen, welche Wallet-Software oder welches Sicherheitsmodell jemand nutzt, ein Fingerabdruck, der sich f\u00fcr gezielte Angriffe ausnutzen l\u00e4sst. 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\u00fcr die Folgen lieferte schon in den fr\u00fcheren 2010er-Jahren die sogenannte Transaktionsmalleabilit\u00e4t, bei der sich die Transaktions-ID durch geringf\u00fcgige \u00c4nderungen an einer Signatur ver\u00e4ndern lie\u00df, ohne die eigentliche Zahlung ung\u00fcltig zu machen, ein Problem, das SegWit 2017 strukturell entsch\u00e4rfte und das mit den festen, deterministischen 64-Byte-Signaturen aus BIP 340 endg\u00fcltig an Relevanz verlor. Auch die Idee, Skriptbedingungen in einem Baum zu verstecken, ist \u00e4lter als Taproot selbst: Bereits 2016 und 2017 schlug der Entwickler Johnson Lau mit den BIPs 114, 116 und 117 fr\u00fche 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\u00e4higen Kandidaten.<\/p> BIP 340 ersetzt ECDSA im Taproot-Kontext durch Schnorr-Signaturen, benannt nach dem deutschen Mathematiker Claus-Peter Schnorr, dessen Verfahren lange patentgesch\u00fctzt war, das Patent aber bereits vor der eigentlichen Taproot-Entwicklung auslief. Dass Bitcoin dennoch bis 2021 auf das \u00e4ltere, patentfreie ECDSA setzte, lag weniger an rechtlichen als an praktischen Gr\u00fcnden: ECDSA war 2009 bereits gut getestete Standardtechnologie, w\u00e4hrend Schnorr-Signaturen erst nach Jahren \u00f6ffentlicher Forschung, unter anderem am Blockstream-Forschungsteam um Pieter Wuille, so weit ausgereift waren, dass eine Konsens\u00e4nderung vertretbar erschien. Der entscheidende Vorteil ist Linearit\u00e4t: Mehrere Schnorr-Signaturen und die dazugeh\u00f6rigen \u00f6ffentlichen Schl\u00fcssel lassen sich mathematisch zu einer einzigen Signatur und einem einzigen Schl\u00fcssel aggregieren, ohne dass eine Partei die privaten Schl\u00fcssel der anderen kennen muss. Der mathematische Grund: Eine ECDSA-Signatur enth\u00e4lt einen Term, bei dem eine Zufallszahl invertiert werden muss, eine Operation, die sich nicht verlustfrei \u00fcber mehrere Teilnehmer hinweg addieren l\u00e4sst. 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\u00e4ter mehr) \u00fcberhaupt erst praktikabel, wobei die Sicherheit der Aggregation selbst \u00fcber Jahre kryptografischer Begutachtung nachgewiesen wurde, bevor BIP 340 als aktivierungsreif galt. Ein weiterer, unscheinbarerer Vorteil: Schnorr-Signaturen haben eine feste Gr\u00f6\u00dfe von 64 Byte, w\u00e4hrend klassische DER-kodierte ECDSA-Signaturen zwischen 71 und 73 Byte variieren, ein kleiner Unterschied, der sich \u00fcber Millionen Transaktionen zu sp\u00fcrbaren Netzwerk- und Geb\u00fchreneinsparungen summiert.<\/p> BIP 341 f\u00fchrt zus\u00e4tzlich 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\u00e4ndig sichtbares Skript zu packen, werden sie als einzelne Bl\u00e4tter in einen Merkle-Baum geh\u00e4ngt. Nur die Wurzel dieses Baums, ein einzelner 32-Byte-Hash, landet in der \u00f6ffentlichen Adresse. Eine Wallet k\u00f6nnte zum Beispiel drei Bedingungen definieren: ein 2-von-2-Multisig f\u00fcr den Alltag, ein 3-von-5-Backup-Schema f\u00fcr den Notfall und ein Zeitschloss, das nach zwei Jahren Inaktivit\u00e4t einem Erben Zugriff gew\u00e4hrt. Ohne MAST m\u00fcssten alle drei Zweige bei jeder Ausgabe offengelegt werden. Mit MAST bleibt beim Ausgeben nur der tats\u00e4chlich genutzte Zweig plus ein kryptografischer Nachweis (der Merkle-Pfad) sichtbar, die beiden ungenutzten Zweige bleiben f\u00fcr immer verborgen. Das reduziert sowohl die Transaktionsgr\u00f6\u00dfe als auch die Menge an Information, die ein Beobachter \u00fcber die Sicherheitsarchitektur einer Wallet gewinnen kann. Kryptografisch ist die Wahl eines Merkle-Baums dabei kein Zufall: Die Gr\u00f6\u00dfe des Nachweises w\u00e4chst nur logarithmisch mit der Zahl der Bl\u00e4tter, selbst eine Adresse mit hundert alternativen Ausgabebedingungen ben\u00f6tigt beim Ausgeben nur wenige zus\u00e4tzliche Hash-Werte, nicht hundert vollst\u00e4ndige Skripte.<\/p> Technisch verschmilzt Taproot die Schnorr-Signatur und den MAST-Baum zu einem einzigen \u00f6ffentlichen Schl\u00fcssel Q. Dieser ergibt sich aus einem internen Schl\u00fcssel P, der mit einem Hash aus P und der Merkle-Wurzel des Skriptbaums verrechnet (getweakt) wird. Nach au\u00dfen ist Q ein ganz gew\u00f6hnlich aussehender Punkt, nichts an ihm verr\u00e4t, ob \u00fcberhaupt 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\u00fcr den getweakten Schl\u00fcssel Q, und die Transaktion sieht auf der Blockchain exakt so aus wie eine simple Ein-Signatur-Zahlung, ganz ohne Hinweis auf ein m\u00f6glicherweise 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\u00f6rige Kontrollblock und der Merkle-Nachweis offengelegt und ausgef\u00fchrt. 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\u00fcr die Validierung bedeutet, ein Detail, das in Diskussionen um Bitcoins langfristige Skalierung gelegentlich \u00fcbersehen wird. Praktisch bedeutet das: Selbst wer alle Transaktionen einer Adresse \u00fcber 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\u00fcr F\u00e4lle, in denen gar kein sinnvoller Key Path existieren soll, etwa bei reinen Skript-Konstruktionen, definiert BIP 341 zus\u00e4tzlich einen sogenannten NUMS-Punkt (Nothing-Up-My-Sleeve): einen Schl\u00fcssel, der nachweislich aus einer \u00f6ffentlich nachvollziehbaren Konstante abgeleitet ist und f\u00fcr den niemand einen privaten Schl\u00fcssel kennen kann, was ausschlie\u00dft, dass der Key Path heimlich als Hintert\u00fcr missbraucht wird. F\u00fcr Endnutzer sichtbar wird der Unterschied vor allem am Adressformat: Taproot-Adressen nutzen die Bech32m-Kodierung aus BIP 350 und beginnen mit bc1p, w\u00e4hrend SegWit-Adressen (Bech32, BIP 173) mit bc1q beginnen.<\/p> 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\u00fcssel zu pr\u00fcfen. Zus\u00e4tzlich lockert Tapscript einige historische Beschr\u00e4nkungen wie die alte Obergrenze f\u00fcr die Zahl der Opcodes pro Skript, was komplexere Konstruktionen praktikabler macht und Wallet-Implementierungen insgesamt weniger Sonderf\u00e4lle beschert. Wichtiger f\u00fcr die Zukunft ist aber eine andere Designentscheidung: Tapscript reserviert eine ganze Reihe bislang ung\u00fcltiger Opcodes als sogenannte OP_SUCCESS-Codes. Praktisch bedeutet das, k\u00fcnftige Skript-Erweiterungen lassen sich per Soft Fork aktivieren, ohne dass daf\u00fcr wieder ein komplett neues Adressformat n\u00f6tig w\u00e4re. Genau \u00fcber diese T\u00fcr sollen Vorschl\u00e4ge wie OP_CTV oder OP_CAT sp\u00e4ter einziehen, dazu weiter unten mehr.<\/p> Die Aktivierung von Taproot verlief bewusst anders als der sogenannte Blocksize War der Jahre 2015 bis 2017, der schlie\u00dflich zur Abspaltung von Bitcoin Cash f\u00fchrte. 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\u00fcr Taproot einigten sich Entwickler und Miner auf einen Mechanismus namens Speedy Trial: ein vergleichsweise kurzes, rund dreimonatiges Signalisierungsfenster, in dem Miner in ihren Bl\u00f6cken Zustimmung markieren konnten. Weil Taproot als reines Effizienz- und Privatsph\u00e4re-Upgrade ohne kontroverse Auswirkung auf Bitcoins Geldpolitik oder Blockgr\u00f6\u00dfe galt, verlief die Signalisierung praktisch reibungslos: Das Lock-in erfolgte am 12. Juni 2021 im Block 687.284 mit \u00fcber 90 Prozent Zustimmung der Hashrate, die eigentliche Aktivierung folgte turnusgem\u00e4\u00df gut f\u00fcnf Monate sp\u00e4ter am 14. November 2021. Dass eine derart tiefgreifende \u00c4nderung an Bitcoins Kryptografie am Ende so unspektakul\u00e4r verlief, gilt in der Community bis heute als Beleg daf\u00fcr, dass technische Qualit\u00e4t allein nicht ausreicht, ein Konsensverfahren muss auch politisch tragf\u00e4hig sein, eine Lektion, die die aktuelle Covenant-Debatte pr\u00e4gt. Dass Miner \u00fcberhaupt in dieser Form abstimmen, h\u00e4ngt eng mit ihren wirtschaftlichen Anreizen zusammen; wie eng die Margen im Mining-Gesch\u00e4ft mittlerweile kalkuliert sind, zeigt unsere Analyse zu Bitcoins Mining-Margen 2026<\/a>. Wie der Abschnitt zur Covenant-Debatte weiter unten zeigt, ist diese Art von reibungsloser Einigkeit 2026 bei neuen Vorschl\u00e4gen wie OP_CTV keineswegs mehr selbstverst\u00e4ndlich.<\/p>Das Problem vor Taproot: Sichtbarkeit und Ineffizienz<\/h2>
Schnorr-Signaturen: Warum Linearit\u00e4t alles ver\u00e4ndert<\/h2>
MAST: Wie ein Merkle-Baum unn\u00f6tige Daten verbirgt<\/h2>
Key Path und Script Path: Eine Taproot-Transaktion im Detail<\/h2>
Tapscript: Bitcoins erweiterte Skriptsprache<\/h2>
Speedy Trial: Wie Bitcoin 2021 den letzten gro\u00dfen Streit vermied<\/h2>
Adoption in Zahlen: Von der Nische zum Alltagswerkzeug<\/h2>