Understanding Bitcoin Transactions: Inputs, Outputs, and Scripting

Bitcoin transactions form the backbone of the entire Bitcoin network. Every aspect of the system—from wallet software to mining and blockchain consensus—is designed to ensure that transactions can be created, propagated across the network, validated, and permanently recorded in the global ledger known as the Bitcoin blockchain. At its core, a Bitcoin transaction is a data structure encoding the transfer of value between participants. Unlike traditional financial systems, Bitcoin does not rely on accounts, balances, or addresses at the protocol level. Instead, it uses a model based on unspent transaction outputs (UTXOs) and cryptographic scripting to track ownership and enable secure value transfers.

This chapter breaks down how Bitcoin transactions work under the hood: their structure, creation, validation, and integration into the blockchain. We'll explore inputs, outputs, transaction fees, digital signatures, and the powerful scripting language that makes Bitcoin programmable.

Transaction Structure: What’s Really Inside?

When you view a transaction in a blockchain explorer—like Alice paying Bob for coffee—it often appears as a simple transfer from one "address" to another. However, this is a high-level abstraction. The actual transaction data looks very different.

Using Bitcoin Core's command-line tools (getrawtransaction and decoderawtransaction), we can inspect the raw transaction:

{
  "version": 1,
  "locktime": 0,
  "vin": [
    {
      "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
      "vout": 0,
      "scriptSig": "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.01500000,
      "scriptPubKey": "OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG"
    },
    {
      "value": 0.08450000,
      "scriptPubKey": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG"
    }
  ]
}

Notice: there are no explicit sender or receiver addresses. There’s no field labeled “Alice” or “Bob.” Instead, what we see are inputs and outputs, linked through cryptographic scripts.

👉 Discover how wallets turn complex scripts into simple payments with one click.

Unspent Transaction Outputs (UTXOs): The Building Blocks of Value

The fundamental unit of value in Bitcoin is the Unspent Transaction Output (UTXO). Each UTXO represents a discrete amount of bitcoin—denominated in satoshis (the smallest unit, where 1 BTC = 100,000,000 satoshis)—that can be spent in a future transaction.

Think of UTXOs like physical coins or bills: they come in fixed denominations and must be used whole. If you want to spend part of a UTXO, the entire amount is consumed, and change is sent back to your wallet as a new UTXO.

For example:

You have a 2 BTC UTXO.
You want to send 0.5 BTC to someone.
Your transaction consumes the full 2 BTC UTXO.
It creates two outputs:
- One for 0.5 BTC (to recipient)
- One for 1.5 BTC (as change to yourself)

This mechanism explains why most Bitcoin transactions have multiple outputs—even when sending money to just one person.

Wallets calculate your “balance” by scanning the blockchain for all UTXOs tied to your keys. This balance isn’t stored on the blockchain; it’s derived by summing up your unspent outputs.

How Wallets Handle UTXO Selection

Just like using exact change or breaking a large bill at a store, wallets use strategies to select UTXOs:

Combine small UTXOs to meet payment needs.
Use one large UTXO and receive change.
Minimize transaction size and fees.

All of this happens automatically behind the scenes.

Did you know? The first transaction in every block is called a coinbase transaction. It has no inputs—it creates new bitcoins out of thin air as a mining reward. This is how new BTC enters circulation.

Transaction Inputs: Spending What You Own

A transaction input references a specific UTXO by:

Transaction ID (txid): The hash of the transaction that created the UTXO.
Output Index (vout): Which output in that transaction is being spent (starting from 0).

It also includes:

scriptSig: A script that satisfies the spending conditions of the referenced UTXO (usually a digital signature and public key).
Sequence Number: Used for advanced features like Replace-by-Fee (RBF) or timelocks.

To validate an input, nodes must:

Retrieve the referenced UTXO.
Check its value and locking script.
Verify the unlocking script (scriptSig) correctly satisfies the conditions.

This means a single transaction cannot be fully understood without accessing prior transactions—a key reason full nodes maintain a complete copy of the UTXO set.

Transaction Fees: Incentivizing Miners

Most transactions include a fee, which incentivizes miners to include them in the next block. Fees are not mandatory but significantly affect confirmation speed.

How Fees Are Calculated

Fees are based on transaction size in bytes, not the amount of bitcoin sent. Larger transactions (e.g., those with many inputs) cost more to confirm.

