PQC output type discussion

The discussion revolves around the integration of CISA with P2TRv2 and its potential implications on the deployment and adoption rates prior to Q-day. There is a consideration that bundling CISA with P2TRv2 could delay the latter's rollout due to the need for consensus validation rules required by CISA, which might not be fully developed yet. This delay could potentially slow down adoption rates more significantly than any fee incentives could encourage them.

Furthermore, there is an acknowledgment of the appeal of an output type supporting post-quantum cryptography (PQC) while also being cost-effective, despite current preferences for other types like P2MR. The necessity for a new witness extension becomes evident if Q-day leads to the widespread use of hash-based signatures. Such an extension would accommodate larger serialized block sizes that might result from different costing rules for witnesses.

The email also touches upon various technical solutions to address the challenges posed by larger block sizes and signature data. One such solution is the use of Forward Error Correction (FEC) techniques to allow nodes to store only a fraction of each block, thus reducing individual storage requirements while still ensuring complete data recovery through collaborative node interaction. Moreover, the possibility of implementing SNARK aggregation post-mining is considered to reduce long-term storage impacts and speed up Initial Block Download (IBD).

The complexities of network operation in terms of bandwidth and CPU costs for transaction validation are significant concerns. These factors are crucial for maintaining synchronization across the network, affecting both miners and nodes. It is pointed out that extensive signature aggregation might not influence the efficiency of mempool transaction relay, and hence any new protocols should carefully consider the balance between performance enhancements and increased resource demands.

Finally, the potential reparameterization of SHRINCS to target lower computational costs per byte is discussed as a way to adapt to a new pricing model for block data introduced by a witness extension. This approach could justify increases in block size without disproportionately escalating CPU costs during signature validation, emphasizing the versatility and configurability of hash-based signature schemes.