BIP draft: CISA for Taproot Key Path Spends

The recent discussions from the Bitcoin Development Mailing List highlight significant advancements and proposals in the realm of Bitcoin protocol development, specifically revolving around the use of BIP-459 for full aggregation in transactions. This protocol, accessible at BIP-459, offers a method to recover one of the Elliptic Curve (EC) keys in a CoinJoin-like setup referred to as CISA groups. By resolving a specific equation detailed in BIP-459, programmers can save 32 bytes per group using this method.

This approach introduces a modification to how coefficients are calculated to avoid circular dependencies during verification times when an EC public key is omitted. Instead of using EC public keys to compute these coefficients, there is a proposed shift towards using scriptPubKeys, ensuring security even when the actual public keys aren't visible in the transaction data. However, for cases like P2MR recoverable EC leaf, where multiple keys might be involved, additional measures such as including the control block or its hash need to be incorporated to prevent related-key attacks.

On the efficiency front, various scenarios were analyzed showing how much space savings could be achieved by employing one-key recovery strategies across different numbers of inputs. For instance, a single-input scenario under full aggregation would have the same 65-byte payload as typical non-CISA single-input spends, indicating no additional overhead in the simplest case. Yet, this configuration eliminates the advantage of batch verification across CISA groups, although it maintains verification efficiency within individual groups.

Additionally, another part of the discussion touched upon integrating this proposal with post-quantum cryptographic (PQC) methods, particularly how these developments could influence future aggregated PQ signatures. Two primary paths were debated: tightly coupling CISA with P2TRv2 to encourage migration to PQC-supporting wallets, albeit with potential quantum-vulnerability concerns; or hiding EC public keys behind hashes in the scriptPubKey to enhance security, despite potentially lesser savings in terms of transaction size.

Further feedback and insights were solicited via a mock pull request linked at Fabian's BIP repository, indicating an ongoing process of review and refinement for these proposals. These discussions underscore a pivotal moment in evolving Bitcoin's underlying technology to accommodate more secure and efficient transaction mechanisms while contemplating future-proofing against quantum threats.