Segwit commitment to post-quantum witness data?

The discussion revolves around the intricacies of blockchain transaction processing and how data within a transaction, particularly witness data, is weighted and accounted for in terms of computational cost. One proposed method involves applying different weight formulas to various types of authorization data. For example, legacy transactions retain a 1:1 weighting while segwit adjustments offer a 1:4 weighting. Future modifications could introduce new weightings for other data types like pqdata.

Further complexities arise when considering the management of different data types within a single witness type. This setup might require maintaining track of data types throughout script execution, which adds an additional layer of complexity but is deemed feasible. Another suggestion includes redesigning the scripting language to streamline processes. This would involve the witness stack containing sequences of public key and signature pairs, with upfront checks and subsequent assertions related to the signing authority.

Cost accounting in this context should ideally be a monotonic function based on input/output costs, storage and bandwidth requirements, and CPU usage. Each component has its own dynamics; for instance, I/O costs are constant due to UTXO lookups, storage costs correlate with serialized witness size, and CPU costs depend on executed opcodes. A potential design could simplify the witness stack to just include a declared computation budget and script input data, with each witness type having its own formula to map these elements to weighted units (WU).

Additionally, the concept of annex entries in transactions was explored as a means to extend transaction capabilities without altering existing authorization encodings or weightings. These annexes could handle specific needs like per-input locktimes or conditions based on blockchain height, independent of the main transaction data. The possibility of allowing multiple annexes per transaction input was suggested to reduce complexity, contrasting with encoding everything into a single witness style. This approach distinguishes between protocol-level serialization and script-level functionality, potentially streamlining future developments and adaptations in blockchain technology.