比特币交易是要求全节点更新其包含的货币所有权信息的请求。为了将她的一些比特币转让给鲍勃，Alice 首先需要告诉全节点如何找到她接收这些比特币的先前交易。由于比特币的控制是通过交易输出进行分配的，Alice 使用一个输出点字段指向先前的输出。每个输入必须包含一个输出点。
输出点包含一个32字节的 txid，用于指向 Alice 接收比特币的交易。这个 txid 使用比特币内部的字节顺序表示（参见“内部和显示字节顺序”）。
因为交易可能包含多个输出，Alice 还需要标识该交易的特定输出索引，称为其输出索引。输出索引是从零开始的4字节无符号整数。
当一个全节点遇到一个输出点时，它会使用这些信息来查找被引用的输出。全节点只需要查看区块链中的先前交易。例如，Alice 的交易包含在块774,958中。验证她的交易的全节点只会在该块及之前的块中查找她的输出点引用的先前输出，而不会查找任何更晚的块。在块774,958中，它们只会查看排在 Alice 交易之前的区块中的交易，这由块的默克尔树中叶子节点的顺序决定。
在找到先前的输出后，全节点从中获取了几个关键的信息：
- 被分配给先前输出的比特币数量。这些比特币将在本次交易中转移。在示例交易中，先前输出的价值为100,000 satoshis。
- 先前输出的授权条件。这些是必须满足的条件，才能花费分配给先前输出的比特币。
- 对于已确认的交易，确认它的区块高度和该区块的中位时间过去（MTP）。这对于相对时间锁（在“作为共识强制相对时间锁的序列”中描述）和 coinbase 交易的输出（在“Coinbase 交易”中描述）是必要的。
- 先前输出存在于区块链中（或作为已知的未确认交易），并且没有其他交易花费它的证据。比特币的一个共识规则禁止任何输出在有效的区块链中被花费超过一次。这是针对双重支付的规则：Alice 不能使用同一个先前输出在不同的交易中分别支付给 Bob 和 Carol。试图花费相同先前输出的两个交易称为冲突交易，因为只有一个可以包含在有效的区块链中。
不同的全节点实现在不同的时期尝试了跟踪先前输出的不同方法。比特币核心目前使用被认为是最有效的解决方案，即保留所有必要信息同时最小化磁盘空间的解决方案：它维护一个数据库，存储每个未花费交易输出（UTXO）及其关键元数据（如其确认块高度）。每当新的交易块到达时，它们花费的所有输出都将从 UTXO 数据库中移除，而它们创建的所有输出都将添加到数据库中。
内部和显示字节顺序
比特币在各种情况下使用哈希函数的输出，称为摘要。摘要为区块和交易提供唯一标识符；它们用于地址、区块、交易、签名等的承诺；并且摘要在比特币的工作量证明功能中进行迭代。在某些情况下，哈希摘要以一种字节顺序显示给用户，但在内部使用另一种字节顺序，这可能会引起混淆。例如，考虑我们示例交易中的前一个输出的事务ID（txid）：
eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da135698679268041c54a
如果我们尝试使用Bitcoin Core来使用该txid检索该交易，我们会收到一个错误，并且必须反转其字节顺序：
$ bitcoin-cli getrawtransaction \
eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da135698679268041c54aerror code: -5
error message:
No such mempool or blockchain transaction.
Use gettransaction for wallet transactions.
$ echo eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da135698679268041c54a | fold -w2 | tac | tr -d "\n" 4ac541802679866935a19d4f40728bb89204d0cac90d85f3a51a19278fe33aeb
$ bitcoin-cli getrawtransaction \
4ac541802679866935a19d4f40728bb89204d0cac90d85f3a51a19278fe33aeb 02000000000101c25ae90c9f3d40cc1fc509ecfd54b06e35450702...
这种奇怪的行为可能是早期比特币软件设计决策的无意后果。从实际角度来看，这意味着比特币软件的开发者需要记住将显示给用户的交易和区块标识符中的字节顺序反转。在本书中，我们使用内部字节顺序一词来表示出现在交易和区块中的数据。我们使用显示字节顺序来表示显示给用户的形式。另一组常见术语是内部版本的小端字节顺序和显示版本的大端字节顺序。