Alle News durchlaufen eine strenge Faktenprüfung und werden von Blockchain-Experten sowie erfahrenen Brancheninsidern verfasst und redaktionell geprüft.
- Bitcoin Entwickler haben BIP-360 offiziell veröffentlicht. Es schlägt P2MR vor, einen Taproot-ähnlichen Output ohne „Key-Path“.
- Bitcoin Entwickler haben damit vor allem ein Risiko im Blick: Wenn ein Public Key lange öffentlich ist, könnte ein künftiger Quantencomputer daraus den Private Key berechnen.
Eine aktualisierte Fassung von BIP-360 ist ins offizielle Bitcoin-BIP-Repository auf GitHub gemergt worden. Der Entwurf („Pay-to-Merkle-Root“, P2MR) schlägt einen neuen Output-Typ per Soft Fork vor: Taproot-Logik über Tapscript und Script-Trees bleibt im Kern erhalten, aber der Key-Path-Spend fällt weg. Genau dieser Key Path gilt im Quanten-Kontext als Schwachstelle.
Kurz gesagt: P2MR ist „Taproot ohne Key Path“. Der Output committet nur noch auf die Merkle-Root eines Script-Trees (32 Byte) und nicht mehr auf einen internen Key. Wer so einen Output ausgibt, kann das daher nur noch über den Script Path tun, ein Key-Path-Spend existiert schlicht nicht mehr.
Erster Schritt zur Bitcoin-Quantensicherheit
Der Draft setzt dabei sehr bewusst an einem bestimmten Bedrohungsmodell an: sogenannten „Long-Exposure“-Angriffen. Gemeint sind Situationen, in denen Public Keys oder Spend-Skripte so lange offen liegen, dass ein zukünftiger „cryptographically relevant quantum computer“ mit Shor private Keys aus Public Keys ableiten könnte. P2MR soll genau dieses Risiko bei Elliptic-Curve-Kryptografie entschärfen – nicht mehr, aber auch nicht weniger.
Für „Short Exposure“, also Fälle, in denen ein Public Key nur kurzzeitig (etwa im Mempool) sichtbar ist, reicht P2MR laut Text nicht aus. Dafür könnte es später Post-Quantum-Signaturen in Bitcoin brauchen. Die Autoren deuten dafür einen separaten Vorschlag an, allerdings erst nach weiterer Forschung.
Wichtig ist auch die Umsetzung: BIP-360 ist als Soft Fork angelegt und soll bestehende Taproot-Outputs nicht anfassen. P2MR läuft über SegWit v2 (Bech32m); entsprechende Mainnet-Adressen würden mit bc1z beginnen.
Ohne SegWit-v2-/P2MR-Support verstehen Nodes und Wallets diese Ausgaben nicht. Der Draft erinnert außerdem daran, dass nicht aktualisierte Nodes SegWit-v2-Outputs grundsätzlich wie „anyone-can-spend“ behandeln, sie aber in der Praxis typischerweise weder relayen noch minen.
Der Preis für die zusätzliche Härte im Long-Exposure-Modell ist ziemlich konkret: P2MR tauscht den schlanken Taproot-Key-Path gegen einen Spend, der immer „Script Path“ ist – und damit auch immer wie „Script Path“ aussieht. Bei einer einfachen Beispielrechnung ist ein minimaler P2MR-Witness 37 Bytes größer als ein Taproot-Key-Path-Witness (nur Signatur).
Mit tieferen Script-Trees wächst der Overhead um 32·m Bytes (m = Merkle-Tree-Tiefe). Umgekehrt ist P2MR gegenüber einem äquivalenten Taproot-Script-Path-Spend 32 Bytes kleiner, weil im Control Block kein interner Public Key mehr mitgeschleppt werden muss.
Auch beim Thema Privacy ist der Trade-off eher nüchtern: Wer P2MR nutzt, signalisiert beim Spend zwangsläufig „Script Path“, weil es keinen Key Path mehr gibt. Das ist weniger “Leak” als ein strukturelles Merkmal, aber es ist ein sichtbares Merkmal.
Als Autoren nennt BIP-360 Hunter Beast, Ethan Heilman und Isabel Foxen Duke. Anduro, ein forschungsorientiertes Unternehmen, das an quantenresistenten Ansätzen für Bitcoin arbeitet, kommentierte auf X:
“Bitcoin hat einen wichtigen Schritt in Richtung zukünftiger Quantenresistenz gemacht. […] Das BIP geht auch auf die Kritik ein, dass Bitcoin-Entwickler die Quantenbedrohung nicht ernst nehmen.“
Die nächste spannende Phase beginnt ohnehin erst nach dem Draft-Status. Wenn BIP-360 weiterkommt, dreht sich die Debatte vermutlich weniger um das Grundprinzip „Taproot ohne Key Path“ – sondern um die Anschlussfragen:
Wie adressiert Bitcoin Short Exposure? Welche Post-Quantum-Signaturen sind realistisch? Über welchen Upgrade-Mechanismus läuft das sauber? Welche Opcode-Strategie ist praktikabel? Und vor allem: Wie bekommen Wallets und Nutzer eine Migration hin, die in der Realität nicht an UX, Koordination und Trägheit scheitert?
