What Is a Transaction Input? Understanding BSV Transaction Inputs and UTXO References

In BSV’s UTXO model, a transaction input is the funding source of the current transaction. It does not mean “subtract money from an account.” Instead, it explicitly references an unspent output from a previous transaction and provides the data needed to unlock that output.

Understanding inputs is essential for understanding BSV transaction structure, fees, UTXO selection, double-spend conflicts, and transaction debugging.

What Is a Transaction Input?

In short:

A transaction input is the current transaction’s reference to a previous unspent transaction output, or UTXO.

BSV does not use an account-balance model. A transaction is not simply written as:

• subtract 10 from Alice;
• add 10 to Bob.

In the UTXO model, funds exist as a set of unspent transaction outputs. To create a new transaction, you must specify which previous output the new transaction is spending.

That reference to the previous output is the input.

Except for special coinbase transactions, ordinary transactions must reference existing UTXOs through their inputs. Without an input, a transaction has no funding source.

Why Transactions Need Inputs

In the UTXO model, money is not stored in an account balance field. It is distributed across multiple unspent transaction outputs.

When you want to spend, you need to do two things:

1. identify which previous output you want to spend;
2. prove that you are authorized to spend it.

A typical input therefore includes:

• the TXID of the previous transaction;
• the output index in that previous transaction;
• the script or signature data needed to unlock that output;
• control fields such as a sequence number.

Taken together, an input means:

I want to spend the Nth output from a previous transaction, and I am providing the required unlocking material.

Outpoint: The Key Reference in an Input

The most important part of an input is the outpoint.

An outpoint consists of two parts:

Suppose a previous transaction has the TXID abc...123 and contains two outputs:

If the current transaction wants to spend Alice’s 100 satoshis, it must reference:

The TXID alone is not enough. A single transaction can contain multiple outputs, so the output index is required to identify exactly which output is being spent.

An Input Is Not the Same as the Payer

Beginners often interpret an input as “the payer.” That is not accurate.

An input is the source of funds, not the identity of the payer.

It references an old UTXO. Who can spend that UTXO depends on the locking script in the old output and whether the unlocking data provided by the current input satisfies it.

For example, in a common P2PKH scenario, the old output may be locked to a particular public key hash. To spend it, the current input needs to provide:

• the corresponding public key;
• a valid signature.

During network validation, nodes check whether:

• the public key hash matches the locking condition in the old output;
• the signature is valid.

Only if validation succeeds is the old UTXO accepted as legally spent.

A Transaction Can Have Multiple Inputs

A transaction does not have to reference only one UTXO. Many transactions have multiple inputs, which usually means they are combining several old UTXOs.

Assume a wallet has three UTXOs:

To pay 100 satoshis, no single UTXO is enough. The wallet can select multiple UTXOs as inputs:

The total input value is 120 satoshis. The transaction can then create outputs such as:

A multi-input transaction is therefore not unusual. It simply means the transaction spends multiple UTXOs.

Unlocking Data in an Input

An input does more than reference an old output. It also provides evidence that the transaction is allowed to spend it.

In a common P2PKH scenario, the input provides:

• a signature;
• a public key.

The locking script in the old output checks whether:

• the public key hash matches;
• the signature is valid.

This is the relationship between inputs and Script:

The input provides the unlocking material, while the old output provides the locking condition.

Transaction validation only succeeds when the two match.

Inputs and Double Spending

The same UTXO can only be spent once.

If two transactions reference the same outpoint, they are conflicting transactions. For example:

These two transactions cannot both be valid. The network can ultimately accept only one of them into the valid chain.

This is how the double-spend problem appears at the transaction-structure level: multiple transactions attempt to spend the same UTXO.

Why Inputs Matter in BSV Development

When building BSV applications, inputs affect many engineering concerns, including:

• how a wallet selects UTXOs;
• how fees are calculated;
• the size of the transaction;
• whether small UTXOs need to be consolidated;
• whether address relationships may be exposed;
• whether the transaction depends on unconfirmed ancestor transactions;
• whether the signature matches the old output.

SDKs and wallets can often select inputs automatically, but developers should not always treat inputs as a black box.

When transaction construction or broadcasting fails, common causes include:

• the input references the wrong outpoint;
• the UTXO has already been spent;
• the output index is incorrect;
• the signature does not match the locking condition of the old output;
• there is a problem with an unconfirmed ancestor transaction that this transaction depends on.

Understanding the structure of inputs helps you diagnose these issues.

Common Misunderstandings

The following points about transaction inputs are especially easy to confuse:

• an input is not the payer’s account; it is a reference to an old UTXO;
• the previous TXID alone is not enough; the output index is also required;
• an input is not simply a field where you enter an amount; validation also requires the amount and script of the previous output;
• multi-input transactions are not abnormal; they simply spend multiple UTXOs;
• if two transactions reference the same UTXO, they conflict;
• the signature provided by the input must match the locking condition of the old output.

Summary

A transaction input is, at its core, a reference to and unlocking of an old UTXO.

It answers two key questions:

1. Where does this transaction’s money come from?
2. Is the current transaction authorized to spend that money?

In BSV, understanding inputs is not only part of understanding the transaction format. It is also directly relevant to wallet design, transaction construction, fee estimation, UTXO management, and troubleshooting.

References

• BSV Transactions docs
• Transaction Inputs and Outputs
• Advanced Transaction Construction