Coinkite, a bitcoin platform that transacts more than 400,000 BTC per month, has reported a bitcoin malleability attack that requires users to be careful about zero confirmation receipts since there are two versions of a transaction (low S high S). Coinkite is requiring one confirmation for deposits before it uses them in a new transaction.
Transactions have been modified and rebroadcast with new transaction numbers, indicating a malleability attack. The attacks have occurred over the last 24 to 48 hours. Almost all transactions on the network have suffered the attacks.
Customer Funds Not At Risk
The company noted in a blog that the attacks do not put Coinkite’s customer funds at risk. The modification being made to the transactions is a simple numeric tweak to one number (S) in the ECDSA (Elliptical Curve Digital Signature Algorithm) signature, the blog notes. “It’s documented as part of BIP62 and is called the ‘low S’ requirement.” Coinkite always uses the lower S value, but the attackers have been replacing it with the higher S value.
The attackers change the transactions 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 happens.
Users cannot trust bitcoin transaction numbers as much when this occurs. Once a transaction sends, the user must understand the transaction might get into the a block under a different hash.
Your receipt gets the funds the same, miners 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.
Caution Needed On Zero Confirmation Receipts
Coinkite urges users to be more careful about action on zero confirmation receipts at the present time. It is not safe to build new transactions on top of the previous one until it confirms, since there are in effect two version of the transactions – the user’s and the high-S version – and the user cannot predict which will be mined. The problem even exists for transactions between trusted parties and between a user’s own accounts.
All deposits into Coinkite accounts must receive one confirmation before Coinkite uses them in a new transaction.
We have deployed new code that tracks these modified transactions, and when they get confirmed into blocks, we retroactively adjust our records and continue with the new transaction number in effect.
BIP62 is not currently deployed and Coinkite encourages all miners to enforce it as soon as possible.
Featured image from Shutterstock.