Where is the Transaction ID stored?

[deepskydiver]

Hi everyone,

I'm doing a little self education. I believe I understand the format and what is stored in the header and individual transactions but I have a gap I can't find the answer to.
The only ID I can find is for the transaction the unspent outputs are being pulled from. I can't find where the ID of the transaction itself is stored..?

Thanks for any help!

[1715512317]

1715512317

[1715512317]

1715512317

[1715512317]

1715512317

[1715512317]

1715512317

[jackg]

Whereabouts are you looking for it? Are you in the code itself or on a data file/block data?

There's a chance there isn't one stored in the block files because it might only exist in the chainstate and can be built by each node based on the transaction data itself (and that can't become dangerously corrupted because it's signed if it's legitimate).

[deepskydiver]

I'm thinking in the data - I can't find where in the blockchain each transaction ID is stored. It can't be calculated each time a node reads all of the blocks can it?
It's just missing from every reference I can find. I can see how it's calculated just not where it's put!

[pooya87]

Nodes only have to store blocks and nothing else. The transactions inside a block don't have IDs, they have to be calculated on the fly. They don't need to compute it except when they are verifying the block header (merkle root hash).

There is an additional database that nodes build which is optional but necessary. This database contains UTXOs and they contain the transaction ID and some extra information to make verification easier since each transaction input only contains a reference to the output they are spending by using its transaction ID (and index).
When a UTXO is spent it will be removed from this database and with it the txid will go away too.

[deepskydiver]

Thank you - that's helpful.
I had felt certain that the transaction ID would be held somewhere within the block initially.
But your explanation also makes me realise that storing the transaction ID would have little point as it's trivial to calculate - probably faster than the time it takes to read the transaction it's based on.
And it's interesting to consider too that the transaction list would of course be cleaned up to remove those which had no unspent amount in them.

Thanks again!

[TheArchaeologist]

To elaborate a bit on the excellent answer of pooya87 check out how to get from raw transaction to the transaction-id using a  transaction from block 100000 as example. The raw transaction is what is stored within a block on the blockchain.

Code:

txid: 
e9a66845e05d5abc0ad04ec80f774a7e585c6e8db975962d069a522137b80c1d

raw transaction:
01000000010b6072b386d4a773235237f64c1126ac3b240c84b917a3909ba1c43ded5f51f4000000008c493046022100bb1ad26df930a51cce110cf44f7a48c3c561fd977500b1ae5d6b6fd13d0b3f4a022100c5b42951acedff14abba2736fd574bdb465f3e6f8da12e2c5303954aca7f78f3014104a7135bfe824c97ecc01ec7d7e336185c81e2aa2c41ab175407c09484ce9694b44953fcb751206564a9c24dd094d42fdbfdd5aad3e063ce6af4cfaaea4ea14fbbffffffff0140420f00000000001976a91439aa3d569e06a1d7926dc4be1193c99bf2eb9ee088ac00000000

Perform a SHA-256 hash on the raw transaction twice ( you can do this online using https://emn178.github.io/online-tools/sha256.html, use input-type hex):

Code:

SHA-256((0100.. 0a00) = 201fa3cb0ad2a6f14d87492a582ccaa6dc6635946b700e2ab45099d2609ae187
SHA-256(201fa3cb0ad2a6f14d87492a582ccaa6dc6635946b700e2ab45099d2609ae187) = 1d0cb83721529a062d9675b98d6e5c587e4a770fc84ed00abc5a5de04568a6e9

So the outcome calculated is 1d0cb83721529a062d9675b98d6e5c587e4a770fc84ed00abc5a5de04568a6e9 which does not match the txid expected. This is because bitcoin uses little-endian notation for the txid in which the least significant byte is on the far left. In other words the bytes calculated for the hash-256 should be encoded as little endian by reversing the byte order.

This means the e9 (least significant byte, at he most right should go the far left: e9....
The next byte is added to this becoming: e9a6
Completing this reversing will give: e9a66845e05d5abc0ad04ec80f774a7e585c6e8db975962d069a522137b80c1d, which is the txid expected.

Check out more info about big-endian and little-endian here: https://www.techtarget.com/searchnetworking/definition/big-endian-and-little-endian. Although that doesn't answer why Bitcoin choose to use little endian in the first place for txid's.