Bitcoin Malleability Attack Explained
As CoinKite has discovered, many of our customers have had issues due to the current Bitcoin malleability attack that has been going on during this last week. In order to keep you all informed we are re-posting this very informative blog post that our friends at CoinKite have released that explains what this type of attack is and does to transactions.
See the original article here on the CoinKite blog.
We’ve noticed a number of our customer’s transactions modified and rebroadcast with a new transaction number. This attack is being applied to almost all transactions on the network and is not targeted at ShapeShift or our users. Just as Peter from CoinKite mentioned, this does not put ShapeShift customer funds at risk:
This is a nuisance only and does not put your funds at risk. – Peter, CoinKite CTO
The modification that’s being made to the transactions is well understood and isn’t new: it is a simple numeric tweak to one number (S) in the ECDSA signature. It’s documented as part of BIP62 and is called the “low S” requirement. Coinkite always uses the lower S value, but these pranksters have been replacing that with the higher S value. Transactions are being changed without any knowledge of the private keys involved. The change does not affect the source, destination, or amounts of the funds, so it isn’t obvious when it first happens
What does this mean to me?
While this attack is happening, you cannot trust bitcoin transaction numbers as much as you might be used to. Once you send a transaction, you need to understand that your transaction might actually get into a block under a different hash. Your recipient gets the funds the same, miner fees are the same, and most block explorers do not show enough detail to be able to tell the two transactions apart.
Technically, your original transaction could be considered a “double spend” and let’s hope no-one is foolish enough to confuse your intentions. There is nothing you can do to prevent these modifications. The modification happens after it is sent onto the public network.
What should I do?
We all need to be a little more careful about acting on zero-confirmation receives right now. In particular, it is not safe to build new transactions on top of the first transaction until it confirms, because there are in effect two versions of that transaction (yours and the high-S version) and you can’t predict which will be mined. This is a problem even for transactions between trusted parties and even between your own accounts.
What’s the long-term solution?
The solution would be BIP62 which is not ready yet. Once it is, we encourage all miners to enforce it as soon as possible.