The BIP draft explained that the txid will strip the 'malleable parts', but it wasn't clear what data would be used to calculate the normalized txids and how this change would apply retroactively. The concern was raised about the reuse of pubkeys (addresses) which could result in a lack of unique normalized txids and protection against replay attacks. While the issue is covered, the question was asked about how this would work in simpler terms. The SCRIPT_CHECKSIGEX_NORMALIZE could have been better explained in the document. A question was also asked whether it would fix > third level malleability (a tx which spends from another unconfirmed tx which spends from yet another unconfirmed tx).Christian Decker via bitcoin-dev replied that, as with the previous version using a hard-fork, the normalized txid is computed only considering the non-malleable parts of a transaction by stripping the signatures before computing the hash of the transaction. It was clarified that the proposal is recursive starting from the coinbase transaction and the rule is that txids are what they would have been if n-txids had been used right from the start.