Likelihood of transaction hash mutating with current state of BIP062

[No_2]

From what I understand most of BIP062 is now implemented via soft fork. And have read on some posts that transaction malleability could be completely eliminated within the next few years.

...
But, I believe it will take a minimum of two years remove malleability.
...

I hope my question is not too open ended but what forms of normal activity and also attack can still currently occur on the Bitcoin network to cause transaction hash to mutate? I’m trying to get an idea of how likely it is currently to have a transaction mutate or how easily an attack can be levied to mutate a transaction, if a user is broadcasting a transaction they do not want mutated.

I understand once BIP062 is fully implemented transactions could still be optionally created to allow malleability but the default client state for Bitcoin Core will be to create transactions that cannot undergo malleability. Is this correct?

Will malleability ever be totally eliminated?

[gmaxwell]

From what I understand most of BIP062 is now implemented via soft fork

Not so. There have been no soft forks related to that yet.

Will malleability ever be totally eliminated?

No. It is an intentional and useful feature, without it things like lighthouse would not be possible

[TierNolan]

Will malleability ever be totally eliminated?

No. It is an intentional and useful feature, without it things like lighthouse would not be possible

That presumably depends on the definition of malleability?  

Payment channels use entirely new transactions that are signed by their private key holders.  Malleability normally means tweaking transactions to give a different transaction hash but without needing the private keys.

[Edit]
The OP_LOCKTIMEVERIFY soft fork would fix things too, right?

[DeathAndTaxes]

None of the BIP62 rules are currently in consensus rules (although one rule is currently being 'voted' on by miners).  Most of the checks are part of the IsStandard() check and transactions which violate them will not be relayed by default but are still valid and can be included in a block.

These flag names in the bitcoin source code correspond to the seven BIP62 rules.  It might make it easier to locate the relevant code blocks.
Rule 1 - SCRIPT_VERIFY_DERSIG
Rule 2 - SCRIPT_VERIFY_SIGPUSHONLY
Rule 3 - SCRIPT_VERIFY_MINIMALDATA
Rule 4 - SCRIPT_VERIFY_MINIMALDATA
Rule 5 - SCRIPT_VERIFY_LOW_S
Rule 6 - SCRIPT_VERIFY_CLEANSTACK
Rule 7 - SCRIPT_VERIFY_NULLDUMMY

Status as of v0.10 and current block
Rule 1 - Insufficient miner votes for soft-fork *
Rule 2 - Not Enforced +
Rule 3 - IsStandard **
Rule 4 - IsStandard **
Rule 5 - Not Enforced +
Rule 6 - IsStandard **
Rule 7 - IsStandard **

*   https://github.com/bitcoin/bitcoin/blob/93a8c46807a8b9c98e536ccd21ecdb11b9b3cf52/src/main.cpp#L1791
**  https://github.com/bitcoin/bitcoin/blob/f425050546644a36b0b8e0eb2f6934a3e0f6f80f/src/script/standard.h#L47
+   Unless I am missing something these are not enforced by IsStandard checks for relaying (although standard txns created by bitcoin core will pass these rules)

[No_2]

So transaction malleability is useful and currently cannot be avoided but the Bitcoin devs are proposing a way to enforce that some transactions cannot be mutated? With these new enforcement rules to be phased in over the next few years. Have I understood this correctly?

[gmaxwell]

cannot be mutated

by third parties.

[CIYAM]

Will malleability ever be totally eliminated?

No. It is an intentional and useful feature, without it things like lighthouse would not be possible

Can you explain this?

(without resorting to anything that can't be clearly understood by most people)

[gmaxwell]

Can you explain this?
(without resorting to anything that can't be clearly understood by most people)

The pledges model used for lighthouse is that you author a transaction paying you some amount but not supplying the coins, then people can supply signatures for their coins at their leisure and they can be merged by anyone in any order without interaction. Once enough coins are provide the transaction can go through.  These additional signatures are modifications of the transaction.

We have the sighash flags specifically to _allow_ malleability.

Absent this, you'd need something more like a realtime coinjoin server; which is much less usable; all the users would have to agree in advance on all the participants and all be online at basically the same time, and all would have to coordinate through a server, and if anyone dropped out before signing the process would have to restart.

[Cryddit]

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. 

[No_2]

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. 

This is very clear, thanks for the concise answer.