Was erschwert die Implementierung von Cross-Input-Signaturaggregation? Warum hat es es außer aus Gründen des Design Space nicht in BIP-Taproot geschafft? (Schlüsselaggregation innerhalb einer Eingabe kann mit MuSig, MuSig2 usw. erreicht werden, aber Signaturen können mit BIP-Taproot nicht über verschiedene Eingaben hinweg aggregiert werden.)
Darauf antwortete Pieter Wuille auf Twitter .
Die wichtigste Komplikation der Cross-Input-Aggregation wird in diesem Bitcoin-Entwickler-Mailinglisten- Beitrag von AJ Towns erläutert.
TL;DR: Wenn Softforks ändern, welche Signaturen überprüft werden, dürfen sie nicht ändern, was zusammen aggregiert wird. Dies ist besonders kompliziert, wenn sie mit dem OP_SUCCESSx-Upgrade-Mechanismus von BIP341 interagieren, der es zukünftigen Softforks leicht ermöglichen könnte, die Skriptsemantik vollständig zu ändern. Hier gibt es nichts grundsätzlich Schwieriges – es ist nur technische Komplexität, um sicherzustellen, dass alles gut zusammenarbeitet.
Pieter fügte bei einem Londoner BitDevs Socratic Seminar zu BIP-Taproot hinzu:
Graftroot und Cross-Input-Aggregation sind solche tiefgreifenden konzeptionellen Änderungen. Sie können nicht zulassen, dass sie später gebaut werden. Es ist eine solche strukturelle Änderung der Funktionsweise von Skripten. Diese Dinge können nicht einfach später zu Taproot hinzugefügt werden. Sie brauchen einen Nachfolger. Cross-Input-Aggregation, das Konzept der Skriptverifizierung ist nicht länger eine Sache pro Eingabe, sondern eine Sache pro Transaktion. Sie können es nicht mit optimaler Effizienz tun, ich denke, Sie können Dinge erfinden. Die Art der eingebauten Erweiterbarkeit sind neue Opcodes, neue Arten von öffentlichen Schlüsseln, neue Sighash-Typen, all diese Dinge werden ziemlich einfach gemacht und haben fast keine Nachteile, verglichen mit einer nicht sofortigen Ausführung. Echte strukturelle Änderungen an der Skriptausführung, sie brauchen etwas anderes.
nilskp
Michael Folkson
Michael Folkson