This is a very complicated way to explain TX malluability. It'd say that the problem is that signatures only sign a portion of the transaction and the resulting TXID that is used in the blockchain is based on hashing the entire transaction.<p>So the signature can be mutated as the author suggests, but the signature doesn't sign the entire section of the transaction anyway (where data is provided to the redeemScript to satisfy its conditions. This section called the scriptSig includes the sig which cannot sign itself.)<p>So with the scriptSig, anyone is free to add whatever new data they like to this section which gets added to the input stack, and as long as you leave the stack the same way as you found it you can insert any arbitrary junk as you like and it will change the resulting TXID as seen in the blockchain without invalidating the transaction.<p>This is a bad thing for "smart contracts" on Bitcoin because many contracts depend on making chains of unconfirmed, future transactions, based on hashing the entire transaction to compute its TXID (as Clarkmoody suggests.) An example of this is a cross-chain contract where you might want to send funds to a partially shared address between a stranger and yourself, and you need a way to setup a time-locked refund in case the protocol doesn't succeed (no longer necessary due to OP_CHECKLOCKTIMEVERIFY but its an example.)<p>To do refunds in this way you would need to be able to sign chains of unconfirmed transactions without previous transaction IDs being changed from transaction malleability. Bitcoin does include a fix for this called "segregated witness" but the fix has been controversial. I don't keep up to date with the "scaling progress" now but I doubt it has been merged yet.