Referencing Spendability

When a Bitcoin node receives a transaction, it must verify that the inputs are valid. It uses the TXID and VOUT to perform a lookup in its local database.

1. The Lookup Process

The node does not search the entire blockchain to verify an input. Instead, it looks in the Chainstate (UTXO Set).

1. The node takes the TXID and VOUT from the incoming input.

2. It queries the UTXO Set to see if that OutPoint exists.

3. If it doesn't exist, the transaction is rejected (either the money doesn't exist or it has already been spent).

2. Retrieving the "Lock"

If the OutPoint exists, the database returns two crucial pieces of information:

• The Amount: How many satoshis are in this output.

• The ScriptPubKey: The locking script that defines the ownership rules.

3. Verification Logic

Once the node has the ScriptPubKey (the lock) from the database and the ScriptSig (the key) from the input, it executes them together in the Bitcoin Script Virtual Machine.

• If the result is TRUE, the input is verified.

• The node then removes that OutPoint from the UTXO Set to prevent it from being spent again (Double-Spend protection).

4. Why TXIDs Must Be Unique

If two different transactions had the same TXID (a collision), the UTXO Set would become corrupted.

• In the past, two coinbase transactions could have the same hash if they had the same outputs and were in the same height.

• BIP 34 fixed this by requiring the block height to be included in the coinbase script, ensuring every coinbase (and thus every TXID) is unique.

Data Source	Content	Purpose
Input Hex	TXID + VOUT	The "Search Query"
UTXO Set	ScriptPubKey + Amount	The "Verification Target"
Input Hex	ScriptSig / Witness	The "Proof of Ownership"

In the final section, we will build a Python OutPoint Parser to extract these details from raw hex data.