How does a transaction malleability look like in the blockchain? Are there any examples?


2 Answers 2


Here is example: https://blockchain.info/tx/683f45578328242a06bc5c54acbcbe6e70a5435b4561fc8b0570a59ab09f8bfa?show_adv=true

Look at first input script in raw:


Look at first byte: 4d (OP_PUSHDATA2). It means, that next 2 bytes contains length of data, that will be pushed to stack. This length = 0x49. But typical transaction does not use OP_PUSHDATA2 command. If transaction was created by bitcoin-qt, it starts with length of data directly:


I take into brackets unnecessary bytes.

So, someone added 2 bytes to signature script, but did not break signature and changed id of transaction. Original tx was deleted from blockchain.info. Next link no longer works: https://blockchain.info/tx/ef74c1cbf0003fc4e96a87a59838f7dd3da488d9d83fec3f270b0d3d7c2bc309?show_adv=true

Look at wiki for more information about scripts: https://en.bitcoin.it/wiki/Script

  • 1
    Interesting analysis of the raw bytes. Commented Feb 12, 2014 at 10:55
  • The ef74 transaction no longer appears on blockchain.info; your link leads to a message saying "Transaction not found". Commented Feb 13, 2014 at 4:11
  • Looks like blockchain does not save tx, which is not included in blocks.
    – Zergatul
    Commented Feb 13, 2014 at 8:18
  • @Zergatul, Where did you grab this tx from?
    – Pacerier
    Commented May 22, 2014 at 17:39
  • I run parser and found this tx in my local blockchain.
    – Zergatul
    Commented May 28, 2014 at 11:55

The blockchain cannot contain malleable transactions. The malleable transactions happen before the transaction is embedded in a block in the blockchain.

Essentially, the transaction ID is a hash of everything about the transaction including the signature. The signature signs everything except the signature part (it can't sign its own data). So, two transaction records can have the same inputs and outputs, with (effectively) the same signature, but have a different transaction ID. It is this double transaction ID for the same transaction that can confuse some Bitcoin clients.

After a transaction is incorporated into a block, the malleability no longer matters. When Bitcoin clients try to work with transactions before they have been properly confirmed (by being incorporated in a block several times), problems can arise.

  • So inside the block the transaction will definitely have the same ID as when it was created?
    – D-32
    Commented Feb 12, 2014 at 9:53
  • No, transaction will have another ID. I do not agree with Greg Hewgill, trying to found such tx in blockchain now.
    – Zergatul
    Commented Feb 12, 2014 at 9:59
  • @D-32 When the transaction is created one gets a transactionID, however, the ID can be changed until it is confirmed in a block. If the ID is changed one or the either may be accepted. When somebody expects transactionID A to make it into a block, but transactionId B is accepted, and they just check for the transactionId A they will not find it confirmed. Once the transaction is in a block the transactionId cannot change anymore.
    – Murch
    Commented Feb 14, 2014 at 10:11
  • 1
    This is dangerously incorrect! The block can be orphaned. And if that block is orphaned and a mutant is in the winning chain, your entire chain of succeeding transactions will jam because the immediate successors refer to the wrong transaction ID in their inputs and the indirect successors refer to transactions that can never confirm. This is precisely the mistake that screwed over high-volume transaction issuers. Commented Feb 14, 2014 at 12:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.