Bitcoin Forum
December 14, 2017, 11:00:52 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: How did tx malleability/DDOS attacks allow exchanges to get "out of sync"?  (Read 645 times)
pythonscript
Newbie
*
Offline Offline

Activity: 6


View Profile
March 02, 2014, 09:17:56 PM
 #1

This Coindesk article says that

Quote
“So as transactions are being created, malformed/parallel transactions are also being created so as to create a fog of confusion over the entire network, which then affects almost every single implementation out there,”.

Antonopoulos went on to say that Blockchain.info’s implementation is not affected, but some exchanges have been affected – their internal accounting systems are gradually going out of sync with the network.

I think I understand the first part; as transactions are created, hundreds of transactions are created that are identical except for a mutated signature are created in the network. The second part confuses me a bit, though. Do the exchange's accounting systems get out of sync because some of the original transactions aren't going through because a mutated version has already been confirmed in the blockchain? So for example, Mt. Gox, which was using an automated system to approve withdrawals (as stated in the article), would consider a withdrawal transaction approved before it was actually confirmed in the blockchain. Once a mutated version of that transaction was confirmed in the blockchain, Mt. Gox's accounting system had a problem because a transaction it assumed was confirmed (and therefore had already "lost" the Bitcoins for) wasn't actually confirmed.
1513249252
Hero Member
*
Offline Offline

Posts: 1513249252

View Profile Personal Message (Offline)

Ignore
1513249252
Reply with quote  #2

1513249252
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513249252
Hero Member
*
Offline Offline

Posts: 1513249252

View Profile Personal Message (Offline)

Ignore
1513249252
Reply with quote  #2

1513249252
Report to moderator
1513249252
Hero Member
*
Offline Offline

Posts: 1513249252

View Profile Personal Message (Offline)

Ignore
1513249252
Reply with quote  #2

1513249252
Report to moderator
1513249252
Hero Member
*
Offline Offline

Posts: 1513249252

View Profile Personal Message (Offline)

Ignore
1513249252
Reply with quote  #2

1513249252
Report to moderator
Test User
Member
**
Offline Offline

Activity: 86

Miner and technician


View Profile
March 02, 2014, 11:25:15 PM
 #2

Exchanges accounting systems can get out of sync, if they follow the "transaction ID".

A customer issues a withdrawal request. The exchange system initiates a bitcoin transaction and records the TxID for audit purposes, and to show the customer for tracking purposes. In the event of a malleability attack, it is possible for a mutated version of the transaction to be accepted by the blockchain, and therefore the original transaction ID will be rejected and never confirm (but the transaction had, in fact, completed under the new ID). In this scenario, exchange software may see the TxID has failed to confirm on the blockchain, and treat it as a failed transaction, and give the customer the option of trying the withdrawal again (allegedly what happened at Silk Road 2 by a completely automated system for re-attempting withdrawals).

In the case of Mt Gox, it appears that in the event that the TxID didn't show up in the blockchain, a customer could contact support claiming not to have received the transaction (even though it had arrived), and support would issue a new transaction.

In this case, the exchange thinks that the withdrawal is still pending, but it has actually completed. Good audit and reconciliation practice should mitigate this significantly, because the books wouldn't balance as soon as a new transaction was issued and a customer got double paid.

However, if an exchange didn't take care to check their wallet balances on a regular basis, then they could easily end up losing coins. (Mt Gox claimed that they had suffered losses over a period of years. This would suggest that they had never checked their wallet balance against deposits/withdrawals ever over a period of several years - either they are lying, or the negligence is beyond comprehension).


Donations welcome - BTC: 1f52PwRLHkN4w5uBY6EccKiDYqpLkh13y     DOGE: DCg65AKPG76X5LEtWCqfyRj4a6apYRHR8j
Trust: https://bitcointalk.org/index.php?topic=432215.0
acoindr
Legendary
*
Offline Offline

Activity: 1036


View Profile
March 03, 2014, 12:23:36 AM
 #3

The second part confuses me a bit, though. Do the exchange's accounting systems get out of sync because some of the original transactions aren't going through because a mutated version has already been confirmed in the blockchain?

No. The original transactions will have gone through, especially if using something like the reference client Bitcoin-qt/Bitcoind, which will not usually broadcast invalid transactions. The only thing which doesn't "go through" is the expected transaction ID.

So for example, Mt. Gox, which was using an automated system to approve withdrawals (as stated in the article), would consider a withdrawal transaction approved before it was actually confirmed in the blockchain.

Actually that's what they should have done. They should have assumed their transaction was valid/approved once broadcast. When and if they believed it wasn't they should have investigated the reason(s) why, instead of simply sending new transactions.

Once a mutated version of that transaction was confirmed in the blockchain, Mt. Gox's accounting system had a problem because a transaction it assumed was confirmed (and therefore had already "lost" the Bitcoins for) wasn't actually confirmed.

No. Once a mutated version of the transaction was confirmed MtGox's accounting system had a problem because a transaction it assumed was confirmed, was confirmed, but someone told them it wasn't, and to check they used the irresponsible method of relying on transaction ID (which has the known malleability issue).
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!