Bitcoin transactions form the backbone of the cryptocurrency’s decentralized network, enabling peer-to-peer value transfer without intermediaries. At their core, these transactions are structured data packets that unlock existing bitcoin outputs and create new ones. Understanding how they function—both conceptually and technically—reveals the elegance of Bitcoin’s design.
The Core Mechanism: Unlocking and Locking Bitcoin
A Bitcoin transaction operates as a digital handoff mechanism. It selects unspent transaction outputs (UTXOs)—think of them as individual “batches” of bitcoin—from prior transactions and unlocks them using cryptographic proof. Then, it creates new UTXOs with fresh locking conditions for the recipient(s).
This process forms a chain of ownership, where each output becomes an input in a future transaction. To unlock an output, the sender must provide a digital signature generated with their private key, matching the public key embedded in the output's lock. This ensures only the rightful owner can spend their bitcoin.
“We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner.”
— Satoshi Nakamoto, Bitcoin Whitepaper
While this cryptographic foundation is essential, our focus here is on the structure and mechanics of transactions—the blueprint that powers every Bitcoin transfer.
👉 Discover how blockchain technology is transforming finance—explore real-world applications today.
Anatomy of a Raw Bitcoin Transaction
All Bitcoin transactions follow a standardized format composed of fields in byte-level data. Whether legacy or SegWit-enabled, each transaction shares this foundational layout:
Version
- Size: 4 bytes
- Purpose: Indicates protocol version
Common Values:
01000000(Version 1): Basic transactions since 200902000000(Version 2): Supports relative locktime (BIP 68), widely used since 2015
Marker & Flag (SegWit Indicator)
Present only in Segregated Witness (SegWit) transactions:
- Marker: Always
00 - Flag: Typically
01, signaling witness data follows
These two bytes tell nodes that unlocking data (witness) is stored separately, reducing malleability and improving scalability.
Input Count
- Variable size using Compact Size encoding
- Specifies how many inputs are included
Inputs
Each input references a prior output via:
- TXID: 32-byte hash of the source transaction (in reverse byte order)
- VOUT: 4-byte index identifying which output from that transaction is being spent
- ScriptSig Size & ScriptSig: Contains unlocking script (signatures, public keys); used only for legacy scripts like P2PKH
- Sequence: 4-byte field for features like Replace-By-Fee (RBF) and relative locktime
Output Count
- Variable size
- Defines number of new UTXOs created
Outputs
Each output includes:
- Amount: 8-byte value in satoshis (1 BTC = 100,000,000 satoshis)
- ScriptPubKey Size & ScriptPubKey: The locking script defining who can spend it
Witness (SegWit Only)
Houses unlocking data for SegWit inputs:
- Contains stack items: signatures and public keys
- Not part of traditional script execution but validated during consensus
Locktime
- 4-byte field setting earliest time/block when transaction can be mined
- Enables time-locked transactions (like post-dated checks)
Transaction Types: Legacy vs. SegWit
Bitcoin supports multiple script types, evolving over time for efficiency and security.
Legacy Scripts
Used in early Bitcoin; stored unlocking data in ScriptSig:
- P2PKH (
76a914...88ac): Pay to Public Key Hash – most common legacy type - P2SH (
a914...87): Pay to Script Hash – allows complex conditions
SegWit Scripts
Introduced in 2017 via BIP 141; move signature data off-chain:
- P2WPKH (
0014...): Native SegWit version of P2PKH - P2WSH (
0020...): For complex scripts like multisig
SegWit reduces transaction size and fees by discounting witness data in block weight calculations.
👉 See how modern wallets streamline Bitcoin transactions with advanced security features.
Real-World Transaction Examples
Example 1: Basic Legacy Transaction
A single-input, two-output P2PKH transfer:
- Input spends a previous UTXO via
ScriptSigcontaining signature + public key - One output goes to recipient; second returns change to sender
- Signature dominates size—increasing fees due to higher byte count
Example 2: Native SegWit Transaction
Same logic, but uses P2WPKH:
ScriptSigempty (00)- Unlocking data moved to witness section
- Lower effective size → cheaper fees under SegWit rules
Example 3: Mixed Input Transaction
Combines legacy and SegWit inputs:
- First input uses
ScriptSig - Second uses witness field
- Both require witness array entries—even if empty (
stackitems: 00)
This flexibility allows seamless interoperability across script types.
Key Concepts in Bitcoin Transactions
TXID: The Transaction Fingerprint
Generated by double-SHA256 hashing:
TXID = HASH256(version + inputs + outputs + locktime)Used universally to identify transactions on explorers and link UTXOs.
wTXID: Witness Transaction ID
Includes witness data:
wTXID = HASH256(version + marker + flag + inputs + outputs + locktime + witness)Critical for SegWit blocks; used in Merkle trees within coinbase transactions.
Transaction Size Metrics
Three ways to measure:
- Bytes: Raw data length
- Weight: Base size × 4, minus witness discount (×1 instead of ×4)
- Virtual Bytes (vBytes): Weight ÷ 4 — standard metric for fee rates
For example, a 200-byte SegWit transaction might weigh 600 units → 150 vBytes, lowering fee costs.
Transaction Fees: The Miner’s Incentive
Calculated as:
Fee = Sum(All Inputs) – Sum(All Outputs)Unclaimed balance goes to miner. Accurate output calculation prevents accidental overpayment.
Frequently Asked Questions (FAQ)
Q: What happens if I send more bitcoin than intended?
A: Excess becomes a transaction fee. Always double-check output amounts before broadcasting.
Q: Why do some transactions have lower fees?
A: SegWit transactions benefit from weight-based pricing, making them up to 40% cheaper than legacy equivalents.
Q: Can a transaction be canceled once sent?
A: No—Bitcoin transactions are irreversible. However, unconfirmed transactions may be replaced via RBF if enabled.
Q: How long does a transaction take to confirm?
A: Typically 10 minutes on average, depending on network congestion and fee level.
Q: What is change in a Bitcoin transaction?
A: When input value exceeds outputs, the remainder is sent back to a change address controlled by the sender.
Q: Are all Bitcoin addresses compatible?
A: Yes—funds can be sent from any address type to any other, though using native formats optimizes fees.
👉 Start exploring Bitcoin’s ecosystem with tools designed for secure, low-cost transactions.
Summary
Bitcoin transactions are not just financial instruments—they’re cryptographic puzzles solved through digital signatures and verified by a global network. From selecting UTXOs to crafting outputs and managing fees, every component serves a purpose in maintaining trustless security.
Whether you're decoding raw hex data or sending your first satoshi, understanding transaction structure empowers deeper engagement with the network. With innovations like SegWit enhancing efficiency and paving the way for Layer 2 solutions like the Lightning Network, the evolution continues.
As Satoshi envisioned, Bitcoin redefines money as a chain of verifiable ownership—each transaction a link forged in code and consensus.
Core Keywords: Bitcoin transactions, UTXO model, SegWit, transaction fee, TXID, ScriptPubKey, blockchain, digital signatures