Quote from: Endlessa on February 14, 2014, 08:33:46 AM

Quote from: sgk on February 14, 2014, 04:35:03 AM

Come on! How does a malleability attack steal their all coins 'SLOWLY' and they don't notice it until all of them are gone?
They stole the coins themselves and took advantage of the malleability situation as an excuse.

Ok, I'll bite. In this scenario there are two ledgers. One is the bitcoin block chain and the second is SR2 escrow service.

The interacton/use case goes like this:

1) Vendor A withdraws some money from SR2 escrow
2) the SR2 escrow sends a payment to the bitcoin P2P network
3) SR2 escrow records the payment's txid in it's database
4) waits for confirm (a miner to include it in the block)
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
Note: this where all the websites are changing their code base, like SR2 should have when the ~~bug~~ exploit was discovered>
10) SR2 escrow credits the vendors account for the "dead" funds, believing they are still in the escrow wallet (escrow ledger is now out of synch)
11) the malleability transaction gets confirmed by miners
12) Vendor A now owns those bitcoins
13) Vendor A now goes into the SR2 escrow service and requests payment again
14) Vendor A is now at step 1 again and continues until the escrow wallet is no longer able to fulfill withdraw requests
14a) Process complete: SR2 sends out a sad message about their wallet being empty

so yes you can lose BTC with transaction malleability.

How do you defeat this?

There are several ways:

you send a request to the network for transactions on your wallet address and look to see if there are any between you and Vendor A on the network (check that the inputs aren't still in use)
Flag the account for human intervention/review when fraud conditions are met
Re-use the same inputs, so if there is another transaction (mutant) the network will not allow the double pay

or

use multi-sig transactions with the SR2 service acting as the "Oracle" (What SR2 is talking about in the sad message)

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.