Bitcoin Transactions

Bitcoin transactions form the backbone of the blockchain network, enabling secure, decentralized value transfer without intermediaries. Understanding how these transactions work—from inputs and outputs to scripting and fees—is essential for anyone engaging with Bitcoin at a technical or investment level. This comprehensive guide breaks down the structure, mechanics, and evolution of Bitcoin transactions, including key innovations like Segregated Witness (SegWit) and advanced scripting capabilities.

Understanding Bitcoin Transactions

At its core, a Bitcoin transaction (often abbreviated as "Tx") is a digital record that transfers value between participants on the Bitcoin network. These transactions are grouped into blocks, which are then secured by cryptographic proof-of-work. The immutability and security of the blockchain ensure that once confirmed, transactions cannot be altered or reversed.

A basic transaction involves one party sending Bitcoin to another. For example, when Alice sends Bitcoin to Bob, the transaction includes:

• Inputs: References to previously unspent outputs (UTXOs) that fund the transfer.
• Outputs: New UTXOs created for the recipient (Bob) and any change returned to the sender (Alice).

Importantly, transaction inputs must equal or exceed outputs. Any difference is paid as a transaction fee to miners.

👉 Discover how real-time Bitcoin transactions are processed across the global network.

Unspent Transaction Outputs (UTXO) Explained

The UTXO model is fundamental to Bitcoin’s design. Unlike account-based systems (like traditional banking), Bitcoin tracks ownership through discrete, spendable outputs.

What Is a UTXO?

Each transaction output specifies:

1. A value in satoshis (the smallest unit of Bitcoin, where 1 BTC = 100,000,000 satoshis).
2. A locking script (scriptPubKey) defining who can spend it.

When an output hasn’t been used as an input in another transaction, it remains an Unspent Transaction Output (UTXO). The sum of all UTXOs linked to a public key hash represents the wallet’s balance.

For instance:

• Alice has a single UTXO of 0.1 BTC.
• She wants to send 0.015 BTC to Bob.

• Her transaction will have two outputs:

  • 0.015 BTC to Bob
  • 0.0845 BTC back to herself (as change)
• The remaining 0.0005 BTC becomes the miner fee.

Once confirmed, the original 0.1 BTC UTXO is marked as spent, and two new UTXOs are created.

Practical Example

Imagine Zhang San receives 12.5 BTC as a mining reward. Later:

1. He sends 2.5 BTC to Li Si.
2. Then, both contribute 2.5 BTC each to pay Wang Wu 5 BTC.

Each step creates new UTXOs while consuming old ones, maintaining a transparent and auditable ledger.

Transaction Inputs and Outputs

Transaction Output (vout)

Every Bitcoin transaction generates at least one output. These outputs become future UTXOs unless they're non-spendable (e.g., OP_RETURN data carriers). Each output contains:

• A value in satoshis.
• A locking script (scriptPubKey), also known as a cryptographic puzzle, which sets conditions for spending.

Common types include:

• P2PKH (Pay-to-Public-Key-Hash): Standard wallet-to-wallet transfers.
• P2SH (Pay-to-Script-Hash): For complex logic like multisig.
• P2WPKH/P2WSH: SegWit-native formats.

Transaction Input (vin)

An input references a prior UTXO and provides proof of ownership via an unlocking script (scriptSig). It consists of:

1. Transaction ID (txid): Identifies the source transaction.
2. Output index (vout): Specifies which output from that transaction is being spent.
3. ScriptSig: Contains signatures and public keys satisfying the locking conditions.
4. Sequence number: Used for replace-by-fee (RBF) and locktime features.

Inputs do not explicitly state the amount being spent—the network derives this by looking up the referenced UTXO.

How Bitcoin Script Validates Transactions

Bitcoin uses a simple stack-based scripting language to validate transactions securely. Two main components are involved:

Locking Script (scriptPubKey)

Placed in outputs, this defines the conditions required to spend the funds. For example:

OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG

This is a standard P2PKH script requiring a valid signature and matching public key.

Unlocking Script (scriptSig)

Provided in inputs, it supplies the data needed to satisfy the locking script—typically a digital signature and public key.

Validation works by executing both scripts sequentially on a stack:

1. Push signature and public key (from scriptSig).
2. Execute scriptPubKey operations.
3. If the final result is TRUE, the input is valid.

All inputs must pass validation for the entire transaction to be accepted.

👉 See how script validation ensures every Bitcoin transaction is secure and tamper-proof.

Transaction Fees: Incentivizing Miners

Fees are not explicitly stated in transactions but calculated as:

Fee = Sum(Input Values) - Sum(Output Values)

Wallets typically estimate fees based on network congestion and desired confirmation speed. While optional, higher fees increase priority in block inclusion. Transactions with low or no fees may remain unconfirmed for hours—or indefinitely during peak times.

