How is Transaction malleability affected by SIGHASH flags?

Question

SIGHASH flags allow for the flexible alteration of a transaction.

Given that there are legitimate usages of SIGHASH, and changing a Tx (and presumably the TxID as well), what is the correct way of using Sighash w.r.t. a TxID and tracking its progress?

What malleability risks do SIGHASH transactions incur by virtue of their usage?

Answer 1

SIGHASH flags allow for the flexible alteration of a transaction.

Yes, but the SIGHASH types mainly allow for incremental progress towards creating a full/final transaction, such as combining multiple transactions signed with SIGHASH_SINGLE. Once the transaction is fully created, there are certain tweaks that can be done to it that don't invalidate the tx but change the TxID, and these tweaks can be done regardless of how it was signed.

What malleability risks do SIGHASH transactions incur by virtue of their usage?

I think the SIGHASH signing types allow for the alteration of transactions before they are final. Once a transaction is final, the malleability issues persist regardless of how it was signed. In fact, ECDSA signing itself (regardless of which SIGHASH type is used) is non-deterministic, so you could sign the same transaction twice and distribute them, and they would both be valid (but conflicting), but have different TxIDs.

Given that there are legitimate usages of SIGHASH, and changing a Tx (and presumably the TxID as well), what is the correct way of using Sighash w.r.t. a TxID and tracking its progress?

To track a transactions progress, you will probably need some other way to identify the transaction other than the raw TxID (double hash of tx data). i.e. Some number associated with a transaction that is passed around to all who are editing it, or keeping track of the outputs of the transaction.