Bitcoin transactions form the backbone of the network, enabling users to securely transfer value—measured in satoshis—across a decentralized system. These transactions are more than simple digital payments; they’re programmable, verifiable, and built on cryptographic principles that ensure trust without intermediaries. This guide explores the inner workings of Bitcoin transactions, from basic structure to advanced scripting and security considerations.
Understanding the Structure of a Bitcoin Transaction
Every Bitcoin transaction consists of inputs and outputs, forming a chain of ownership that’s recorded on the blockchain. At its core:
- Inputs reference previous unspent transaction outputs (UTXOs), proving the sender has the right to spend those funds.
- Outputs define where the satoshis go and under what conditions they can be spent.
When your wallet shows a balance of 10,000 satoshis, it’s actually summing up all UTXOs linked to your addresses. Each transaction also includes a version number, a 4-byte field indicating which validation rules apply—enabling future upgrades without breaking older transactions.
👉 Discover how blockchain transactions are validated in real time.
Spending a Transaction Output: The Role of Scripts
To spend a UTXO, a user must satisfy the conditions set in its pubkey script (also known as scriptPubKey). This is done by providing data in a signature script (scriptSig) that fulfills the logic defined in the pubkey script.
The most common transaction type is Pay-To-Public-Key-Hash (P2PKH), which allows sending funds to a Bitcoin address—a hashed version of a public key. Here's how it works:
- The recipient (Bob) generates a private/public key pair using the secp256k1 elliptic curve.
- The public key is hashed to create a pubkey hash, then encoded into a Bitcoin address using Base58Check encoding with a checksum for error detection.
- The sender (Alice) creates a transaction with an output containing a P2PKH script that locks funds to Bob’s address.
Later, when Bob wants to spend the funds, he creates an input that references Alice’s transaction by its transaction ID (txid) and output index, then provides:
- His full public key (to prove it matches the hash)
- A valid ECDSA signature generated with his private key
This combination allows the network to verify ownership and prevent tampering.
How P2PKH Script Validation Works
Bitcoin uses a stack-based scripting language to validate transactions. For P2PKH, the pubkey script looks like this:
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIGWhen Bob spends the output, his signature script is prepended:
<signature> <publicKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIGHere’s how the script executes step-by-step:
- Push Bob’s signature and public key onto the stack.
OP_DUPduplicates the public key.OP_HASH160hashes one copy of the public key.- The original pubkey hash from Alice’s output is pushed.
OP_EQUALVERIFYchecks if the two hashes match—if not, validation fails.OP_CHECKSIGverifies the signature against the public key.
If the final result is true, the transaction is valid.
This process ensures that only someone with the correct private key can unlock and spend the funds.
Expanding Flexibility with P2SH Transactions
While P2PKH is ideal for simple payments, more complex conditions require advanced scripting. Enter Pay-To-Script-Hash (P2SH), introduced in 2012 to simplify sending to custom scripts.
With P2SH:
- The recipient creates a redeem script defining spending conditions (e.g., multi-signature logic).
- They hash this script and share only the hash—formatted as a standard Bitcoin address.
- The sender locks funds to this hash.
- When spending, the recipient provides both the full redeem script and any required data (signatures, etc.).
The network first checks that the provided redeem script hashes to the expected value, then executes it just like a regular pubkey script.
This design keeps addresses short and familiar while enabling powerful use cases like:
- Multi-signature wallets
- Time-locked contracts
- Data storage via
OP_RETURN
👉 Learn how smart contract-like logic works on Bitcoin through P2SH.
Standard vs. Non-Standard Transactions
To maintain network stability and security, Bitcoin Core implements a IsStandard() test that filters incoming transactions. Only those matching predefined templates are widely relayed and mined.
Common Standard Transaction Types
- P2PKH: Most common; sends to a single address.
- P2SH: Enables complex scripts behind simple addresses.
- Multisig: Requires multiple signatures (e.g., 2-of-3) to spend.
- Pubkey: Direct public key locking—rarely used today due to lower security.
- Null Data: Uses
OP_RETURNto embed up to 83 bytes of arbitrary data.
Non-standard transactions (e.g., custom opcodes) may still be included in blocks but won’t propagate through default nodes unless wrapped in P2SH.
As of Bitcoin Core 0.9.3, standard transactions must also meet criteria such as:
- Size under 100,000 bytes
- Signature scripts under 1,650 bytes
- Minimum output value of 546 satoshis (to prevent spam)
Signature Hash Types: Controlling What You Sign
The OP_CHECKSIG operation supports different signature hash types, letting signers control which parts of a transaction are protected.
| Type | What It Signs | Use Case |
|---|---|---|
SIGHASH_ALL | All inputs and outputs | Default; fully locks transaction |
SIGHASH_NONE | Inputs only | Allows others to change outputs |
SIGHASH_SINGLE | One input and matching output | Partial agreement in multi-party deals |
These can be combined with SIGHASH_ANYONECANPAY:
- Lets anyone add new inputs
- Useful for crowdfunding or collaborative payments
This flexibility enables advanced workflows like atomic swaps and payment channels.
Locktime and Sequence Numbers: Time-Locking Transactions
Transactions can be time-locked using the locktime field:
- If < 500 million: interpreted as block height
- If ≥ 500 million: interpreted as Unix timestamp
Until the locktime passes, miners won’t include the transaction in a block.
The sequence number in each input was originally designed for transaction replacement but now primarily serves to disable locktime when set to 0xFFFFFFFF. To enforce locktime, at least one input must have a lower sequence number.
This mechanism supports escrow services, refund clauses, and other time-dependent smart contracts.
Fees, Change, and Efficient Transaction Design
Transaction fees are based on total byte size and paid per byte, fluctuating with network demand. Miners prioritize higher-fee transactions when filling blocks.
Since UTXOs are indivisible, most transactions generate change outputs:
- Example: Spending 8,000 satoshis from a 10,000-satoshi UTXO → one output of 8,000 satoshis (to recipient), one of 1,990 satoshis (back to sender), 10 satoshis as fee.
Change should be sent to a new address to avoid key reuse and enhance privacy.
A minimum relay fee (currently 1,000 satoshis) applies to all transactions broadcast on the network.
Why You Should Avoid Key Reuse
Reusing Bitcoin addresses compromises both privacy and security:
- Anyone can trace all transactions linked to a single address.
- Repeated use of the same public key increases exposure to theoretical attacks on ECDSA.
- Signature analysis may reveal private keys if entropy during signing is weak or reused.
Best practices:
- Generate a new address for every incoming payment.
- Use unique change addresses.
- Combine with privacy tools like CoinJoin when possible.
Even static payment requests should use fresh addresses behind the scenes via payment protocols or wallet integrations.
Addressing Transaction Malleability
Bitcoin’s original design allowed transaction malleability: third parties could alter transaction IDs without invalidating them. This posed risks for:
- Payment tracking (txid changes)
- Dependent unconfirmed transactions
The solution? Segregated Witness (SegWit), activated in 2017 via BIP 141:
- Moves signatures outside the main transaction data
- Fixes malleability by decoupling signature data from txid calculation
- Increases block capacity and reduces fees
Today, using SegWit addresses (e.g., bc1q...) is recommended for better performance and security.
Frequently Asked Questions
What is a UTXO?
A UTXO (Unspent Transaction Output) represents a chunk of Bitcoin that hasn’t been spent yet. Your wallet balance is the sum of all UTXOs you control.
Can I send Bitcoin without paying fees?
No. While technically possible in rare cases, nearly all nodes require at least the minimum relay fee (1,000 satoshis). Low or zero-fee transactions often remain unconfirmed indefinitely.
How do multi-signature wallets work?
Multi-sig requires multiple private keys to authorize a spend (e.g., 2-of-3). It enhances security by distributing control and is commonly used in corporate wallets or custodial setups.
Is it safe to store data on the blockchain?
Yes, via OP_RETURN, but sparingly. Up to 83 bytes can be stored per output at minimal cost. However, storing large amounts of data inflates the blockchain and isn’t efficient.
What happens if my transaction gets malleated?
With legacy transactions, txid changes could disrupt dependent transactions. SegWit solves this by making txids immutable. Always wait for confirmation before building on top of a transaction.
Why are P2SH addresses useful?
P2SH simplifies complex scripts by letting users send to regular-looking addresses while enabling advanced features like multi-sig or time locks behind the scenes.
👉 Start exploring Bitcoin’s transaction ecosystem with secure tools today.