BIP draft: CISA for Taproot Key Path Spends

This methodology introduces a new witness version that supports Taproot-style key path spending, enabling various inputs within a single transaction to aggregate their signatures. Each input can choose from half-aggregation, full-aggregation, or opt-out using a specific marker byte in its witness, as detailed in BIP 458 and BIP 459 which respectively outline these aggregation schemes. This flexibility offers enhanced efficiency in signature processing while maintaining the traditional script path spending as set by BIP 341/342. For those interested in further details or contributing to the proposal, the draft is available here, with an ongoing discussion facilitated through a mock pull request accessible here.

The dialogue surrounding this BIP also touches on the integration challenges and potential conflicts with existing proposals, notably the reserved segwit version 2 and its overlap with BIP-360. A focal point of concern is the compatibility of aggregated signatures with future Post-Quantum Cryptography (PQC) mechanisms, assuming a viable PQC signature algorithm emerges. The current setup, which places a bare Elliptic Curve (EC) public key directly in the script-pubkey, complicates the use of Boris' EC recovery trick due to signature aggregation preventing individual public key recovery. Proposed solutions include closely integrating Current Implementer SigAgg (CISA) with P2TRv2 or concealing the EC public keys behind a hash in the ScriptPubKey (SPK). These options weigh the trade-offs between security enhancements and impacts on transaction witness weight, highlighting the complexities of aligning advanced cryptographic techniques with blockchain protocols.

Further discussions initiated by Fabian via the mailing list reveal a deeper dive into the technical structuring required for PQ scenarios within the Bitcoin framework. Despite his initial lack of extensive study in PQ cryptography, Fabian expresses readiness to explore this area more thoroughly, given the publication of the proposal. He discusses the necessity of new witness versions and output types for full implementation in a PQ setting, alongside strategic considerations for the network’s adaptation to Cryptographically Relevant Quantum Computers (CRQCs). The discourse also reflects on potential network strategies in anticipation of significant shifts prompted by quantum computing developments, emphasizing the importance of consensus on the timeline and impact of such technologies. For a more detailed exploration of Fabian's responses to specific comments, refer to the GitHub discussion.