user12455: All the recent problems caused by transaction malleability have brought to the center stage the fact that tracking a transaction id is not good enough.
So here is my question, what is good enough?
The best I can come up with, is to create my own hash of the transaction I want to track before sending it to the network. Let's call that hash "tracking id". That hash would cover only signed portions of the transaction. The elements hashed would be 

for all inputs: txid, vout
for all outputs: amount, address

Given the fact that the transaction must still be declared valid by the official client, would this "tracking id" be robust enough to track a transaction no matter how it may have been covertly "adjusted" through transaction malleability?
If this scheme does not work, do you know of any way that would allow me to safely track the transaction?

user8717: It's obvious that given the malleability issue you shouldn't use the transaction hash to track a transaction. If your wallet software needs to track a specific transaction it should check its inputs against the block chain, and track it based on that.
The idea is to always rely on the block chain and check inputs/outputs for yourself. Don't rely on the transaction hash for identification purposes.

Edit: One way to implement a solution is to track the referenced output instead of the transaction hash. If you get two unconfirmed transactions, that have different hashes but use the same referenced output, you know something fishy is going on. Therefore a good way to start tracking things would be to make sure the referenced outputs (within an input of a transaction) are not being used more than once.

user85: The signing hash is immutable, since that's precisely what you signed. Using the signing hash to track the transaction should ensure you are not vulnerable to any malleability attacks.

user12455: Since none of the answers that were given were fully fleshed enough to properly answer my question, I'm posting my own answer which synthesizes everything that has been said:
The best way to track a transaction in a way that will be resistant to transaction malleability, is to actually track only the data that has been signed. To do so, I suggest using a double SHA256 of the signed data. The documentation of the OP_CHECKSIG script operation (and it's very useful diagram form hints at which procedure should be followed.
A transaction malleability invariant "Tracking Hash" can be obtained from a pay-to-pubkey-hash transaction by:

Verify the technical validity of the transaction, as is done the reference bitcoin client. This includes verifying the signatures of the transaction. This is a crucial step, if you don't do that, the tracking hash is useless.
double SHA-256 hashing all of the following things:

the version number
the number of inputs
for each input :

the transaction ID of the output to spend
the index of the output to spend
the sequence number
(Note: We intentionally do not hash the input script or the length of the input script)

the number of outputs
for each output:

the amount
the length of the output script
the whole output script

the lockTime


Doing this should give you a nice tracking hash, that will be the same for all equivalent transactions, no matter how it may have been modified by taking advantage of transaction malleability.
Note that this tracking hash is not part of the bitcoin protocol, so you will not find it in the blockchain, and you won't be able to look it up using blockchain.info.

12455: <p>All the recent problems caused by transaction malleability have brought to the center stage the fact that tracking a transaction id is not good enough.</p>

<p>So here is my question, what is good enough?</p>

<p>The best I can come up with, is to create my own hash of the transaction I want to track before sending it to the network. Let's call that hash "tracking id". That hash would cover only signed portions of the transaction. The elements hashed would be </p>

<ul>
<li>for all inputs: txid, vout</li>
<li>for all outputs: amount, address</li>
</ul>

<p>Given the fact that the transaction must still be declared valid by the official client, would this "tracking id" be robust enough to track a transaction no matter how it may have been covertly "adjusted" through transaction malleability?</p>

<p>If this scheme does not work, do you know of any way that would allow me to safely track the transaction?</p>
 8717: <p>It's obvious that given the malleability issue you shouldn't use the transaction hash to track a transaction. If your wallet software needs to track a specific transaction it should check its inputs against the block chain, and track it based on that.</p>

<p>The idea is to always rely on the block chain and check inputs/outputs for yourself. Don't rely on the transaction hash for identification purposes.</p>

<hr>

<p><strong>Edit</strong>: One way to implement a solution is to track the referenced output instead of the transaction hash. If you get two unconfirmed transactions, that have different hashes but use the same referenced output, you know something fishy is going on. Therefore a good way to start tracking things would be to make sure the referenced outputs (within an input of a transaction) are not being used more than once.</p>
 85: <p>The signing hash is immutable, since that's precisely what you signed. Using the signing hash to track the transaction should ensure you are not vulnerable to any malleability attacks.</p>
 12455: <p>Since none of the answers that were given were fully fleshed enough to properly answer my question, I'm posting my own answer which synthesizes everything that has been said:</p>

<p>The best way to track a transaction in a way that will be resistant to transaction malleability, is to actually track only the data that has been signed. To do so, I suggest using a double SHA256 of the signed data. The documentation of the <a href="https://en.bitcoin.it/wiki/OP_CHECKSIG" rel="nofollow">OP_CHECKSIG</a> script operation (and it's very useful <a href="https://en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png" rel="nofollow">diagram form</a> hints at which procedure should be followed.</p>

<p>A transaction malleability invariant "Tracking Hash" can be obtained from a pay-to-pubkey-hash transaction by:</p>

<ol>
<li>Verify the technical validity of the transaction, as is done the reference bitcoin client. This includes verifying the signatures of the transaction. This is a crucial step, if you don't do that, the <em>tracking hash</em> is useless.</li>
<li>double SHA-256 hashing all of the following things:
<ol>
<li>the version number</li>
<li>the number of inputs</li>
<li>for each input :
<ol>
<li>the transaction ID of the output to spend</li>
<li>the index of the output to spend</li>
<li>the sequence number</li>
<li>(Note: We intentionally do not hash the input script or the length of the input script)</li>
</ol></li>
<li>the number of outputs</li>
<li>for each output:
<ol>
<li>the amount</li>
<li>the length of the output script</li>
<li>the whole output script</li>
</ol></li>
<li>the lockTime</li>
</ol></li>
</ol>

<p>Doing this should give you a nice <em>tracking hash</em>, that will be the same for all equivalent transactions, no matter how it may have been modified by taking advantage of transaction malleability.</p>

<p>Note that this <em>tracking hash</em> is not part of the bitcoin protocol, so you will not find it in the blockchain, and you won't be able to look it up using blockchain.info.</p>
