When Bob sells coffee, Alice first constructs a transaction spending one of her available inputs to an address owned by Bob. The resulting transaction gets put into a block and is given a
txidto identify it. The
txid is the double-SHA256 of the serialized transaction.
Within the transaction, there may be multiple outputs - one of these will be the output which is locked with the hash of Bob's public key. The output is referenced by its index within the transaction, called the
outputIndex. Collectively, the
txid and the
outputIndex make up the
The output which now belongs to bob is an unspent transaction output (UTXO). The bitcoin client keeps a map of all UTXOs in a memory-mapped database, so that they can efficiently be found from their
If Bob wishes to later spend the UTXO, he creates a transaction with the input using this
outPoint and the outputs containing a (eg P2PKH) script for where the money gets spent. He signs the transaction, and inserts the signature into the
scriptSig for the input being spent.
The validator of this new transaction will look into the UTXO set to find the previous transaction where Alice paid Bob, and will extract the
txout from it. They will validate the amount being spent, and the
scriptPubKey will be evaluated to make sure Bob can spend it. If the transaction is valid, the new transaction outputs will be added to the UTXO set and the original transaction where Alice paid Bob will be removed from the UTXO set.
This makes normal operation of the bitcoin protocol efficient, but it is inefficient for querying historical data as block explorers do for example. The main reason is because the
txids are not stored in the blockchain data, only in the UTXO set. To find a
txid not in the UTXO set would require scanning the entire blockchain and recomputing the
txid for each transaction until you find the one you're interested in.
For that reason, block explorers, or similar software, will maintain a completely separate transaction index from the blockchain archive, where they can discover any transaction based on its
txid and find where it is located in the chain. If you are re-indexing the blockchain in such way, it is also possible to add relationships in the forward direction, so that you can find the transaction input which spent a particular output. You would need a lot of additional storage for the txids and their indices.