What the "average user" needs to know about Transaction Mutability

[kellrobinson]

blockchain.info, not blockchain
and from what little I know, it sounds like a bit of a kluge

[1715691003]

1715691003

[1715691003]

1715691003

[JonesL]

from mtgox

"Thanks to our friends at Blockchain.info, MtGox now has a workaround that will
use a unique identifier created by Blockchain to show whether transactions have
been modified or not. This will prevent any fraudulent use of the malleability
issue and protect the assets of our customers"

Blockchain was definitely down several times recently, doing "maintenance"

That said, all exchanges should be subjected to the same issue. Like a vulnerability that was exploited in mtgox but other exchanges should have their turn if they din fix it up.

[tvbcof]

from mtgox

"Thanks to our friends at Blockchain.info, MtGox now has a workaround that will
...

Heh.  I wonder if this means that Mark will be giving Ver his coins back

[virtualmaster]

Does it have something to do with transaction malleability or they are completely different issues without any connection ?

[sshapiroNJ]

Thanks for the good information, but I still didn't get who loses?

[un_ordinateur]

Thanks for the good information, but I still didn't get who loses?

That's the point: NOBODY loses. It's more of a nuisance, because the id of transactions is changed before being accepted. But the coins get accepted. If people rely on those id to know if a transaction was accepted, they might be lead to believe that the transaction failed, EVEN if the transaction in fact went trough.

That is a minor nuisance in case of the standart client, because the client sometimes used the "change" of an unconfirmed transaction you sent as an input of another transaction. If the transaction is mutated before it is accepted, then the second transaction will fail, and you'll have to send it again. Also the standart client may be confused by mutated transactions, and show a given transaction twice. But it is a display error, not a protocol error. And it sorts itself out when the transaction confirms.


NOW, if people act stupid, THEN it might be more of a problem.

MtGox relied on transaction ID to check if a user withdrawal went trough. Some users complained that their withdrawal failed (even if it had not), and because it had mutated, MtGox tought that the transaction failed too. So they sent the coins again, and NOW lost some coins. IF they had checked their balance, IF they had checked the spent status of the inputs, they would have noticed the user lied, and should not send the coin.

MtGox lost coins, but it is their fault. It was not a protocol failure, not a double spend; it was a double send.


ALSO, it -might- have happened that a merchant accepting unconfirmed transactions as payment might have lost some coins. Merchants should never do that, but many did for small amounts. For most cases, it is not a problem: even if the transaction mutates, the merchant gets the money. HOWEVER, if the merchant was foolish enough to accept an unconfirmed transaction taking as input the output of another unconfirmed transaction, THEN if the first transaction mutates, the second fails.

THERE IS NO REPORT of someting like that having happened. But it is a theorical possibility.


It must be repeated: The protocol is OK. There is no bug. It was NEVER build with txid immutability in mind. NOBODY should have relied on that. It was a design choice. A bad choice? yes. If they "re-did" the protocol today, the txid would be immutable. But it is too late for that, we must work around it.

[DeathAndTaxes]

Does it have something to do with transaction malleability or they are completely different issues without any connection ?

It is the same thing.  See the bottom of the OP.

[DeathAndTaxes]

It must be repeated: The protocol is OK. There is no bug. It was NEVER build with txid immutability in mind. NOBODY should have relied on that. It was a design choice. A bad choice? yes. If they "re-did" the protocol today, the txid would be immutable. But it is too late for that, we must work around it.

I wouldn't say it is "too late".  I am fairly certain with the plan laid out by sipa ( https://gist.github.com/sipa/8907691 ) there is a road to immutable tx ids in bitcoins future.   It won't however happen overnight.  It probably is going to be the better part of a year as it will need support of users and miners, provide a way forward without splitting the network, will require extensive testing and rolled out in phases.

Short term "patch": make clients handle mutable tx ids in a more consistent and cautious manner.
Long term "solution": ensure tx ids are immutable (or at least immutable by third parties).

[JonesL]

So simple way for mtgox to remain solvent and patch the lost coins.

Trap all users from moving their btc out.
Buy the coins from it's own members at depressed prices...now $100++ and sell on the other exchange at $600++.....repeat...till earn enough to patch the hole.

Put all the earned coins and money into the central fund again. And mtgox is good to go!

[Skinnkavaj]

Thank you DeathAndTaxes. You always write good stuff.

[PrintCoins]

Ok, now I finally grasped the attack I think on gox.

<snip>

No the attack didn't involve tx from the user or deposits as both would require confirmations and any breakdown due to malleability would have not resulted in extra payments.

Simple version:
User has x BTC on his MtGox account.
User created a withdraw request for x BTC.
MtGox creates a withdraw transfer with tx id "A".
MtGox's wallet is creating "broken" tx anyways which make legitimate issues for tx propagation.
User takes tx id "A", modifies the mutable parts and this produced tx id "B".
Tx "B" ends up in a block and user has received x BTC.
User notifies MtGox they haven't received their withdraw.
MtGox looks in blockchain and there is no tx "A" and thus assumes (incorrectly) this means user has not been paid.
MtGox creates a new tx ("C") for x BTC to the address specified by user and has now paid the user twice.

User could not either deposit the double bitcoins and pull the con again or modified tx "C" so it is tx "D" and report a second failure ("MtGox tx C didn't confirm either please pay me again, I mean pay me) to continue to the theft.

MtGox has had legitimate issues with withdraws not being confirmed (due to their own errors) for more than a month.  How many times did an attacker pull the attack described above? How many bitcoins were double paid?

Or if you want to be optimistic, gox could have kept 90% of their funds in a cold wallet and all is safe.

Or they saw all these requests as valid normal outflows and when the hot wallet got low, moved funds from one or more cold wallets to replenish the hot wallet so the could continue to double, triple, quadruple pay withdraw requests.

Only MtGox knows how much they overpaid and they simply are not talking.

Ok, this make so much more sense. Thank you DaT.

So if I set up a trading system, and
* someone makes a withdraw
* I have a log of the transaction id A of that withdraw
* They make another duplicate transaction B which has a different transaction id of A
* I see that A didn't make it into the blockchain (though untracked transaction B did make it in)
* Upon the user's request I make another transaction C to remedy that A failed.
* Rinse and repeat.

Wow, that is a problem. I now have more sympathy for gox and others as this could easily happen, though they should have had some basic human powered fail-safes to prevent a run-away situation.

So as a provider, what information should I keep as the unique identifier for the transaction that would prevent this issue. I guess it would be something easily searchable in the blockchain.

[un_ordinateur]

Wow, that is a problem. I now have more sympathy for gox and others as this could easily happen, though they should have had some basic human powered fail-safes to prevent a run-away situation.

The thing is... such behavior was already known since 2011. People writing software to handle large BTC amount should at least have read the specs, and known that txid cannot be used for tracking purpose.

So as a provider, what information should I keep as the unique identifier for the transaction that would prevent this issue. I guess it would be something easily searchable in the blockchain.

You should keep track of the spent/unspent status of the outputs you used as an input of your transaction. Whatever is the version of the transaction that gets included in the blockchain, the input will appear "spent" if the transaction goes trough.

Additionnally, if you reissue a transaction, you should ALWAYS re-use at least one of the input. So that only one of the two transactions can ever confirm, even if the first one finally gets confirmed after you issued the second.