Introduction
Bitcoin transactions are the fundamental units of value transfer on the Bitcoin network. They represent the movement of bitcoin from one address to another, permanently recorded on the blockchain. Understanding how Bitcoin transactions work is essential for anyone using the cryptocurrency, from basic transfers to complex smart contracts. This cheat sheet covers transaction structure, lifecycle, fees, confirmation process, and best practices for creating and managing Bitcoin transactions.
Core Transaction Concepts
Transaction Anatomy
- Transaction (TX): A record transferring bitcoin value between addresses
- Inputs: References to previous transaction outputs being spent
- Outputs: New UTXOs created, specifying recipients and amounts
- Transaction Fee: Difference between total inputs and total outputs
- Transaction ID (TXID): Unique identifier hash of the transaction
- Block: Group of transactions confirmed together (roughly every 10 minutes)
- Confirmation: Each new block added after a transaction increases confirmations
The UTXO Model
| Component | Description | Example |
|---|---|---|
| UTXO | Unspent Transaction Output; represents spendable bitcoin | 0.5 BTC received to address X |
| Input | Reference to a UTXO being spent | Spending the 0.5 BTC from address X |
| Output | New UTXO created from transaction | 0.3 BTC to address Y, 0.19 BTC change back to X |
| Change | Output returning unspent portion to sender | The 0.19 BTC returned to sender (0.01 BTC fee) |
Transaction Types
| Type | Description | Use Case |
|---|---|---|
| P2PKH | Pay to Public Key Hash (legacy) | Standard transaction to single address |
| P2SH | Pay to Script Hash | Multi-signature and complex script transactions |
| P2WPKH | Pay to Witness Public Key Hash | SegWit version of P2PKH (lower fees) |
| P2WSH | Pay to Witness Script Hash | SegWit version of P2SH (lower fees) |
| P2TR | Pay to Taproot | Newest type with enhanced privacy and efficiency |
| OP_RETURN | Allows embedding small amounts of data | Timestamping, proof of existence |
Transaction Lifecycle
Creation to Confirmation Step-by-Step
- Transaction Creation: Wallet software drafts transaction with inputs, outputs, and fee
- Transaction Signing: Private key creates digital signature authorizing the spend
- Broadcasting: Signed transaction transmitted to Bitcoin network nodes
- Mempool Entry: Transaction awaits in nodes’ memory pools for inclusion in a block
- Mining Selection: Miners select transactions based on fee rate (sats/vbyte)
- Block Inclusion: Transaction included in a mined block
- Block Propagation: New block containing transaction propagated across network
- Confirmation Count: Additional blocks mined on top increase confirmation count
- Finality: Transaction considered irreversible after 6+ confirmations (~1 hour)
Transaction States
| State | Description | When to Consider “Final” |
|---|---|---|
| Unconfirmed | Broadcast to network but not in a block | Not final; might never confirm |
| 1 Confirmation | Included in one block | Acceptable for small amounts |
| 2-5 Confirmations | Multiple blocks mined on top | Suitable for larger amounts |
| 6+ Confirmations | Six or more blocks deep | Industry standard for finality |
| Replaced | Superseded by another transaction (via RBF) | No longer valid |
| Rejected | Not accepted by network (invalid signature, etc.) | Never valid |
Transaction Fees
Fee Determination Factors
| Factor | Impact | Notes |
|---|---|---|
| Transaction Size (vbytes) | Larger size = higher total fee | Size depends on input/output count and type |
| Network Congestion | Higher demand = higher fee rates | Variable throughout day/week |
| Urgency | Faster confirmation = higher fee rate needed | Prioritize based on time sensitivity |
| Transaction Type | Legacy > SegWit > Taproot (highest to lowest fee) | Newer formats are more efficient |
| Input/Output Count | More inputs/outputs = larger transaction | Consolidate inputs during low-fee periods |
Fee Rate Units
| Unit | Description | Typical Ranges (2023) |
|---|---|---|
| Satoshis/vbyte | Fee per virtual byte of transaction | 1-100+ sat/vB |
| Satoshis/weight unit | Fee per weight unit (1/4 of vbyte) | 0.25-25+ sat/WU |
| Total Fee | Complete fee amount in satoshis | 500-50,000+ sats |
| BTC Amount | Fee expressed in bitcoin | 0.000005-0.0005+ BTC |
Fee Estimation Strategies
| Strategy | Description | Best For |
|---|---|---|
| Next Block | Highest fee rate for quick confirmation | Urgent transactions |
| 3-6 Blocks | Medium fee rate for ~30-60 min confirmation | Standard transfers |
| Economic | Low fee rate for eventual confirmation (hours/days) | Non-urgent transactions |
| Replace-By-Fee (RBF) | Start low, increase if needed | Optimization during fee volatility |
| Child-Pays-For-Parent (CPFP) | New transaction pays for stuck transaction | Rescuing stuck transactions |
Transaction Technical Details
Transaction Script Types
| Script Type | Description | Characteristics |
|---|---|---|
| P2PKH Script | Standard pay to public key hash | Higher fee, universal compatibility |
| P2SH Script | Enables complex conditions encoded in scripts | Versatile but higher fees than SegWit |
| P2WPKH Script | SegWit version of P2PKH | Lower fees, limited compatibility |
| P2WSH Script | SegWit version of P2SH | Lower fees, good for complex scripts |
| P2TR Script | Taproot output type | Lowest fees, best privacy, newest type |
| Multisig Script | Requires multiple signatures | Used for shared wallets, escrow |
Transaction Size Calculations
| Element | Approximate Size | Notes |
|---|---|---|
| Transaction Overhead | ~10-12 vbytes | Fixed overhead per transaction |
| Legacy Input (P2PKH) | ~148 vbytes each | Highest input size |
| SegWit Input (P2WPKH) | ~68 vbytes each | ~54% smaller than legacy |
| Taproot Input (P2TR) | ~57 vbytes each | Smallest standard input type |
| Standard Output | ~31-43 vbytes each | Varies by output type |
| Typical 1-in-2-out Transaction | ~225 vbytes (legacy) | Simple payment with change |
| Typical 1-in-2-out Transaction | ~140 vbytes (SegWit) | Simple SegWit payment with change |
| Typical 1-in-2-out Transaction | ~120 vbytes (Taproot) | Simple Taproot payment with change |
Digital Signatures and Verification
| Component | Purpose | Technical Detail |
|---|---|---|
| ECDSA | Original signature algorithm | Used in legacy and SegWit transactions |
| Schnorr | Newer signature algorithm | Used in Taproot transactions, more efficient |
| Signature Hash (SIGHASH) | Determines what parts of TX are signed | Controls signature flexibility |
| SIGHASH_ALL | Signs entire transaction | Most common, prevents any changes |
| SIGHASH_NONE | Only signs inputs | Allows output changes |
| SIGHASH_SINGLE | Signs inputs and corresponding output | Allows other output changes |
| SIGHASH_ANYONECANPAY | Modifier allowing input additions | Can be combined with other types |
Advanced Transaction Features
Timelocks
| Type | Description | Use Cases |
|---|---|---|
| nLockTime | Earliest time/block transaction can be included | Time-delayed payments, scheduled transfers |
| CheckLockTimeVerify (CLTV) | Script-level absolute timelock | Smart contracts, escrow with deadlines |
| nSequence | Enables relative timelocks | Relative time constraints |
| CheckSequenceVerify (CSV) | Script-level relative timelock | Payment channels, Lightning Network |
Transaction Privacy Features
| Feature | Description | Privacy Benefit |
|---|---|---|
| CoinJoin | Collaborative transaction combining multiple inputs/outputs | Breaks transaction graph analysis |
| PayJoin | Special CoinJoin between sender and recipient | Disguises payment amount |
| Taproot | Latest Bitcoin upgrade with privacy enhancements | Makes complex scripts look like simple payments |
| Address Reuse Avoidance | Using new address for each transaction | Prevents linking of transactions |
| Coin Control | Manual UTXO selection | Prevents revealing all holdings in single transaction |
Transaction Replacement
| Method | Description | When to Use |
|---|---|---|
| Replace-By-Fee (RBF) | Replace transaction with higher-fee version | When initial fee too low for desired confirmation time |
| Opt-in RBF | Transaction explicitly flagged as replaceable | Standard approach, must be enabled at creation |
| Child-Pays-For-Parent (CPFP) | New transaction with high fee to incentivize mining parent | When transaction stuck but RBF not enabled |
| Package Relay | Submitting parent and child transactions together | When parent won’t propagate due to low fee |
| Transaction Acceleration | Services that prioritize specific transactions | Emergency situation requiring confirmation |
Common Challenges and Solutions
Challenge: Transaction Stuck in Mempool
- Solution: Use Replace-By-Fee (RBF) if enabled to increase fee
- Solution: Create a child transaction spending the unconfirmed output with high fee (CPFP)
- Solution: Wait for mempool to clear (can take hours to days)
- Solution: Use transaction accelerator service (some miners offer this)
- Prevention: Enable RBF when creating transactions, check mempool conditions before sending
Challenge: Sent to Wrong Address
- Solution: If funds sent to your own mistyped address, they are likely lost
- Solution: If sent to another person’s address, contact them and request return
- Solution: If sent to exchange/service address, contact their support
- Prevention: Always double-check addresses, use address book features, send test amount first
Challenge: High Transaction Fees
- Solution: Wait for lower network congestion if not urgent
- Solution: Use batching to combine multiple payments in one transaction
- Solution: Upgrade to SegWit/Taproot wallet for lower fees
- Solution: Use Lightning Network for small/frequent payments
- Prevention: Check fee estimators before sending, schedule non-urgent transactions during weekends
Challenge: Transaction Shows Different Amount Than Expected
- Solution: Verify if the difference is the transaction fee
- Solution: Check if change went to a different address in your wallet
- Solution: Confirm you’re looking at the correct transaction
- Prevention: Review transaction details before signing, understand how change works
Best Practices for Bitcoin Transactions
Security Best Practices
- Verify the first and last characters of destination addresses
- Use hardware wallets for signing transactions with significant value
- Enable address verification on hardware wallet display
- Consider multi-signature for high-value transactions
- Wait for appropriate confirmation count based on transaction value
- Backup wallet before making transactions
Efficiency Best Practices
- Use native SegWit (bc1) or Taproot (bc1p) addresses for lower fees
- Batch multiple payments into single transactions when possible
- Consolidate UTXOs during low fee periods
- Set appropriate fee based on urgency (not always highest)
- Enable Replace-By-Fee for all non-urgent transactions
- Use Lightning Network for small or frequent payments
Privacy Best Practices
- Never reuse addresses (generate new address for each transaction)
- Avoid merging UTXOs from different sources in one transaction
- Consider using CoinJoin for enhanced privacy
- Separate coins by source/purpose using multiple wallets
- Be cautious of timing patterns in your transactions
- Consider transaction size when timing sensitive transactions
Technical Comparison: Transaction Types
| Feature | Legacy (P2PKH) | SegWit (P2WPKH) | Taproot (P2TR) |
|---|---|---|---|
| Address Format | Starts with 1 | Starts with bc1 | Starts with bc1p |
| Input Size | ~148 vbytes | ~68 vbytes | ~57 vbytes |
| Fee Efficiency | Lowest | Medium | Highest |
| Compatibility | Universal | High | Growing |
| Privacy | Basic | Basic | Enhanced |
| Smart Contract Support | Limited | Better | Best |
| Signature Algorithm | ECDSA | ECDSA | Schnorr |
| Adoption (2023) | ~10% | ~70% | ~20% |
Resources for Transaction Management
Block Explorers
- Mempool.space – Visual mempool and fee estimation
- Blockstream Explorer – Transaction lookup and verification
- Blockchain.com Explorer – Popular block explorer
- BTC RPC Explorer – Self-hosted explorer
Fee Estimation Tools
- Mempool.space Fee Estimator – Real-time fee recommendations
- Bitcoin Fees – Detailed fee market analysis
- Whatthefee.io – Probability-based fee estimation
Transaction Acceleration Services
- ViaBTC Transaction Accelerator – Free/paid acceleration
- BTC.com Accelerator – Paid acceleration service
- Mempool.space Accelerator – Paid acceleration (Miningpool.ch)
Advanced Transaction Tools
- Sparrow Wallet – Advanced transaction creation and UTXO management
- BitcoinJS – JavaScript library for transaction creation
- Bitcoin Core – Reference implementation with complete transaction control
- PSBT (Partially Signed Bitcoin Transactions) – Standard for transaction coordination
This comprehensive cheat sheet covers the essentials of Bitcoin transactions. Remember that the Bitcoin protocol continues to evolve, and best practices may change over time. Always verify information with current sources before making significant transactions.