5) before it's confirmed, Vendor A changes the txid (using malleability)
6) Vendor A broadcasts this transaction to the bitcoin network
7) Since, the inputs are the same, bitcoin network code sees this as a double spend
8 ) bitcoin marks the orignal transaction as dead (no miners will include it in a block)
9) SR2 escrow receives notification that the oridinal txid is dead
Why does the network invalidate the original transaction and confirm the second? Does that happen every time, the newer transaction with the same inputs wins? That does seem like a flaw in the protocol if that is the case.
Vendor A (the attacker) sends the cloned tx to a different node in the network, before that node sees the original tx. There are now two txs in the network, and there is no way to tell which one is newer (because the timestamps are exactly the same). There is some luck involved, as the attacker can't guarantee that his cloned transaction will be confirmed in a block (or seen by more nodes) before the original tx, but the attacker can just keep trying with multiple withdrawals.