The 10-second answer
Bitcoin uses a UTXO model. Every transaction consumes one or more unspent outputs (inputs) and creates new outputs locked by scripts. Wallets pick UTXOs, build outputs (recipient + change), estimate a fee in sats/vB, sign, broadcast to the network’s mempool, and miners include it in a block when the fee is competitive.
The moving pieces: inputs, outputs, and scripts
A transaction references previous outputs as inputs and creates new outputs. Each output has a locking script (scriptPubKey). To spend an output later, you provide an unlocking script (scriptSig or witness) that satisfies the lock. This script system—Bitcoin Script—is what actually enforces ownership.
What “addresses” really are
Addresses are encodings of locking conditions. Today most wallets use Bech32/Bech32m formats for native SegWit and Taproot outputs, improving error detection and efficiency. P2TR (Taproot) uses Bech32m; earlier SegWit v0 types use Bech32.
The UTXO model in plain English
Think of UTXOs like bills and coins. You can’t “split” one in place; you spend whole UTXOs and receive change as a new UTXO. The global set of spendable outputs is the UTXO set. Wallets select which UTXOs to spend, often preferring fewer inputs to reduce size and fees.
SegWit and why TXIDs stopped being fragile
Legacy transactions could have their ID (TXID) altered without changing their economic effect—a headache for protocols and wallets. SegWit moved signatures into a separate witness area, changing the way TXIDs are computed and effectively fixing transaction malleability while also introducing block “weight” up to 4,000,000 WU.
TXID vs WTXID
A TXID hashes the non-witness parts of a transaction; a WTXID includes witness data. If a transaction has no SegWit inputs, TXID and WTXID are identical.
Taproot: modern spending paths and simpler signatures
Taproot (BIPs 340/341/342) added Schnorr signatures and two ways to spend a P2TR output: key-path (just a Schnorr signature) or script-path (reveal one committed script branch). Key-path is efficient and private; script-path lets you keep complex policies hidden until used.
From “send” to “confirmed”: what your wallet actually does
1) Build
The wallet chooses inputs (UTXOs), creates outputs for the recipient and change, and sets nLockTime/sequence if needed for timelocks or replaceability.
2) Price the blockspace
Fees are market-based and measured as sats per virtual byte (sats/vB). Total fee = fee rate × vbytes of the transaction. Higher feerate usually means faster inclusion.
3) Sign
Each input is signed according to its script type. With SegWit and Taproot, signatures are in the witness and validated against the spending rules.
4) Broadcast and wait
Nodes validate and place the transaction in their mempools. Miners typically pick transactions offering the highest fee per weight unit until the block’s weight limit is filled.
Why your small payment isn’t “free”: dust and standardness
Nodes won’t relay outputs so tiny they’d cost more to spend than they’re worth—called “dust.” Bitcoin Core enforces dust and other “standardness” policies to prevent DoS and UTXO bloat. As a result, extremely tiny outputs can be rejected even if they are technically valid by consensus.
Stuck transactions: two safe ways to bump the fee
Replace-By-Fee (RBF)
If your original transaction signaled replaceability, you can resend the same inputs with a higher feerate. RBF is defined by policy (BIP-125) and widely supported.
Child-Pays-for-Parent (CPFP)
Spend one of the unconfirmed outputs in a new child transaction with a high feerate. Miners evaluate the package so both parent and child confirm together; this is supported by ancestor-feerate mining policies.
Multi-party and hardware workflows: PSBT
Partially Signed Bitcoin Transactions (PSBT, BIP-174) let different tools and people exchange an unsigned transaction, add signatures, and then finalize and broadcast—ideal for multisig and hardware wallets.
Fee tips for 2025–2026
- Check current mempool conditions and set feerate in sats/vB accordingly; the amount of BTC you send doesn’t change the fee, the data size does.
- Prefer native SegWit or Taproot addresses (bc1…) for smaller transaction weight and better error detection.
- Keep change outputs above dust to avoid creating uneconomic UTXOs.
FAQs
What exactly is being “verified” in a Bitcoin transaction?
Nodes verify that each input correctly unlocks a previous output using the relevant script rules and that total inputs cover outputs plus fee.
Why do addresses start with 1, 3, or bc1?
Those reflect different locking script types and encodings: legacy (Base58), P2SH, and SegWit/Taproot (Bech32/Bech32m).
Does SegWit make transactions cheaper?
SegWit changes how size is measured (weight/virtual bytes) and discounts witness data, so many spends do cost less per effect. It also fixes malleability.
What’s the difference between mempool policy and consensus?
Consensus rules define what blocks can contain; policy rules define what nodes will relay or miners will include by default. Dust limits are policy.
