None of Dash's signature hash types protect the signature scriptsignature script - Data generated by a spender which is almost always used as variables to satisfy a pubkey script. Signature Scripts are called scriptSig in code., leaving the door open for a limited denial of service attack called transaction malleabilitymalleability - The ability of someone to change (mutate) unconfirmed transactions without making them invalid, which changes the transaction's txid, making child transactions invalid.. The signature script contains the secp256k1 signaturesignature - A value related to a public key which could only have reasonably been created by someone who has the private key that created that public key. Used in Dash to authorize spending duffs previously sent to a public key., which can't sign itself, allowing attackers to make non-functional modifications to a transaction without rendering it invalid. For example, an attacker can add some data to the signature script which will be dropped before the previous pubkey scriptpubkey script - A script included in outputs which sets the conditions that must be fulfilled for those duffs to be spent. Data for fulfilling the conditions can be provided in a signature script. Pubkey Scripts are called a scriptPubKey in code. is processed.
Although the modifications are non-functional---so they do not change what inputsinputs - An input in a transaction which contains three fields: an outpoint, a signature script, and a sequence number. The outpoint references a previous output and the signature script allows spending it. the transaction uses nor what outputsoutputs - An output in a transaction which contains two fields: a value field for transferring zero or more duffs and a pubkey script for indicating what conditions must be fulfilled for those duffs to be further spent. it pays---they do change the computed hash of the transaction. Since each transaction links to previous transactions using hashes as a transaction identifier (TXIDTXID - An identifier used to uniquely identify a particular transaction; specifically, the sha256d hash of the transaction.), a modified transaction will not have the txid its creator expected.
This isn't a problem for most Dash transactions which are designed to be added to the block chainblock chain - A chain of blocks with each block referencing the block that preceded it. The most-difficult-to-recreate chain is the best block chain. immediately. But it does become a problem when the output from a transaction is spent before that transaction is added to the block chain.
Dash Core 12.3 implemented BIP-147: Dealing with dummy stack element malleability which fixes a design flaw in OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY that caused them to consume an extra stack element ("dummy element") after signature validation. Previously, the dummy element was not inspected in any manner, and could be replaced by any value without invalidating the script. BIP147 removed this malleability vector by forcing the dummy element to be an empty byte array and rejecting anything else.
Transaction malleability also affects payment tracking. Dash Core's RPC interface lets you track transactions by their txid---but if that txid changes because the transaction was modified, it may appear that the transaction has disappeared from the network.
Current best practices for transaction tracking dictate that a transaction should be tracked by the transaction outputs (UTXOs) it spends as inputs, as they cannot be changed without invalidating the transaction.
Best practices further dictate that if a transaction does seem to disappear from the network and needs to be reissued, that it be reissued in a way that invalidates the lost transaction. One method which will always work is to ensure the reissued payment spends all of the same outputs that the lost transaction used as inputs.
For additional information regarding the types transaction malleability, reference this blog post by one of the Dash Core developers.
Updated about a year ago