Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
A Bitcoin transaction is the atomic unit of state change. Knowing exactly what fields it carries — version, inputs (with witness data post-SegWit), outputs (with scripts), locktime — is the difference between using wallets and writing them. Most of the protocol's complexity lives here.
Transaction structure in detail.
Use these three in order. Each builds on the one before.
In one paragraph, explain a Bitcoin transaction.
Walk me through how SegWit changed tx hashing and size.
Design a transaction batching strategy that minimizes fees for a payment processor sending to 100 recipients.
// Bitcoin transaction (post-SegWit) wire format
// All multibyte integers are little-endian.
pub struct Transaction {
pub version: i32, // 4 bytes; currently 1 or 2
pub flag: Option<u16>, // 0x0001 marker if witness data present
pub inputs: Vec<TxIn>,
pub outputs: Vec<TxOut>,
pub witnesses: Vec<Witness>, // one per input if flag set
pub locktime: u32, // 4 bytes; height or unix timestamp
}
pub struct TxIn {
pub previous_outpoint: OutPoint, // 36 bytes: prev_txid (32) + vout_index (4)
pub script_sig: Vec<u8>, // legacy scriptSig (empty for SegWit)
pub sequence: u32, // RBF + locktime semantics
}
pub struct TxOut {
pub value: u64, // amount in satoshis (1 BTC = 100,000,000 sats)
pub script_pubkey: Vec<u8>, // locking script (see Script module)
}
pub struct Witness {
pub items: Vec<Vec<u8>>, // stack items: signatures, pubkeys, scripts
}
// Serialized size matters because fees are based on virtual size (vsize),
// not just bytes. SegWit reduces effective tx cost by separating witness
// data into a discounted partition.
// Modern txid (post-SegWit, BIP-141) is hash of legacy fields only —
// witness is separate. The full hash including witness is wtxid.