Transaction Outpoint

What Is a Transaction Outpoint?

A transaction outpoint is a compact data structure that pinpoints a single output from a previous Bitcoin transaction. It consists of two fields: the transaction ID (TXID) of the transaction that created the output, and the output index (vout) indicating which output in that transaction is being referenced. Together, these two fields form a globally unique identifier for every unspent transaction output on the Bitcoin network.

Think of it like a mailing address for money. The TXID identifies which transaction "building" the funds live in, and the vout identifies which "apartment" within that building holds the specific coins. Without outpoints, Bitcoin nodes would have no way to know which coins a transaction intends to spend.

In Bitcoin Core's source code, the outpoint is represented by the COutPoint class, defined in transaction.h. It contains two public members: hash (the TXID) and n (the output index). This simple pairing is what makes Bitcoin's entire UTXO model work.

How It Works

When you create a Bitcoin transaction that spends existing coins, each input in your transaction must specify which UTXO it is consuming. It does this by including the outpoint of that UTXO: the TXID of the transaction that created it plus the zero-based index of the specific output.

1. A previous transaction creates one or more outputs, each assigned an index starting from 0
2. Those outputs enter the UTXO set and become available for spending
3. When a new transaction wants to spend one of those outputs, it references it by outpoint (TXID + vout)
4. Nodes validate that the referenced outpoint exists in the UTXO set
5. Once the spending transaction confirms, the outpoint is removed from the UTXO set permanently

Binary Format

In raw transaction hex, the outpoint appears at the beginning of each input and is exactly 36 bytes:

| Field  | Size     | Encoding      | Description                    |
|--------|----------|---------------|--------------------------------|
| TXID   | 32 bytes | Little-endian | Hash of the previous transaction |
| vout   | 4 bytes  | Little-endian | Index of the output to spend   |

Both fields are stored in little-endian byte order in the serialized transaction. This means the TXID appears byte-reversed compared to how block explorers display it (big-endian). For example, if a block explorer shows a TXID starting with a1b2c3..., the raw transaction hex stores it ending with ...c3b2a1.

Reading an Outpoint in Raw Hex

Consider a transaction input that spends the fourth output (index 3) of a previous transaction:

# Raw input hex (first 36 bytes = outpoint)
# Bytes 0-31:  TXID (little-endian)
7b1e2f3a4d5c6e7f8091a2b3c4d5e6f7...  # 32 bytes

# Bytes 32-35: vout (little-endian)
03000000                               # Index 3

# The outpoint uniquely identifies this UTXO:
# "Output #3 from transaction 7b1e2f3a..."

The 4-byte vout field uses uint32_t, allowing up to 4,294,967,295 possible outputs per transaction. In practice, transactions rarely have more than a few dozen outputs, but the field size accommodates any valid transaction.

The Null Outpoint

One special case exists: the coinbase transaction in each block. Since coinbase transactions create new bitcoins rather than spending existing ones, their single input uses a null outpoint: 32 bytes of zeros for the TXID and 0xffffffff for the vout. This signals to nodes that the input does not reference any previous output.

# Null outpoint (coinbase input)
TXID: 0000000000000000000000000000000000000000000000000000000000000000
vout: ffffffff  (4,294,967,295 in decimal)

Why It Matters

Double-Spend Prevention

Outpoints are central to how Bitcoin prevents double spending. The UTXO set is essentially a database keyed by outpoints. When a node validates a transaction, it checks that every input's outpoint exists in the set. Once the transaction confirms, those outpoints are removed. Any subsequent transaction attempting to reference the same outpoint will fail validation because the entry no longer exists.

In Bitcoin Core, the CCoinsViewCache::HaveInputs function performs this check: it verifies that every prevout (previous outpoint) of a transaction is present in the UTXO set. This is the consensus-level enforcement that makes each UTXO spendable exactly once.

Coin Selection

When a wallet constructs a transaction, its coin selection algorithm chooses which UTXOs to spend. Internally, the wallet tracks available coins by their outpoints. The selected outpoints become the inputs of the new transaction, and the wallet must ensure it has the signing authority to spend each one. For a deeper comparison of selection strategies, see the coin selection algorithm comparison.

