In general, tx malleability should never happen by accident or when the people making the transactions don't intend it.
Right now it never happens by accident - but it can be non-accidental on the part of somebody who *isn't* one of the people making the transaction. Somebody out there on the network (especially if they're a miner) can deliberately construct a replacement transaction that has a different hash and broadcast that instead of the original transaction. In that case tx malleability happens without the intent of the people making the tx.
And it is this case that current efforts to limit tx malleability are trying to address.
In the usual case, if the person doing it isn't a miner, the replacement transaction has to be the one that reaches more nodes of the network faster, or it won't get relayed. And the original tx has a head-start. A miner constructing modified transactions to put into a block doesn't have this logistical problem. But in the normal case, miners also don't have any motive to do this.
Having a 'canonical form' for transactions, meaning inputs and outputs are in a particular checkable sequence, and only one of the possible key transformations or signature forms can be used - would address the problem. But every possible choice of canonical form to be used would conflict with the way *somebody* is using (deliberate) tx malleability now.
Right now it never happens by accident - but it can be non-accidental on the part of somebody who *isn't* one of the people making the transaction. Somebody out there on the network (especially if they're a miner) can deliberately construct a replacement transaction that has a different hash and broadcast that instead of the original transaction. In that case tx malleability happens without the intent of the people making the tx.
And it is this case that current efforts to limit tx malleability are trying to address.
In the usual case, if the person doing it isn't a miner, the replacement transaction has to be the one that reaches more nodes of the network faster, or it won't get relayed. And the original tx has a head-start. A miner constructing modified transactions to put into a block doesn't have this logistical problem. But in the normal case, miners also don't have any motive to do this.
Having a 'canonical form' for transactions, meaning inputs and outputs are in a particular checkable sequence, and only one of the possible key transformations or signature forms can be used - would address the problem. But every possible choice of canonical form to be used would conflict with the way *somebody* is using (deliberate) tx malleability now.
This is very clear, thanks for the concise answer.
