Transaction Malleability

Transaction Malleability Example

Transaction malleability is an attack that lets a person change a Bitcoin transaction’s unique ID before confirmation on the Bitcoin network. This change makes it possible for the person to pretend that a transaction didn’t happen. In case of Bitcoin exchanges, it can be used to make a double deposit or double withdrawal.

Malleability is a problem that has been in Bitcoin for many years, it is well known and it is not too hard to make sure a business can’t lose money over this. The problem really should get fixed, though, as it is a rather embarrassing issue[1].

Contents

Description

The high level problem is this; A user can create a transaction, which she signs and sends off to the network in order to get mined. Transactions get automatically assigned a transaction-ID. To uniquely identify that transaction. This assignment is done in a smart way such that the ID is assigned based on the content. This way we avoid having to ask a central server to give unique IDs.

There is a way to change the transaction slightly so it still is a valid transaction that correctly moves money as the original author intended and doesn’t break the signatures either. This is called the malleability issue. The small change will have as an effect that the transaction-ID changes, as its based on slightly different content now. The result is that a company sending a transaction can not be certain that his transaction will have the same ID from the moment is was created to when it finally gets mined in a block. MtGox claimed that this was a reason they lost funds where users would complain a transfer from the company to them never arrived and the exchange would only check the transaction ID having been mined. A simple fix is to avoid address reuse and check balances on addresses instead.

How can you malleate a transaction?

Quite technical, Feel free to skip to the solution below. A Bitcoin transaction of version 1 defines that the transaction-ID is calculated by taking the entire content of the transaction and hashing it[2].

On the other hand, the thing that protects a transaction from being modified after the fact are signatures that are created for each input. These signatures ignore parts of the transaction. And exactly the difference in what is used for the Transaction ID and what is used for signing an input is where the malleability comes from.

During signing of an input the signatures of all inputs are removed because of the cryptographic truism that signatures can’t be part of the thing that is signed. In adding a signature in Bitcoin 2 things are added. First the amount of bytes that the signature takes, then the actual signature. Both of these pieces of information are removed for signing but used for creating the transaction ID. The trick here is that we can add some dummy data, or we can encode the length in different ways that mean the same thing. 120 bytes is the same thing as 0120 bytes. But the latter is encoded differently. And thus creates a different transaction ID.

While transactions are signed, the signature does not currently cover all the data in a transaction that is hashed to create the transaction hash. Thus, while uncommon, it is possible for a node on the network to change a transaction you send in such a way that the hash is invalidated. Note that this just changes the hash; the output of the transaction remains the same and the bitcoins will go to their intended recipient. However this does mean that, for instance, it is not safe to accept a chain of unconfirmed transactions under any circumstance because the later transactions will depend on the hashes of the previous transactions, and those hashes can be changed until they are confirmed in a block (and potentially even after a confirmation if the blockchain is reorganized). In addition, clients must always actively scan for transactions to them; assuming a txout exists because the client created it previously is unsafe[3].

Signature Malleability

SF Bitcoin Devs Seminar: Transaction Malleability: Threats and Solutions

The first form of malleability is in the signatures themselves. Each signature has exactly one DER-encoded ASN.1 octet representation, but OpenSSL does not enforce this, and as long as a signature isn’t horribly malformed, it will be accepted. In addition for every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message.

As of block 363724[4], the BIP66 soft fork has made it mandatory for all new transactions in the block chain to strictly follow the DER-encoded ASN.1 standard. Further efforts are still under way to close other possible malleability within DER signatures.

Signatures can still be changed by anyone who has access to the corresponding private keys.

ScriptSig Malleability

The signature algorithm used in Bitcoin does not sign any of the scriptSig to create the signature. While signing the whole scriptSig would be impossible – the signature would be signing itself – this does mean that additional data can be added such that it will be pushed on the stack prior to the required signatures and public keys. Similarly OP_DROP can be added to leave the stack exactly as before prior to scriptPubKey execution.

Preventing scriptSig malleability is being considered as well. Currently transactions with anything other than data push operations in their scriptSig are considered non-standard and are not relayed, and eventually this rule may extend to enforcing that the stack have exactly one item after execution. However doing that may interfere with later extensions to Bitcoin[5].

How Does Transaction Malleability Affect The Lightning Network?

First, let’s review what the Lightning Network is. The Lightning Network is an off-chain micro-payment network. The Lightning Network operates on top of Bitcoin and is often referred to as a “Layer 2” solution for that reason. The Lightning Network works by creating a double-signed transaction. That is, we have a new check that requires both parties to sign for it to be valid. The check specifies how much is being sent from one party to another. As new micro-payments are made from one party to the other, the amount on the check is changed and both parties sign the result.

To start the Lightning Network channel, this double-signed check must be funded. In order that the double-signed check isn’t held captive by an uncooperative counterparty, the double-signed check is signed by both parties before the funding transaction is sent out to the network.

For the Lightning Network to work, we need the funding transaction to not be broadcast until the double-signed check is signed. Because the double-signed check refers to the funding transaction’s identifier, if the funding transaction’s identifier is changed, the double-signed check will become invalid. This represents a risk to opening the Lightning Network channel. There are ways to make the Lightning Network work without this fixing transaction malleability, but LN is easier when transaction malleability is fixed[6].

External links

See Also on BitcoinWiki

References

  1. ↑ Malleability – Bitcoin Classic
  2. ↑ https://bitcointalk.org/index.php?topic=8392.msg1245898#msg1245898
  3. ↑ Transaction Malleability, Mutability – Bitcoin Glossary – Bitcoin.org
  4. ↑ When did BIP66 switch from activation to enforcement?, answer by StephenM347, 6 July 2015, Bitcoin.StackExchange
  5. ↑ https://bitcointalk.org/index.php?topic=8392.msg122410#msg122410
  6. ↑ How Does Transaction Malleability Affect – Bitcoin Tech Talk



Bitcoin Core documentation
User documentation
Developer documentation
History & theory