<p>This is an interesting problem, one that has been studied and discuss within the bitcoin community quite a bit.</p>

<p>The basic way to do this is to keep track of a normalized TXID alongside of the actual TXID used in the protocol. Then to calculate the normalized ID of a transaction, you serialize it:</p>

<ul>
<li>With the inputs' txids replaced by their normalized transaction</li>
<li>Removing the scriptSigs (as those are the most malleable parts of a transaction)</li>
</ul>

<p>The only caveat is that that this doesn't need to be done for coinbase transactions, as the scriptSig is not malleable (since it's already in a block) and there are no real txids in the inputs. You also don't want to remove the scriptSig from the coinbase transaction because it contains the height of the block (per BIP34), which guarantees the TXID (and normalized TXID) will be unique. Hence, for coinbase transactions, the normalized transaction id is the same as the transaction id (nTXID == TXID). </p>

<hr> 

<p>Note: this is a lot of work to keep track of normalized IDs for every transaction. It has not been implemented in Bitcoin Core yet, and implementing your own version of this may be time consuming. </p>

<p>If you can guarantee the set of outputs in all transactions within your system will be unique (i.e. you are using new receiving addresses and new change addresses for every transaction), then you might be able to use a hash of the set of outputs as a unique identifier. This would be more specific to your use case, as a temporary fix while Bitcoin Core doesn't yet have support for normalized transaction ids.</p>

<p>Some further resources:</p>

<ul>
<li><a href="https://github.com/bitcoin/bitcoin/pull/3656" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/pull/3656</a></li>
<li><a href="https://bitcoin.stackexchange.com/questions/22168/what-is-the-normalized-transaction-hash-of-a-transaction">What is the normalized transaction hash of a transaction?</a></li>
<li><a href="https://bitcoin.stackexchange.com/questions/23310/when-computing-a-normalized-transaction-id-when-do-i-finalize-the-sha256-hash">When computing a normalized transaction id, when do I finalize the sha256 hash?</a></li>
</ul>

CC BY-SA 3.0
2015-05-27T15:45:20.943Z
I'm not sure if hashing the outputs would help, since anyone could create a hash of the same outputs to attack my system (it would cost them bitcoin, but not much - my application will always send the minimum amount of BTC). What about hashing the inputs?
bvpx
CC BY-SA 3.0
2015-05-27T15:52:41.923Z
@bvpx, very good point. Well, inputs are the parts that are malleable, so it's hard to include the input data. Keep in mind that inputs have the (prevout txid, prevout index, scriptSig, and sequence number). The prevout txid and scriptSig are occasionally malleable, and the other two aren't all that unique. No good option :(
morsecoder
CC BY-SA 3.0
2015-05-27T15:27:08.800Z
2015-05-27T15:32:33.363Z
2017-04-13T12:47:33.583Z
morsecoder
<p>You can still use the <code>txid</code> to identify it in your database. You just have to make sure you wait enough confirmations to trust the transaction, and that it can't be "malleated" by other parties. If you receive 2 transactions which have same inputs/outputs but different transaction ids, then you simply keep one (maybe the first one) and discard the other. In other words, identify transactions however you want, just remember not to trust unconfirmed ones.</p>

CC BY-SA 3.0
2015-05-27T15:26:57.857Z
2015-05-27T15:26:57.857Z
Luca Matteis
<p>Transactions I broadcast can be malleated by anyone watching the mempool (more info <a href="https://gist.github.com/sipa/8907691">here</a>).</p>

<p>This rules out using <code>txid</code> for transaction identification.</p>

<p>How can I identify my transactions to make sure they are tracked by my application, even if the <code>txid</code> changes by the time the transaction is mined in a block?</p>

CC BY-SA 3.0
2015-05-29T12:19:30.670Z
Tracking the UTXO:s it spends and the outputs it creates.
Natanael
<transactions><utxo><transaction-malleability><mempool>
How do I uniquely identify a transaction (to protect against malleability)?
bvpx
# How do I uniquely identify a transaction (to protect against malleability)?

(Asked by: username_0 on 2015-05-27)

Transactions I broadcast can be malleated by anyone watching the mempool (more info [here](https://gist.github.com/sipa/8907691)).

This rules out using `txid` for transaction identification.

How can I identify my transactions to make sure they are tracked by my application, even if the `txid` changes by the time the transaction is mined in a block?

**Tags:** transactions, utxo, transaction-malleability, mempool

> **Comments:**
> **username_1**: Tracking the UTXO:s it spends and the outputs it creates.  

---

## 2 answers

### Answer by username_2 on 2015-05-27. Score: 5

This is an interesting problem, one that has been studied and discuss within the bitcoin community quite a bit.

The basic way to do this is to keep track of a normalized TXID alongside of the actual TXID used in the protocol. Then to calculate the normalized ID of a transaction, you serialize it:

* With the inputs' txids replaced by their normalized transaction
* Removing the scriptSigs (as those are the most malleable parts of a transaction)

The only caveat is that that this doesn't need to be done for coinbase transactions, as the scriptSig is not malleable (since it's already in a block) and there are no real txids in the inputs. You also don't want to remove the scriptSig from the coinbase transaction because it contains the height of the block (per BIP34), which guarantees the TXID (and normalized TXID) will be unique. Hence, for coinbase transactions, the normalized transaction id is the same as the transaction id (nTXID == TXID).

---

Note: this is a lot of work to keep track of normalized IDs for every transaction. It has not been implemented in Bitcoin Core yet, and implementing your own version of this may be time consuming.

If you can guarantee the set of outputs in all transactions within your system will be unique (i.e. you are using new receiving addresses and new change addresses for every transaction), then you might be able to use a hash of the set of outputs as a unique identifier. This would be more specific to your use case, as a temporary fix while Bitcoin Core doesn't yet have support for normalized transaction ids.

Some further resources:

* <https://github.com/bitcoin/bitcoin/pull/3656>
* [What is the normalized transaction hash of a transaction?](https://bitcoin.stackexchange.com/questions/22168/what-is-the-normalized-transaction-hash-of-a-transaction)
* [When computing a normalized transaction id, when do I finalize the sha256 hash?](https://bitcoin.stackexchange.com/questions/23310/when-computing-a-normalized-transaction-id-when-do-i-finalize-the-sha256-hash)

> **Comments:**
> **username_0**: I'm not sure if hashing the outputs would help, since anyone could create a hash of the same outputs to attack my system (it would cost them bitcoin, but not much - my application will always send the minimum amount of BTC). What about hashing the inputs?  
> **username_2**: @username_0, very good point. Well, inputs are the parts that are malleable, so it's hard to include the input data. Keep in mind that inputs have the (prevout txid, prevout index, scriptSig, and sequence number). The prevout txid and scriptSig are occasionally malleable, and the other two aren't all that unique. No good option :(  

---

### Answer by username_3 on 2015-05-27. Score: 1

You can still use the `txid` to identify it in your database. You just have to make sure you wait enough confirmations to trust the transaction, and that it can't be "malleated" by other parties. If you receive 2 transactions which have same inputs/outputs but different transaction ids, then you simply keep one (maybe the first one) and discard the other. In other words, identify transactions however you want, just remember not to trust unconfirmed ones.


---

