OP_CIV - Post-Quantum Signature Aggregation

In a recent exchange among developers on the Bitcoin Development Mailing List, innovative approaches to enhance Bitcoin's transaction efficiency and security were discussed, focusing on stateless address generation and cross-input signature aggregation (CISA). The discussion began with an idea proposed to streamline transactions by assigning every address a unique index and generating a sequence of shared keys. This method entails adding taproot leaves for future addresses during the creation of an address, allowing a deterministic rule that requires no state information for transaction signing. This approach promises to simplify backups since any device with the master seed can compute indices and shared keys without prior wallet state knowledge, assuming it knows the window size N.

Conduition raised concerns about the practicality of committing each script pubkey to previous outputs in the transaction, especially for deterministic backup wallets which constitute a large part of modern Bitcoin usage. They suggested an alternative that involves committing a taptree to a deterministic set of pubkeys, such as those nearest in the same BIP32 account. This would allow for stateless address generation while enabling a single signature to cover all inputs owned by the same entity in a transaction. However, this could significantly impact UTXO privacy due to the stronger common-owner heuristic that would emerge, potentially making ownership more traceable on-chain.

The conversation then shifted towards Post-Quantum (PQ) considerations in signature aggregation, introducing a concept not tied to any specific signature scheme. Given the larger size of PQ signatures, a new method dubbed OP_CIV (OP_CHECKINPUTVERIFY) was proposed. This opcode allows a transaction input to prove linkage to another within the same transaction, essentially saying, "that's the signature I'm using," thereby bypassing the need for its own signature. This proposal aims at reducing the transaction size significantly, which is crucial in the context of post-quantum cryptography where signature sizes are substantially larger.

Implementation challenges were noted, particularly concerning deterministic wallets' ability to recover keys without knowing which pubkeys pointed to which UTXOs. Solutions such as limiting the number of OP_CIV scripts or including scripts pointing to already spent TXOs were discussed to mitigate recovery issues. Additionally, concerns about address reuse and replay attacks were addressed, noting that OP_CIV points to outpoints rather than addresses or keys, minimizing these risks.

The potential for other applications of the OP_CIV opcode was also mentioned, highlighting its utility beyond just making PQ transactions smaller. Its introduction into Bitcoin's opcode set could enable new types of contracts and transactional proofs, making it a versatile tool for future development. A real-life example of OP_CIV commitments was shared through a link to a TABConf talk, inviting further discussion and feedback on the proposed ideas.