Transaction Graph Analysis

Because every input explicitly references the outpoint it spends, the entire Bitcoin blockchain forms a directed acyclic graph of outpoints. Chain analysis tools traverse this graph to trace the flow of funds. Each outpoint acts as an edge connecting one transaction's output to another transaction's input, making the full history of any coin traceable back to its coinbase origin.

Use Cases

UTXO Management and Consolidation

Wallet software uses outpoints to track and manage a user's coin inventory. Operations like UTXO consolidation (combining many small UTXOs into fewer large ones) require selecting specific outpoints and constructing transactions that spend them all into a single output. Advanced users can use coin control features to manually choose which outpoints to include in a transaction, improving privacy or fee efficiency.

Deterministic Input Ordering (BIP 69)

BIP 69 defines a standard for sorting transaction inputs and outputs in lexicographic order. For inputs, the sort key is the outpoint itself: first by the previous transaction hash, then by the output index as a tiebreaker. This deterministic ordering helps prevent wallet fingerprinting, where an observer could identify which wallet software created a transaction based on how inputs are arranged. The standard is particularly relevant in privacy-focused protocols like CoinJoin, where consistent ordering makes all participants' inputs indistinguishable.

PSBTs and Multi-Party Signing

Partially Signed Bitcoin Transactions (PSBTs) rely on outpoints to coordinate between multiple signers. Each signer needs to know exactly which UTXOs the transaction spends (by outpoint) to verify the transaction and produce their signature. The outpoint serves as the canonical identifier that all parties agree on, even when they use different wallet software.

Layer 2 Protocols

Layer 2 systems like the Lightning Network and Spark reference on-chain outpoints extensively. A Lightning channel's funding transaction creates an outpoint that both parties monitor. Commitment transactions and justice transactions reference this funding outpoint. In Spark's architecture, virtual UTXOs maintain a conceptual link to on-chain outpoints while operating off-chain, enabling instant transfers without the overhead of tracking individual on-chain references for every payment.

Replace-By-Fee

Replace-by-fee (RBF) uses outpoints to identify which unconfirmed transaction is being replaced. When a user broadcasts a replacement transaction that spends at least one of the same outpoints as the original, nodes recognize the conflict and apply RBF rules to determine which version to keep in the mempool.

Risks and Considerations

Privacy Implications

Outpoints are fully transparent on the public blockchain. Anyone can trace which outpoint was spent by which transaction, building a complete spending graph. Techniques like CoinJoin, PayJoin, and careful coin selection help mitigate this by making it harder to link outpoints to specific users. The common-input-ownership heuristic assumes that all outpoints in a transaction's inputs belong to the same wallet, a powerful assumption that CoinJoin specifically aims to break.

UTXO Set Growth

Every unspent outpoint occupies space in the UTXO set, which full nodes must keep in memory for fast validation. As Bitcoin's history grows, managing the UTXO set becomes a scalability consideration. Outputs that are uneconomical to spend (where the value is less than the fee required to include the outpoint in a transaction) contribute to state bloat. The dust limit exists partly to prevent the creation of outpoints that will never be spent.

Outpoint Reuse After Reorgs

During a chain reorganization, outpoints that were consumed in the orphaned chain may reappear in the UTXO set. Transactions that spent those outpoints in the abandoned fork are no longer valid, and the coins return to their pre-spend state. This is why waiting for sufficient block confirmations matters: it reduces the probability that a confirmed outpoint consumption gets reversed.

Segwit and Outpoint References

Prior to SegWit, the TXID used in an outpoint was computed over the entire transaction, including signature data. This made TXIDs (and therefore outpoints) vulnerable to transaction malleability: a third party could modify the signature without invalidating it, changing the TXID and breaking any transaction that referenced the original outpoint. SegWit fixed this by excluding witness data from the TXID calculation, making outpoint references stable and reliable. For the full transaction flow from construction to confirmation, see the Bitcoin transaction lifecycle explained.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.