Seit dem 11. Februar 2026 liegt mit BIP 360 erstmals ein formal aufgenommener Vorschlag im offiziellen Verzeichnis, der Bitcoin gegen eine klar umrissene Klasse von Quantenangriffen absichern soll. Der neue Ausgabetyp Pay-to-Merkle-Root verzichtet vollständig auf den inneren öffentlichen Schlüssel und bindet eine Adresse nur noch an die 32 Byte lange Wurzel eines Skriptbaums. Damit verschwindet genau jene Information aus der Blockchain, aus der ein ausreichend leistungsfähiger Quantenrechner den zugehörigen privaten Schlüssel rekonstruieren könnte. Die jüngste Fassung der Spezifikation trägt das Datum 24. Juli 2026, aktiviert ist bislang nichts.
Die Sicherheit von Bitcoin ruht auf zwei sehr unterschiedlichen kryptografischen Säulen. Die eine ist die Hashfunktion SHA-256, die den Arbeitsnachweis des Minings absichert und gegen Quantenrechner vergleichsweise robust ist, weil der bekannteste Quantenalgorithmus dort nur einen quadratischen Vorteil liefert. Die andere Säule sind digitale Signaturen auf der elliptischen Kurve secp256k1, und genau hier liegt das Problem. Der Shor-Algorithmus löst das diskrete Logarithmusproblem exponentiell schneller als jedes klassische Verfahren und erlaubt damit die Ableitung eines privaten Schlüssels aus einem bekannten öffentlichen Schlüssel. Die Spezifikation nennt für einen 256 Bit langen Schlüssel eine Größenordnung von rund 10 hoch 8 Quantenoperationen. Eine Maschine, die das leisten kann, existiert nicht, doch die Hardwareentwicklung schreitet sichtbar voran, wie zuletzt ein gefangenes Antiproton als Qubit gezeigt hat, das zwischen zwei Spinzuständen pendelt.
Entscheidend für die Risikoabschätzung ist, wann ein öffentlicher Schlüssel überhaupt sichtbar wird. Bei den älteren Ausgabetypen P2PKH, P2SH, P2WPKH und P2WSH steht in der Blockchain zunächst nur ein Hashwert. Der Schlüssel selbst taucht erst auf, wenn die Mittel ausgegeben werden, und ab diesem Moment ist die Adresse dauerhaft offengelegt. Wer dieselbe Adresse mehrfach verwendet, hebelt diesen Schutz vollständig aus. Zwei Kategorien sind dagegen von Anfang an ungeschützt: die sehr alten P2PK-Ausgaben aus den Anfangsjahren, zu denen die mutmaßlichen Bestände des Erfinders zählen, sowie sämtliche Taproot-Ausgaben, die mit bc1p beginnen. Auch veröffentlichte erweiterte öffentliche Schlüssel, also xpubs, und Wallet-Deskriptoren geben verwertbare Informationen preis. Wer seine Bestände heute schon einordnen will, muss deshalb nicht auf Marktnarrative schauen, sondern auf den Ausgabetyp und die eigene Adresshygiene.
Taproot verbindet in einer Ausgabe zwei Ausgabewege. Der Skriptpfad führt über einen Merkle-Baum aus Blattskripten, der Schlüsselpfad über eine Schnorr-Signatur gegen einen inneren Schlüssel, der mit der Merkle-Wurzel getweakt wurde. Dieser getweakte Punkt steht als 32 Byte langes Zeugnisprogramm dauerhaft in der Blockchain, und zwar unabhängig davon, ob die Ausgabe jemals bewegt wurde. Aus Sicht eines künftigen Angreifers ist eine Taproot-Adresse damit schlechter gestellt als eine klassische Adresse mit Hashschutz, was der breiten Öffentlichkeit bislang kaum bewusst ist. Verschärfend kommt hinzu, dass Taproot inzwischen die Grundlage für zentrale Bausteine des Ökosystems bildet, darunter Zahlungskanäle des Lightning-Netzwerks, BitVM und Ark. Der naheliegende Rat, Taproot einfach zu meiden, würde also einen erheblichen Teil der technischen Weiterentwicklung blockieren.
Aus dieser Zwickmühle folgt die eigentliche Konstruktionsaufgabe. Gesucht war ein Ausgabetyp, der die volle Tapscript-Funktionalität behält, aber die exponierte Schlüsselinformation loswird. Bestehende Alternativen erfüllen jeweils nur die Hälfte der Anforderung: P2WSH ist gegen Langzeitangriffe geschützt, unterstützt aber keine Skriptbäume und keine Blattversionen. Genau diese Lücke schließt der neue Vorschlag, der damit nach Taproot der zweite Ausgabetyp mit Skriptbaum im Netzwerk wäre. Bemerkenswert ist dabei, wie klar die Debatte auf die Signaturebene fokussiert bleibt. Der Energieaufwand des Minings, der in der öffentlichen Wahrnehmung von Bitcoin und anderen Kryptowährungen meist den größten Raum einnimmt, spielt für die Quantenfrage praktisch keine Rolle, weil der Arbeitsnachweis auf Hashfunktionen beruht und nicht auf elliptischen Kurven.
Der neue Ausgabetyp ist ein natives SegWit-Programm der Version 2. Das scriptPubKey besteht schlicht aus OP_2 gefolgt von 32 Byte, und diese 32 Byte sind nicht länger ein getweakter Punkt, sondern unmittelbar die mit dem Tag TapBranch gehashte Wurzel des Skriptbaums. Der innere Schlüssel entfällt ebenso wie der Tweak-Schritt aus BIP 341. In der Bech32m-Kodierung bildet Version 2 auf das Zeichen z ab, weshalb entsprechende Adressen im Hauptnetz mit bc1z beginnen und sich damit auf einen Blick von bc1q und bc1p unterscheiden lassen. Der Kontrollblock im Zeugnis schrumpft von 33 plus 32 mal m Byte auf 1 plus 32 mal m Byte, weil der öffentliche Schlüssel dort nicht mehr mitgeführt werden muss. Das Paritätsbit ist konstant auf 1 gesetzt, die Blattversion ergibt sich weiterhin aus c[0] und 0xfe, was Fehlimplementierungen sofort auffliegen lässt. Wer die Details nachrechnen will, findet die vollständige Spezifikation samt Testvektoren im offiziellen Vorschlagsverzeichnis des Protokolls, das seit Februar öffentlich einsehbar ist.
Praktisch relevant sind die Größenunterschiede im Zeugnis. Ein Schlüsselpfad-Ausgang unter Taproot kommt mit 66 Byte aus, weil dort nur eine Signatur nötig ist. Ein vergleichbarer Ausgang des neuen Typs mit einem Baum der Tiefe 1 benötigt 135 Byte, also 69 Byte mehr, weil Blattskript, Eingabestapel und Kontrollblock mitgeliefert werden müssen. Allgemein liegt der Aufwand bei 103 plus 32 mal m Byte. Gegenüber einem gleichwertigen Skriptpfad-Ausgang unter Taproot spart der neue Typ dagegen konstant 32 Byte ein, und die Validierung ist geringfügig schneller, weil die nötigen Operationen eine echte Teilmenge der Taproot-Prüfung bilden. Eine Änderung vom 18. Juni 2026 verdient besondere Aufmerksamkeit: Bäume der Tiefe 0 gelten ausdrücklich als von jedermann ausgebbar. Wer beim Aufbau einer Adresse also nur ein einziges Blatt ohne Geschwisterknoten verwendet, verschenkt seine Mittel. Die Sicherheitsmarge selbst entspricht mit 128 Bit Kollisions- und 256 Bit Urbildwiderstand exakt dem Niveau von P2WSH.
Die Spezifikation trennt sauber zwischen zwei Angriffsszenarien, und diese Unterscheidung ist der Schlüssel zum Verständnis des gesamten Vorschlags. Ein Langzeitangriff richtet sich gegen Daten, die dauerhaft in der Blockchain stehen, etwa gegen einen offengelegten öffentlichen Schlüssel. Ein Angreifer hat dafür beliebig viel Zeit, solange die Mittel unbewegt bleiben. Ein Kurzzeitangriff dagegen muss innerhalb weniger Minuten gelingen, nämlich in dem Fenster, in dem eine Transaktion unbestätigt im Mempool liegt und ihren Schlüssel bereits preisgegeben hat. Der neue Ausgabetyp löst ausschließlich das erste Problem, und zwar vollständig und ohne dass dafür ein einziges neues Signaturverfahren aktiviert werden müsste. Genau darin liegt der pragmatische Reiz: Der Schutz greift mit heutiger Kryptografie, und frühe Quantenrechner dürften ohnehin viel zu langsam für Kurzzeitangriffe sein.
Für den zweiten Fall bleibt der Weg über postquantensichere Signaturen offen, wobei die Autoren Verfahren wie ML-DSA und SLH-DSA nennen und ausdrücklich auch redundante Kombinationen erwägen. Deren Einbau setzt allerdings einen Ausgabetyp mit Skriptbaum voraus, weil nur dort der Aktualisierungspfad über OP_SUCCESSx zur Verfügung steht, mit dem sich künftig eine postquantensichere Prüfoperation nachrüsten ließe. Diskutiert wurden auch andere Ansätze, etwa Einmalsignaturen nach Lamport oder Winternitz in Verbindung mit OP_CAT, die jedoch bei doppelter Signatur denselben Schlüssel gefährden und damit gängige Praktiken wie Gebührenerhöhungen riskant machen würden. Ebenfalls im Umlauf sind Verpflichtungs- und Aufdeckungsschemata sowie Vorschläge, verwundbare Bestände einzufrieren oder zu verbrennen, was das Autorenteam bewusst aus dem Vorschlag heraushält und stattdessen auf einer eigenen Projektseite zum Vorhaben begleitet, die den Stand der Forschung bündelt.
Der wichtigste Punkt lässt sich ohne jede Protokolländerung umsetzen: Adressen dürfen nicht wiederverwendet werden, und veröffentlichte xpubs oder Deskriptoren sollten als kompromittierbare Information behandelt werden. Wer heute eine reine Schlüsselpfad-Wallet unter Taproot betreibt, kann den Umstieg außerdem bereits konzeptionell vorbereiten, denn die Migration verlangt lediglich den Wechsel auf ein simples Blattskript aus einer 32 Byte langen Schlüsselangabe und OP_CHECKSIG. Für Bibliotheks- und Wallet-Entwickler liegen Testvektoren für die Konstruktion entsprechender Ausgaben und Kontrollblöcke bereit, und die Fassung vom 24. Juli 2026 hat eine Referenzimplementierung in Python ergänzt, während die Varianten in Rust und JavaScript in ein separates Bindungsprojekt ausgelagert wurden. Erste Transaktionen dieses Typs liefen bereits im September 2025 auf einem Testnetz. Bemerkenswert ist der geringe Umbauaufwand, weil der Entwurf bewusst auf bereits erprobtem Taproot- und Tapscript-Code aufsetzt.
Beim Status ist Nüchternheit angebracht. Der Vorschlag trägt die Kennzeichnung Entwurf, setzt die Vorschläge 340, 341 und 342 voraus und wäre als Soft Fork umzusetzen, für den es weder einen Aktivierungsmechanismus noch einen Zeitplan noch erkennbaren Konsens gibt. Knoten, die Version 2 nicht kennen, würden solche Ausgaben als von jedermann ausgebbar einstufen, sie aber weder weiterleiten noch in Blöcke aufnehmen, während ältere Wallets nach den Regeln von BIP 350 immerhin an solche Adressen senden könnten. Den äußeren Zeitdruck liefern derweil staatliche Vorgaben: Die Algorithmensuite CNSA 2.0 verlangt die Umstellung von Software und Netzwerktechnik bis 2030 sowie von Browsern und Betriebssystemen bis 2033, und laut dem Dokument NIST IR 8547 soll Kryptografie auf elliptischen Kurven in US-Behörden nach 2035 nicht mehr zulässig sein. Die Autoren fassen ihre Haltung in einer Formel zusammen, die vorbereitet sein will, ohne Angst zu schüren.