The transaction ID is not assigned by anyone. It is simply a SHA-256 hash of the transaction.
You are Right. But my point was that when it comes to malleability problem, it's the miner that can change the data and cause the transaction to have to a new ID. It's not that anyone can do that (unless the original transaction has been marked as RBF which is a different topic)
Let's say I created a non-RBF and non-segwit transaction and broadcast it to the network. Now I create another transaction with same inputs and outputs, but a different transaction ID.
Will the new transaction be accepted by the nodes? It's so unlikely.
Can the miner change the data, so a transaction with same inputs and outputs but a different ID as the one I had broadcast is included into the blockchain? Yes.
That's also a problem, but spending an unconfirmed UTXO is risk even without transaction malleability.
Right. Especially if the parent has been flagged as RBF.
Strictly speaking, it is a double-spend, but I agree that is not what people normally think of as a double-spend. If you want to get really pedantic, an RBF transaction is also a double-spend.
In RBF, the new transaction can have different outputs and you are right that it's a double-spend. One can easily abuse RBF, if the recipient accept the unconfirmed transaction.
You can abuse transaction malleability only if you are a miner and the unconfirmed (non-segwit) transaction has a child.
If there's no child, there is no way to use malleability bug to scam someone. Because the new transaction will have same inputs and same outputs.
Correct me if I am wrong, please.