So I am trying to get my head around the issue. Correct me at each point where I am wrong.
Ok, I'll try.
From what I understand, if a tx is sent, someone can change a portion of the txid before it confirms
True.
- the signature maybe?
Possibly, but more often it is non-signature portions of the ScriptSig
I thought the txid just becomes invalid
Well, I suppose you could say the original txID is "invalid", really it's just different. I guess it's going to depend on what we mean by "invalid".
however I read people can use it to withdraw and say it never worked, when really it did and get the bitcoins back.
Only if the entity you are withdrawing from is unaware of transaction malleability, relies on the transaction ID to determine if a transaction exists, and has horrible accounting protocols. (Or if they are aware of malleability and are just incompetent).
Can someone summarize it simply please ?
Imagine you send transactions to customers, and are unaware of transaction malleability. Each time you send a transaction, you write down on a sheet of paper amount that the transaction was supposed to send, the address it was supposed to go to, and the transactionID that you generated before you broadcast it. Then you give the customer a piece of paper with the same information on it.
Now, a couple of days later, one of your customers comes to you and says, "I never received the bitcoins that I requested, here's my receipt." You take a look at the transactionID on the receipt, and you match it up to the list that you keep. You see that all the information on the customer's receipt matches all the information on your list, so you decide that the customer is presenting you with a transaction that you expect to have sent. Next you search for that transactionID on the blockchain. You don't find it at all. You also find that the transactionID doesn't exist in the memory pool of any peers either. You assume that something must have gone wrong with the transaction, and that your customer never received their bitcoins. In the interest of maintaining good customer relations, you send a new transaction transferring the same amount of bitcoins to the customer.
What you didn't realize was that the customer actually did receive the earlier transaction, but the transactionID changed. Since you didn't know this, you didn't think to look for any alternate transactionID's that sent the same amount of bitcoins at the same time using the same inputs. Now your second transaction confirms. Your customer just got paid from you twice for the same bitcoins in their "account" on your system.
Your customer, realizing that he just discovered a way to steal money from you without you knowing quickly learns how to create malleated transactions. He signs up for multiple false IDs on your system and tells some of his friends about it. They all repeat this processes on an occasional basis. You continue to send more and more bitcoins out of your system without noticing the drastic reduction in bitcoins on hand.
Eventually one day someone points out this transaction malleability issue to you and you decide to audit your accounts to see how short you are.
This is one example of how someone can take advantage of transaction malleability.
There are a few other ways, but the basic concept is the same (relying exclusively on original transactionID to determine if a transaction exists in the bitcoin network).
Also if the exchanges had to change their software to deal with this, does that no mean all merchants and clients need to as well ?
That really depends on how often you send bitcoins, and what process you use to track those bitcoins. Some exchanges used their own custom code to track withdrawals. That custom code may not have been aware of this issue and may have needed to be updated to look at spent inputs (or some other unmodifiable portion of the transaction). If you are just using one of the well known wallets, and always wait for at least 1 confirmation before sending any bitcoins anywhere then you shouldn't have a problem.
