Not a very precise question, but I'll try. The abandoned
BIP62 lists ways in which a Bitcoin transaction is malleable:
- Non-DER encoded ECDSA signatures: I don't think this is an issue since all signatures are DER encoded (BIP66)
- Non-push operations in scriptSig Any sequence of script operations in scriptSig that results in the intended data pushes, but is not just a push of that data, results in an alternative transaction with the same validity.
- Push operations in scriptSig of non-standard size type The Bitcoin scripting language has several push operators (OP_0, single-byte pushes, data pushes of up to 75 bytes, OP_PUSHDATA1, OP_PUSHDATA2, OP_PUSHDATA4). As the later ones have the same result as the former ones, they result in additional possibilities.
- Zero-padded number pushes In cases where scriptPubKey opcodes use inputs that are interpreted as numbers, they can be zero padded.
- Inherent ECDSA signature malleability ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it.
- Superfluous scriptSig operations Adding extra data pushes at the start of scripts, which are not consumed by the corresponding scriptPubKey, is also a source of malleability.
- Inputs ignored by scripts If a scriptPubKey starts with an OP_DROP, for example, the last data push of the corresponding scriptSig will always be ignored.
- Sighash flags based masking Sighash flags can be used to ignore certain parts of a script when signing.
The point of all these is that when a node creates a transaction, hashes it locally and sends it into the network, another node can receive the transaction, change it in some of the ways listed above and send it along. The change will not affect the result of the transaction but it will change it's hash. That is why you can't trust a transation hash until it is included in a block. SegWit fixes all this.
I hope this answers your question.