SegWit adoption has reduced effective fees by counting witness data at a discounted rate (see below).

The Role of Locktime in Transactions

The locktime field specifies when a transaction can be added to the blockchain:

• If locktime = 0: Immediate processing.
• If < 500 million: Interpreted as block height.
• If ≥ 500 million: Unix timestamp (seconds since epoch).

However, if all input sequence numbers are 0xFFFFFFFF, locktime is ignored—allowing immediate confirmation even if set.

This feature enables time-locked contracts and advanced use cases like payment channels.

Transaction Serialization and Broadcasting

After creation, transactions are serialized into binary format using strict rules before being broadcast across the peer-to-peer network.

TxID Generation

The transaction ID (TxID) is a double-SHA256 hash of:

[nVersion][txins][txouts][nLockTime]

Note: Even with SegWit, this calculation excludes witness data—ensuring backward compatibility.

Example:

import hashlib
raw_tx = bytes.fromhex("01000000...")  # Serialized transaction
txid = hashlib.sha256(hashlib.sha256(raw_tx).digest()).digest()[::-1].hex()

This TxID uniquely identifies the transaction and is used in future inputs to reference it.

Advanced Scripting Features

Bitcoin supports sophisticated spending conditions beyond simple payments.

Multisignature (Multisig)

Requires M-of-N signatures to unlock funds (e.g., 2-of-3). Commonly used for corporate wallets or escrow services.

Locking script:

OP_2 <PubA> <PubB> <PubC> OP_3 OP_CHECKMULTISIG

Due to a historical bug, unlocking scripts must prepend a dummy 0.

Pay-to-Script-Hash (P2SH)

Allows sending to a hash of a redeem script instead of a public key. Simplifies complex logic for senders.

Example: A multisig setup where only the recipient needs to know the full script details upon redemption.

Benefits:

• Shorter addresses.
• Reduced sender-side complexity.
• Enhanced privacy.

OP_RETURN: Embedding Data

Enables storing arbitrary data (up to 80 bytes) in the blockchain—used for metadata, proofs, or NFT-like tokens. Outputs with OP_RETURN are provably unspendable and don’t bloat the UTXO set.

Segregated Witness (SegWit): A Major Upgrade

Activated in 2017, SegWit addressed critical limitations in Bitcoin’s original design.

What Is SegWit?

SegWit separates witness data (signatures) from transaction data:

• Signature scripts moved to a separate witness field.
• Original scriptSig becomes empty.
• Witness data does not affect TxID calculation.

This change resolves several issues:

Eliminates Transaction Malleability

Previously, attackers could alter signature encoding slightly—changing the TxID without invalidating the transaction. This caused problems for exchanges and payment channels.

With SegWit, TxIDs depend only on non-witness data, making them immutable pre-confirmation.

Improves Scalability and Efficiency

Witness data often accounts for over 75% of transaction size. By discounting it in block weight calculations (up to 4 MB effective capacity), SegWit increases throughput and lowers fees.

Nodes can also prune witness data after validation, reducing storage demands.

Additional Benefits

• Faster signature verification: Complexity reduced from O(n²) to O(n).
• Better hardware wallet support: Amounts included in signed data eliminate need for full transaction history during offline signing.

SegWit Address Formats: Bech32

SegWit introduced Bech32 addresses (BIP-0173), starting with bc1 on mainnet (tb1 on testnet). Advantages over legacy Base58Check:

• Case-insensitive.
• Better error detection.
• Compact QR codes.
• Human-readable prefixes prevent cross-chain confusion.

Examples:

• P2WPKH: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4
• P2WSH: bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3

Frequently Asked Questions

What is a UTXO?

A UTXO (Unspent Transaction Output) is a discrete amount of Bitcoin that can be spent as input in a new transaction. It represents your available balance across all wallet addresses.

How are Bitcoin transaction fees calculated?

Fees equal total input values minus total output values. Higher fees result in faster confirmations due to miner prioritization.

What problem does SegWit solve?

SegWit fixes transaction malleability, improves scalability via block weight adjustments, reduces fees, and enhances scripting efficiency.

Can I spend part of a UTXO?

No—you must spend the entire UTXO. Any excess is returned as change in a new output.

What is the difference between P2SH and P2WSH?

P2SH uses Base58 addresses and includes redeem scripts in inputs; P2WSH uses Bech32 addresses and stores redeem scripts in witness data—reducing cost and improving security.

Why are Bech32 addresses better?

They offer superior error detection, compact size, case insensitivity, and clearer formatting—making them safer and easier to use across platforms.

👉 Start exploring live Bitcoin transactions using modern wallet standards today.