Topic: Verifying a Transaction Mutation (Read 980 times)

First of all. The original public key is placed in transaction itself. So, it is not a requirement.
Second. Let us assume, that the transaction was signed with SIGHASH_ALL (this is default in all clients)
Third. We discuss pay-to-public-key scripts for tx inputs.

In such assumptions
For two valid transactions we can definitely say is one of them is mutated from other.
Some pseudocode:

Maybe this will help http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html, in the second part of the article "how bitcoin transactions are signed" he talks about which part of the transactions are signed and which parts aren't.  If I understand things properly, it does seem like any part of the transaction which isn't signed could potentially be changed. 

This overflow post takes you through a step-by-step on how transactions are signed (which parts, what data is moved where, etc):

http://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx

I hope this helps.  Thanks for the thread, I'm learning a lot myself by trying to help answer you.

Thanks. I've already read through thatand am still none the wiser. Can anyone else confirm if the txid, public key and signature are all that is required to spot all forms of transaction mutation?

Not all of the transaction is signed so it can slightly modified to change the hash of the transaction but not the signature. There is work to prevent this issue but it is not foolproof. See https://en.bitcoin.it/wiki/Transaction_Malleability

As for the OP's question, I think you only need to check the signature and the txid. The signature will be invalid and won't match the original if any part of the signature or data it signs doesn't match. This will be different depending on what was signed. This https://bitcoin.org/en/developer-guide#signature-hash-types might be able to help you.

I have to admit, I'm a little confused here.  As far as I know, a transaction has to be signed to be valid.  If the transaction was changed after the signature was added, then the signature isn't going to be valid (that's how digital signatures work).  Also, I believe that the ecdsa signing algorithm uses a random number, so each time you sign the same content you're going to potentially get a different signature.  How could a transaction be mutated in such a way that the signature wouldn't be rendered invalid?

Can all forms of transaction mutation be detected by someone if they have the original public key that was generated from the private key used to sign a transaction before it was mutated and mined to a block?

From my superficially understanding of malleability I think this is not possible.

Assuming I've understood this correctly: when a transaction's signature or script is changed and then mined to the blockchain, it generates a different hash value to reference that transaction than if the original transaction had been mined to the blockchain. This means if other signed transactions exist which reference the old hash value, then they are rendered invalid, such as transactions using lock_time > 0.

If I had retained an original copy of the transaction before it was mutated, what would be the computationally fastest way to identify that it had been mutated when it was mined to a block? As opposed to say spotting a double spend?

Would it be to check for both transactions to confirm:

   1. The TXID and the vouts being used as the transaction inputs are the same in both transactions.
   2. The outputs are identical, that is to say the value per n output, and each script and address are the same.

Because so far as I can see a double spend would look different because for the two transactions:

   1. The TXID and the vouts being used as the transaction inputs are the same in both transactions.
   2. The outputs are different, that is to say the value per n output, and each script and address are not the same.

I'm just wondering if it's possible to check less fields to get a definite answer and if their is a known reliable way to do this.