<p>Here is example: <a href="https://blockchain.info/tx/683f45578328242a06bc5c54acbcbe6e70a5435b4561fc8b0570a59ab09f8bfa?show_adv=true" rel="noreferrer">https://blockchain.info/tx/683f45578328242a06bc5c54acbcbe6e70a5435b4561fc8b0570a59ab09f8bfa?show_adv=true</a></p>

<p>Look at first input script in raw:</p>

<pre><code>4d49003046022100847361c694421bf63ea1b51d8e2189805b161ab3d4cb96ab745a20468dd6c2ea0221009160897652bedfd7c837855d793c32509063338ac7524b8f09abfed761cf16fc014d410004c8dde23708932059bf4491c96794c5412b1182d62d2741e0986cb87276d3053f0b7326155114ad67c04adc60b5a47718fa8744ecb86a001f99da8761113edb24
</code></pre>

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

<pre><code>[4d]49[00]3046....
</code></pre>

<p>I take into brackets unnecessary bytes.</p>

<p>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: <a href="https://blockchain.info/tx/ef74c1cbf0003fc4e96a87a59838f7dd3da488d9d83fec3f270b0d3d7c2bc309?show_adv=true" rel="noreferrer">https://blockchain.info/tx/ef74c1cbf0003fc4e96a87a59838f7dd3da488d9d83fec3f270b0d3d7c2bc309?show_adv=true</a></p>

<p>Look at wiki for more information about scripts: <a href="https://en.bitcoin.it/wiki/Script" rel="noreferrer">https://en.bitcoin.it/wiki/Script</a></p>

CC BY-SA 3.0
2014-05-22T17:39:05.260Z
@Zergatul, Where did you grab this tx from?
Pacerier
CC BY-SA 3.0
2014-05-28T11:55:09.667Z
I run parser and found this tx in my local blockchain.
Zergatul
CC BY-SA 3.0
2014-02-12T10:55:52.120Z
Interesting analysis of the raw bytes.
Luca Matteis
CC BY-SA 3.0
2014-02-13T04:11:18.007Z
The ef74 transaction no longer appears on blockchain.info; your link leads to a message saying "Transaction not found".
Nate Eldredge
CC BY-SA 3.0
2014-02-13T08:18:33.333Z
Looks like blockchain does not save tx, which is not included in blocks.
Zergatul
CC BY-SA 3.0
2014-02-12T10:10:27.833Z
2014-02-14T10:07:45.730Z
2014-02-14T10:07:45.730Z
Zergatul
<p>The blockchain cannot contain malleable transactions. The malleable transactions happen <em>before</em> the transaction is embedded in a block in the blockchain. </p>

<p>Essentially, the transaction ID is a hash of everything about the transaction including the signature. The signature signs everything <em>except</em> 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.</p>

<p>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.</p>

CC BY-SA 3.0
2014-02-12T09:53:38.260Z
So inside the block the transaction will definitely have the same ID as when it was created?
D-32
CC BY-SA 3.0
2014-02-12T09:59:03.507Z
No, transaction will have another ID. I do not agree with Greg Hewgill, trying to found such tx in blockchain now.
Zergatul
CC BY-SA 3.0
2014-02-14T10:11:20.263Z
@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
CC BY-SA 3.0
2014-02-14T12:07:33.183Z
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
CC BY-SA 3.0
2014-02-12T09:47:45.690Z
2014-02-12T09:47:45.690Z
Greg Hewgill
<p>How does a transaction malleability look like in the blockchain? Are there any examples?</p>

CC BY-SA 4.0
2021-10-04T07:10:07.597Z
Does this answer your question? [What is Transaction Malleability?](https://bitcoin.stackexchange.com/questions/21994/what-is-transaction-malleability)
Dmitry Grigoryev
<transactions><blockchain><transaction-malleability>
Transaction Malleability in the blockchain
D-32
# Transaction Malleability in the blockchain

(Asked by: username_0 on 2014-02-12)

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

**Tags:** transactions, blockchain, transaction-malleability

> **Comments:**
> **username_1**: Does this answer your question? [What is Transaction Malleability?](https://bitcoin.stackexchange.com/questions/21994/what-is-transaction-malleability)  

---

## 2 answers

### Answer by username_2 on 2014-02-12. Score: 8

Here is example: https://blockchain.info/tx/683f45578328242a06bc5c54acbcbe6e70a5435b4561fc8b0570a59ab09f8bfa?show_adv=true
Look at first input script in raw:
4d49003046022100847361c694421bf63ea1b51d8e2189805b161ab3d4cb96ab745a20468dd6c2ea0221009160897652bedfd7c837855d793c32509063338ac7524b8f09abfed761cf16fc014d410004c8dde23708932059bf4491c96794c5412b1182d62d2741e0986cb87276d3053f0b7326155114ad67c04adc60b5a47718fa8744ecb86a001f99da8761113edb24

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:
[4d]49[00]3046....

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

> **Comments:**
> **username_4**: Interesting analysis of the raw bytes.  
> **username_5**: The ef74 transaction no longer appears on blockchain.info; your link leads to a message saying "Transaction not found".  
> **username_2**: Looks like blockchain does not save tx, which is not included in blocks.  
> **username_3**: @username_2, Where did you grab this tx from?  
> **username_2**: I run parser and found this tx in my local blockchain.  

---

### Answer by username_6 on 2014-02-12. Score: 6

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.

> **Comments:**
> **username_0**: So inside the block the transaction will definitely have the same ID as when it was created?  
> **username_2**: No, transaction will have another ID. I do not agree with username_6, trying to found such tx in blockchain now.  
> **username_7**: @username_0 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.  
> **username_8**: 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.  

---

