13
7
How does a transaction malleability look like in the blockchain? Are there any examples?
Transaction Malleability in the blockchain
Answers
7
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
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.
So inside the block the transaction will definitely have the same ID as when it was created? – D-32 – 2014-02-12T09:53:38.260
No, transaction will have another ID. I do not agree with Greg Hewgill, trying to found such tx in blockchain now. – Zergatul – 2014-02-12T09:59:03.507
@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 – 2014-02-14T10:11:20.263
1This 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 – 2014-02-14T12:07:33.183
1Interesting analysis of the raw bytes. – Luca Matteis – 2014-02-12T10:55:52.120
The ef74 transaction no longer appears on blockchain.info; your link leads to a message saying "Transaction not found". – Nate Eldredge – 2014-02-13T04:11:18.007
Looks like blockchain does not save tx, which is not included in blocks. – Zergatul – 2014-02-13T08:18:33.333
@Zergatul, Where did you grab this tx from? – Pacerier – 2014-05-22T17:39:05.260
I run parser and found this tx in my local blockchain. – Zergatul – 2014-05-28T11:55:09.667