Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question

Here is example:

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 Next link no longer works:

Look at wiki for more information about scripts:

share|improve this answer
Interesting analysis of the raw bytes. – Luca Matteis Feb 12 '14 at 10:55
The ef74 transaction no longer appears on; your link leads to a message saying "Transaction not found". – Nate Eldredge Feb 13 '14 at 4:11
Looks like blockchain does not save tx, which is not included in blocks. – Zergatul Feb 13 '14 at 8:18
@Zergatul, Where did you grab this tx from? – Pacerier May 22 '14 at 17:39
I run parser and found this tx in my local blockchain. – Zergatul May 28 '14 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.

share|improve this answer
So inside the block the transaction will definitely have the same ID as when it was created? – D-32 Feb 12 '14 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 Feb 12 '14 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 Feb 14 '14 at 10:11
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. – David Schwartz Feb 14 '14 at 12:07

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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