Segwit commitment to post-quantum witness data?

[conduition]

OK, finally got around to reviewing the whole thread. A few things:

1. PQ signature data should be covered by the block hash. Even with SNARKs, having a commitment to PQ signatures which is covered by the block hash will be an easy win for validation caching and avoiding transaction malleability. If we ever deploy SNARK aggregation (see this thread for further discussion on that topic), the SNARK can simply prove the signatures were properly committed into the block, and at least with hash-based signature SNARKs this would cost at most a marginal increase in proving time. So yeah, disregard my last messages basically
2. Don’t discount non-signature data. While CRQCs change a lot of things, I don’t think they change the costs of script validation outside of signature schemes, so i don’t see any good reason to change the block weight cost of scripts or preimages or other non-signature witness data (yet). Narrowly discounting only signatures also makes it easier to commingle different cost functions for different signature schemes (see below), and improves “JPEG-resistance” because only valid signatures receive the new discount.
3. Users must be able to mix/match signature algorithms. There are a number of use-cases which benefit from hybrid multisignature wallets, that leverage two or more distinct signature schemes in the same spending path. The costing system must be able to account for such edgecases. I’m pretty certain this means the accounting system must drill down into the script level, where CHECKSIG operations are invoked.
4. Transaction weight calculations should be easy. Software should not need to dynamically analyze scripts to figure out how many weight units a transaction consumes.

I have some rough ideas for designs which fulfill the above properties, but first, what do you guys think of these requirements?

---

@sipa

I could imagine a design where the witness stack consists of just (a) a declared computation budget number (used by the opcodes in the script) and (b) script input data. Each witness style is then a formula for mapping the (computation budget, script input size) to WU. Newly introduced opcodes can have new/different computation cost from existing one without needing a new witness style. It is only when the formula changes, so practically when the cost per script input byte changes, that a new style is needed. Perhaps with such a design, a single style per txin suffices?

This sounds a lot like the varops budget proposal for GSR, except IIRC in GSR the budget is fixed based on the size of the serialized transaction, whereas you’re suggesting the budget is declared up-front, e.g. in a new witness field. Personally I like the up-front declaration more, as it gives senders better flexibility and discourages padding transactions to boost the budget. Kinda reminds me of Ethereum’s per-TX “gas limit” field.