One general point for discussion. (Fixed length sighash with positions for fields)

• We observed that having a fixed length sighash with a fixed location for which field occurs where is super helpful in creating complex scripts easily.
• Even though we will new opcodes for getting these directly, it might still be useful to have a structured sighash.
• The only fields with variable length are assetIssuance and nValue( assetIssuance internally uses confidential value serialization). So, everything can be addressed if we fix the serialization of explicit in nValue.

Note that we don't need to change the way serialization is done for these fields in p2p network, but only when we do sighash computation.
Downsides:

• more code complexity
• more divergence from core

We could add zeros to the hash after nNonce nAmount and nAsset such that they'd always total out to 33 bytes. And same for the fields in the issuance.

I don't think this is too much added complexity and it would give you, as you say, fixed-offset fields in the sighash. I can certainly imagine that being useful for a covenant which is trying to fix one piece of the sighash while not touching anything else.

We would still have a variable-length encoding based on the sighash flag, and I don't think there's any reasonable way to avoid that (the different flags mean you're hashing different data). But it's easy to fix/check this flag since it appears on the siganture itself, not only inside the sighash.

Do you think we should 0-pad so that the issuance data field is always 130 bytes even if there is no issuance? This adds two full sha2 compressions (at about 200ns/shot on a desktop CPU) and will rarely be nonzero.

We should compare this overhead to normal signature validation?

If we still want to maintain length index prefixing, we could change the order in which we do the sighash. We could all the input specific things at the end of the sighash.

Normal signature validation is 50us. So an added .5us is a 1% performance hit.

I'd rather not change the order of the sighash too much to minimize the cognitive load for people coming from Bitcoin.

There is also variable length introduced by the presence/absence of the annex. If you are interested in resolving that, then you should pad the annex hash in the case that there is no annex.

Should be (82--130) instead of (74--130)? The minimum size is 2 explicit values + 2 32 bytes = 18 + 62 = 82

The inflationKeys field can be null, in which case it is one byte.

I wonder if we should replace this "shifted by 24 bits" language with an explicit list of cases. In both Elements Core and rust-elements, the prevout stored internally does not actually have these bits set; they are extracted during deserialization and recorded separately.

However you want is fine. I phrased it this way to be forward compatible with new flags that might be added in the future.

Yeah, that sounds reasonable. Let's keep the existing text.

we can remove the <ref>...<ref> here and below. Alternative we could add a reference section below, but I don't think that is preferable.

I think it is preferable for all these NEW statements to be their own paragraph.

Good catch, I'm sure that was my intent but I guess I didn't look at the rendered version too carefully.

masked version excluding outpoint flags.

output index excludes the outpoint flags.

needs a (NEW) before the word extended.

needs a (NEW) before the word extended.

I might prefer a term like "padded CTxOut format" or something rather than "extended". To me "extended" conveys that it has more fields. However it isn't a big deal.

slight preference for this to read ", in padded format". And below too.

I counted 442 bytes. Anyone want to count again?

I think this is not updated with the latest numbers after we removed nNonce. Recalculating the numbers

It's 410/334 for ACP/non-ACP according to my calculations/implementation. Are you taking into consideration the 32-byte annex too?

I was including the annex.