The fee is simply:

Fee = Sum of Inputs – Sum of Outputs

If you forget to include change in your transaction, the leftover amount becomes the fee—potentially giving miners a huge tip!

Example:

Input: 1 BTC
Output: 0.8 BTC (to recipient)
No change output
Result: 0.2 BTC fee → very expensive mistake!

👉 See how smart fee estimation helps avoid costly errors.

Dynamic Fee Estimation

Modern wallets use real-time data to estimate optimal fees. Services like bitcoinfees.21.co provide recommendations based on current network congestion:

High Priority: Faster confirmation (~next block)
Medium: Balanced speed and cost
Low: Cheaper but slower

APIs return values like:

{"fastestFee":80,"halfHourFee":80,"hourFee":60}

Meaning: Pay 80 sat/vB for immediate inclusion.

Static fees no longer work—transactions may get stuck for hours or days.

Bitcoin Script: The Language of Transactions

Bitcoin uses a simple, stack-based scripting language to define spending conditions. This allows for powerful flexibility beyond simple payments.

Key Concepts

Locking Script (scriptPubKey): Attached to an output; defines how it can be spent.
Unlocking Script (scriptSig): Provided in an input; proves ownership (e.g., via signature).

During validation:

Unlocking script runs first.
Then locking script runs.
If final result is TRUE, the spend is valid.

Scripts are intentionally not Turing-complete—no loops or infinite computation—to prevent denial-of-service attacks.

Pay-to-Public-Key-Hash (P2PKH): The Most Common Script

Most Bitcoin transactions use P2PKH, which locks funds to a public key hash (i.e., a Bitcoin address).

Locking Script Example:

OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Unlocking Script:

<Signature> <PublicKey>

When combined and executed:

Public key is hashed and matched against PubKeyHash.
Signature is verified against public key.
If both pass → transaction valid.

This ensures only the owner of the private key can spend the funds.

Digital Signatures (ECDSA): Proving Ownership

Bitcoin uses Elliptic Curve Digital Signature Algorithm (ECDSA) to sign transactions.

How It Works

Signer uses their private key to generate a signature (R, S) over transaction data.
Anyone can verify the signature using the corresponding public key.
Verification proves:
- The signer owns the private key.
- The transaction hasn’t been altered.
- The signature cannot be repudiated.

Signatures are encoded using DER format and appended with a SIGHASH flag indicating what part of the transaction is committed.

SIGHASH Flags

Flag	Meaning
`ALL`	Signs all inputs and outputs (most common)
`NONE`	Signs inputs only; outputs can change
`SINGLE`	Signs one input and matching output
`ANYONECANPAY`	Can be combined; allows adding new inputs

These enable advanced use cases like crowdfunding or multi-party transactions.

Critical Security Note: Reusing the random k value in ECDSA exposes your private key. Always use deterministic k generation (RFC 6979).

From Raw Data to User Experience

Blockchain explorers and wallets create familiar concepts—addresses, balances, send/receive history—by interpreting low-level data:

Addresses are derived from public key hashes in scripts.
Balances are sums of relevant UTXOs.
Transactions are reconstructed from inputs and outputs.

But not all transactions follow standard patterns. Complex scripts (e.g., multisig, time-locked contracts) may confuse basic tools—highlighting the gap between protocol reality and user interface simplicity.

Frequently Asked Questions (FAQ)

Q: What is a UTXO?

A: An Unspent Transaction Output is a discrete unit of bitcoin that can be spent as input in a future transaction. It represents ownership until consumed.

Q: Why do I get change in Bitcoin?

A: Because UTXOs are indivisible. When you spend one, you must use it entirely and create new outputs for any leftover amount.

Q: How are transaction fees determined?

A: Fees depend on transaction size (in bytes) and network demand. Wallets estimate fees using real-time data to balance cost and speed.

Q: Can I send Bitcoin without paying a fee?

A: Yes, but your transaction may take hours or days to confirm—or never confirm at all during high congestion.

Q: What happens if I reuse a signature's random number (k)?

A: Your private key can be mathematically derived from the signatures, leading to complete loss of funds.

Q: Are Bitcoin addresses stored in transactions?

A: No. Addresses are human-readable representations of public key hashes embedded in locking scripts. They’re reconstructed by wallets and explorers.

👉 Learn how advanced wallets manage keys and scripts securely.