Transactions Deep Dive

Bitcoin has no concept of "account balance." Instead, it uses the UTXO (Unspent Transaction Output) model.

Your "balance" is the sum of all unspent outputs associated with your addresses. It's like having three ¥100 coins and one ¥500 coin — not an abstract "¥800 balance" but a specific collection of "coins."

When you send, you consume one or more UTXOs as "inputs" and create new "outputs" (payment to the recipient plus change back to yourself). Consumed UTXOs are spent and can never be used again.

Advantages: easy double-spend detection, parallelizable processing, and better privacy management (coin control). It is a fundamentally different model from a bank account.

Version number (4 bytes): Currently 2 is most common; version 2 or higher is required for OP_CHECKSEQUENCEVERIFY. Since Bitcoin Core 28.0 (October 2024), version 3 (TRUC, BIP-431), which restricts the shape of unconfirmed transaction chains, is also relayed as standard.

Inputs (TxIn): References to previous transaction outputs. Composed of "previous transaction hash" (32 bytes), "output index" (4 bytes), "scriptSig" (unlocking script with signature and public key), and "sequence number" (4 bytes).

Outputs (TxOut): Specify destination and amount. Composed of "value" (8 bytes, in satoshis) and "scriptPubKey" (locking script).

Locktime (4 bytes): Optionally sets a block height or timestamp before which the transaction cannot be valid.

Common output types: P2PKH (legacy, addresses starting with 1), P2SH (starting with 3 — including multisig and nested SegWit), P2WPKH/P2WSH (native SegWit, starting with bc1q), and P2TR (Taproot, starting with bc1p). From SegWit onward, what the signature commits to is redefined by BIP-143.

In SegWit transactions, signature data (witness) is separated from the transaction body. The witness is excluded from the transaction ID (txid) computation, and the hash covering the witness is tracked separately as the wtxid. A third party rewriting how a signature is encoded therefore no longer changes the txid. That is the substance of the malleability fix, and it also effectively increased block capacity.

For legacy outputs such as P2PKH, validation occurs in two stages: ① Execute the input's scriptSig → ② Execute the referenced output's scriptPubKey using scriptSig results. If the stack's top value is true (non-zero), the transaction is valid. With native SegWit (bc1q/bc1p) the scriptSig is empty, and signatures are verified against the data carried in the witness instead.

Standard P2PKH validation flow: Signature and public key from scriptSig → public key is hashed and compared to the hash in scriptPubKey → signature validity is verified → all checks pass, transaction approved.

Miners select unconfirmed transactions from the mempool, prioritizing those with higher fees for block inclusion.

Critical: the entire difference between total input value and total output value goes to the miner as the transaction fee. It is not destroyed, but the sender cannot get it back: forget the change output and you pay the whole remainder of your inputs as fee.

One thing to establish first: RBF, CPFP, and fee-based prioritization are all relay and mempool policies each node chooses for itself, not consensus rules that determine whether a block is valid. That is why their default behavior can change without a soft fork.

Bitcoin fees are based on transaction data size (bytes), not the amount sent. Sending 1 BTC costs the same as 0.001 BTC if the transaction size is identical.

Fee rates are expressed as "sat/vB" (satoshis per virtual byte). SegWit transactions receive a discount on witness data, making them cheaper for the same functionality.

RBF (Replace-By-Fee): replacing an under-priced, unconfirmed transaction with a higher-fee one spending the same inputs. Historically this used the opt-in scheme of BIP-125, under which a transaction was replaceable only if any of its inputs carried a sequence number below 0xFFFFFFFE (0xFFFFFFFE itself is the value many wallets use as standard to enable locktime while declining replacement).

Since then, Bitcoin Core 28.0 (October 2024) made full-RBF the default (-mempoolfullrbf flipped from 0 to 1), and 29.0 (April 2025) removed the option altogether. As of August 2026, nodes in their default configuration treat essentially every unconfirmed transaction as replaceable regardless of signaling. "It did not signal RBF, so zero confirmations are safe" no longer holds.

CPFP (Child-Pays-For-Parent): Create a high-fee child transaction spending the output of a low-fee unconfirmed parent. Miners are incentivized to mine the parent-child pair together. Since Bitcoin Core 28.0, 1-parent-1-child (1P1C) package relay also allows a parent that falls below the minimum relay fee on its own to propagate when evaluated together with its child.

0 confirmations: Transaction sent but not yet in a block. Vulnerable to double-spend attacks (race attack, Finney attack). As noted above, full-RBF has been unconditional in Bitcoin Core since 2025, so treat any unconfirmed transaction as replaceable at any moment.

1 confirmation: Included in the first block. Sufficient for small transactions, though Vector76 attack risk remains.

6 confirmations: Conventionally considered "final." In the whitepaper's §11 calculation, an attacker with 10% of network hash rate has roughly a 0.024% chance of overturning six confirmations (in the same table, the first depth below 0.1% is five confirmations). Note that this is a model figure assuming the attacker's hash power is fixed and cannot be sourced externally, so it does not transfer directly to a real attacker who can rent hash power.

Some operators wait for more confirmations on large amounts, but there is no standard mandating "100 confirmations"; it is each business's internal policy. The 100-block wait that does exist as a consensus rule is coinbase maturity, the period before mining rewards become spendable, which is a separate matter from confirmations on an ordinary payment. Choosing a confirmation count is risk management, based on the amount and on how much you trust the counterparty.

Average confirmation time is ~10 minutes (1 block), but actual block intervals vary from seconds to over an hour.

Segregated Witness (SegWit, BIP-141), activated on August 24, 2017 (block 481,824), is one of Bitcoin's most important protocol upgrades.

By separating signature data (witness) from the transaction body, it replaced the old 1MB size cap with a limit on a different axis: block weight of at most 4,000,000 weight units (WU). Non-witness bytes count as 4 WU each and witness bytes as 1 WU each, so the more witness data a block carries, the more transactions fit. Real blocks generally run about 1.5–2.5MB and rarely approach 4MB. The vsize used for fee calculation is simply weight divided by four.

It solved the transaction malleability problem, which is what allowed payment channel technologies such as the Lightning Network to be built securely.

Native SegWit addresses use the Bech32 format starting with "bc1q." Nested SegWit (SegWit wrapped inside a P2SH address starting with 3) receives the same fee discount. Taproot's "bc1p" addresses are witness version 1 and use Bech32m (BIP-350), the revised encoding.

Adoption figures swing widely with the definition used. Public trackers measuring "the share of transactions spending at least one SegWit input" (such as mainnet.observer) put it at roughly 85–90% in the first half of 2026, while Glassnode's "SegWit Adoption" metric read 96.1% as of March 23, 2026, a gap of about ten points. Rather than memorizing a single number, check which definition it rests on.