7

Transactions I broadcast can be malleated by anyone watching the mempool (more info here).

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?

Murch
  • 71,155
  • 33
  • 180
  • 600
bvpx
  • 1,132
  • 7
  • 28

2 Answers2

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:

Community
  • 1
morsecoder
  • 14,008
  • 2
  • 42
  • 92
  • 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 May 27 '15 at 15:45
  • @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 May 27 '15 at 15:52
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.

Luca Matteis
  • 5,182
  • 17
  • 24