MtGox problems and spambo-smith
As it was already written here many times before , Bitcoin virtual cryptocurrency is going through hard times. For several weeks, users of the oldest and once largest exchange MtGox had difficulties in trying to withdraw their bitcoins from the exchange. In the past few days, the difficulties Bitcoin has experienced have reached a new level.
It should be noted that MtGox’s problems began last spring, when its US settlement account was arrested in connection with the investigation of illegal money transfer activities without a corresponding license. Since then, the exchange can not find reliable banking partners, and regularly delays payments in traditional currency. This led to a noticeable exchange difference compared with other exchanges, sometimes reaching up to 25% .
However, as for the withdrawal of bitcoins, the exchange is not experiencing these problems for the first time. According to Gregory Maxwell, one of the key developers of the Bitcoin Foundation (link), the exchange already experienced similar problems last September:
')
MtGox does not use the reference software provided by the Bitcoin Foundation to perform Bitcoin operations. As they say, reference software is not suitable for their volumes. Instead, they use their own wallet, which, according to rumors, was written in PHP by Mark Karpelles personally (aka MagicalTux), the exchange director. In the derivation of cryptocurrency, they tried to use the newly generated bitcoins (less than 100 confirmations), which is prohibited by the protocol rules. As a result, these transactions were blocked and not confirmed. In order to solve this problem radically, we would have to significantly alter the existing software and keep track of the number of confirmations for each batch of coins. Most likely, MtGox did not decide on radical changes and instead avoided the problem by changing the algorithm for selecting coins for outgoing transactions - giving priority to the oldest received coins.
The problem they faced this time is somewhat similar. These problems began, apparently in early November , and gradually worsened as more and more Bitcoins in their wallet stuck in lost outgoing transactions. A more or less normal explanation of what happened in Russian has already been published here before . I will just make a couple of comments.
Firstly, malleable transactions are not “dull”, but “malleable” (mallet = hammer), or, if translated, “deformable”.
Secondly, many outgoing MtGox transactions were initially not entirely correct, and were blocked by most of the network nodes, because they contained a signature in an incorrect format. This lock was added to the client’s reference implementation relatively recently, and, apparently, not all nodes and not all miners managed to update their software, which allowed MtGox to continue sending transaction curves for the time being. In addition, MtGox has direct access to some miner pools, which allowed them to bypass the blocking of transactions by the network.
One way or another, at some point someone looked carefully at why his transaction did not go through, corrected it (the malleability allows it to be done without changing the signature) and sent it. Since the transaction has changed in form (not in content), its hash has changed, which mtGox used for tracking. The user saw that the coins had arrived at his address, but MtGox continued to believe that the transaction was not confirmed. Later, automatically or manually (I tend to think that automatically), MtGox tries to send a new transaction to the same user. If this new transaction uses “unlocked” coins (of which there were not so many), then either the transaction is successful again (sometimes, by chance, the signature was in the correct format), or the user had to “rewrite” the transaction again, and he received a new batch coins to your address.
Thus, this vulnerability became apparent, possible and easily exploited. The hacker did not have to compete with the original incorrect transaction, which was blocked by the network anyway, there was no need to invent clever ways to “re-load” the transaction (many of which are no longer available). He only needed to “fix” the transaction.
The fact that you cannot rely on a hash to track a transaction was already known in April 2011 . A little later, the corresponding changes were made to the reference software, so that it did not rely only on the transaction id, but monitored any transactions that consumed the corresponding outputs (looking ahead, these changes were insufficient). Despite this, as of the end of January 2014, the developers at MtGox had no idea what was going on. After several days of investigation, on February 10, MtGox finally blocked all outgoing transactions and posted an ad on its website . In it, they briefly give a technical description of the problem and state that this is a critical error in the protocol, and that all exchanges and online wallets can be subject to attacks. There are no words about the problems of their own client implementation, which made the attack easy to implement. MtGox was in such a hurry to blame everyone and everything for their problems, that they even forgot to apologize for their own flaws, sluggishness and those, to put it mildly, inconveniences that they delivered and continue to deliver to their users.
After this statement, MtGox was answered first by some key developers personally , why the official response statement of the Bitcoin Foundation . All of them recognize that this is a long-known lack of protocol design, but is by no means a critical one. It is indicated that the reference software has long contained code to cope with these difficulties, and that MtGox should fix their own software. It is puzzling to many why this is used as a pretext to block withdrawals from the exchange.
A lot of bitcoiners agree that the main purpose of this statement for MtGox was to destabilize the price in order to cover the loss of Bitcoins by buying them at a low price on their own stock exchange and arbitration on other exchanges.
However, the most interesting thing started yesterday.
Someone launched a node / nodes in the Bitcoin network that intercept all transactions and “forge” them on an industrial scale. According to some information , only during February 11 and 12 about 30,000 transactions were “mutated”. Bitcoin protocol does not allow to steal money in this way, and the hacker’s sole purpose, apparently, is to attack bitcoin as a whole, with a view to further destabilizing the price.
As I noted earlier, the reference protocol implementation does not rely on the tx id (transaction hash) to track the expenditure of outputs. However, it has one feature that is not fully compatible with "reforging". Currently, bitcoin-qt allows you to spend "surrender" from the transaction immediately, without waiting for confirmation. It was believed that this is a safe practice - since the change always goes to our own wallet. If the transaction that creates the change is confirmed, then the subsequent transaction that consumes the change will be correct, and the total balance of the wallet will not be disturbed. If the first transaction is not committed, then the transaction that consumes the change will not make sense. Transforming transactions makes its own adjustments to this assumption, since a reforged transaction, with a modified tx id, can be confirmed, but a transaction that consumes change becomes incorrect because the tx id of the transaction on which it depends has changed.
Thus, if someone actively expends funds from his wallet, they may be confronted with the fact that the balance is reflected incorrectly, and some transactions never complete. Bitcoins are not lost! However, this causes chaos in the accounting of the spent bitcoins, and creates certain difficulties, since the “stuck” transactions are not easy to remove manually.
Currently a patch is being prepared to fix this problem urgently. The solution is simple: do not spend change until at least one confirmation is received. A command will also be added to manually “clear” the stalled transactions. In the long run, it has been proposed to minimize the possibilities for “re-crafting” transactions , although it is not yet completely clear whether this can be completely eliminated.
I recommend not to send bitcoins using bitcoin-qt reference until a new release is released. If, however, there is an urgent need to do this, then wait for at least one confirmation before making new transactions.
Update: Bitcoin Foundation has finally made a new release of 0.9.0 Bitcoin benchmark.
It should be noted that MtGox’s problems began last spring, when its US settlement account was arrested in connection with the investigation of illegal money transfer activities without a corresponding license. Since then, the exchange can not find reliable banking partners, and regularly delays payments in traditional currency. This led to a noticeable exchange difference compared with other exchanges, sometimes reaching up to 25% .
However, as for the withdrawal of bitcoins, the exchange is not experiencing these problems for the first time. According to Gregory Maxwell, one of the key developers of the Bitcoin Foundation (link), the exchange already experienced similar problems last September:
I first heard people reporting stuck transactions back in ~ September. I looked at spending money. Freshly generated Bitcoins (from mining) can not be spent until they are at least 100 blocks deep in the blockchain. If the chain reorgs. I pinged magicaltux [note: Mark Karpelles] and after a couple of tries. It is not a big deal.
Mtgox was not their tracking. It is a non-trivial change and it takes a lot of work. I’m suggesting that I’ve been able to work.
')
MtGox does not use the reference software provided by the Bitcoin Foundation to perform Bitcoin operations. As they say, reference software is not suitable for their volumes. Instead, they use their own wallet, which, according to rumors, was written in PHP by Mark Karpelles personally (aka MagicalTux), the exchange director. In the derivation of cryptocurrency, they tried to use the newly generated bitcoins (less than 100 confirmations), which is prohibited by the protocol rules. As a result, these transactions were blocked and not confirmed. In order to solve this problem radically, we would have to significantly alter the existing software and keep track of the number of confirmations for each batch of coins. Most likely, MtGox did not decide on radical changes and instead avoided the problem by changing the algorithm for selecting coins for outgoing transactions - giving priority to the oldest received coins.
The problem they faced this time is somewhat similar. These problems began, apparently in early November , and gradually worsened as more and more Bitcoins in their wallet stuck in lost outgoing transactions. A more or less normal explanation of what happened in Russian has already been published here before . I will just make a couple of comments.
Firstly, malleable transactions are not “dull”, but “malleable” (mallet = hammer), or, if translated, “deformable”.
Secondly, many outgoing MtGox transactions were initially not entirely correct, and were blocked by most of the network nodes, because they contained a signature in an incorrect format. This lock was added to the client’s reference implementation relatively recently, and, apparently, not all nodes and not all miners managed to update their software, which allowed MtGox to continue sending transaction curves for the time being. In addition, MtGox has direct access to some miner pools, which allowed them to bypass the blocking of transactions by the network.
One way or another, at some point someone looked carefully at why his transaction did not go through, corrected it (the malleability allows it to be done without changing the signature) and sent it. Since the transaction has changed in form (not in content), its hash has changed, which mtGox used for tracking. The user saw that the coins had arrived at his address, but MtGox continued to believe that the transaction was not confirmed. Later, automatically or manually (I tend to think that automatically), MtGox tries to send a new transaction to the same user. If this new transaction uses “unlocked” coins (of which there were not so many), then either the transaction is successful again (sometimes, by chance, the signature was in the correct format), or the user had to “rewrite” the transaction again, and he received a new batch coins to your address.
Thus, this vulnerability became apparent, possible and easily exploited. The hacker did not have to compete with the original incorrect transaction, which was blocked by the network anyway, there was no need to invent clever ways to “re-load” the transaction (many of which are no longer available). He only needed to “fix” the transaction.
The fact that you cannot rely on a hash to track a transaction was already known in April 2011 . A little later, the corresponding changes were made to the reference software, so that it did not rely only on the transaction id, but monitored any transactions that consumed the corresponding outputs (looking ahead, these changes were insufficient). Despite this, as of the end of January 2014, the developers at MtGox had no idea what was going on. After several days of investigation, on February 10, MtGox finally blocked all outgoing transactions and posted an ad on its website . In it, they briefly give a technical description of the problem and state that this is a critical error in the protocol, and that all exchanges and online wallets can be subject to attacks. There are no words about the problems of their own client implementation, which made the attack easy to implement. MtGox was in such a hurry to blame everyone and everything for their problems, that they even forgot to apologize for their own flaws, sluggishness and those, to put it mildly, inconveniences that they delivered and continue to deliver to their users.
After this statement, MtGox was answered first by some key developers personally , why the official response statement of the Bitcoin Foundation . All of them recognize that this is a long-known lack of protocol design, but is by no means a critical one. It is indicated that the reference software has long contained code to cope with these difficulties, and that MtGox should fix their own software. It is puzzling to many why this is used as a pretext to block withdrawals from the exchange.
A lot of bitcoiners agree that the main purpose of this statement for MtGox was to destabilize the price in order to cover the loss of Bitcoins by buying them at a low price on their own stock exchange and arbitration on other exchanges.
However, the most interesting thing started yesterday.
Someone launched a node / nodes in the Bitcoin network that intercept all transactions and “forge” them on an industrial scale. According to some information , only during February 11 and 12 about 30,000 transactions were “mutated”. Bitcoin protocol does not allow to steal money in this way, and the hacker’s sole purpose, apparently, is to attack bitcoin as a whole, with a view to further destabilizing the price.
As I noted earlier, the reference protocol implementation does not rely on the tx id (transaction hash) to track the expenditure of outputs. However, it has one feature that is not fully compatible with "reforging". Currently, bitcoin-qt allows you to spend "surrender" from the transaction immediately, without waiting for confirmation. It was believed that this is a safe practice - since the change always goes to our own wallet. If the transaction that creates the change is confirmed, then the subsequent transaction that consumes the change will be correct, and the total balance of the wallet will not be disturbed. If the first transaction is not committed, then the transaction that consumes the change will not make sense. Transforming transactions makes its own adjustments to this assumption, since a reforged transaction, with a modified tx id, can be confirmed, but a transaction that consumes change becomes incorrect because the tx id of the transaction on which it depends has changed.
Thus, if someone actively expends funds from his wallet, they may be confronted with the fact that the balance is reflected incorrectly, and some transactions never complete. Bitcoins are not lost! However, this causes chaos in the accounting of the spent bitcoins, and creates certain difficulties, since the “stuck” transactions are not easy to remove manually.
Currently a patch is being prepared to fix this problem urgently. The solution is simple: do not spend change until at least one confirmation is received. A command will also be added to manually “clear” the stalled transactions. In the long run, it has been proposed to minimize the possibilities for “re-crafting” transactions , although it is not yet completely clear whether this can be completely eliminated.
I recommend not to send bitcoins using bitcoin-qt reference until a new release is released. If, however, there is an urgent need to do this, then wait for at least one confirmation before making new transactions.
Update: Bitcoin Foundation has finally made a new release of 0.9.0 Bitcoin benchmark.
Source: https://habr.com/ru/post/212455/
All Articles