Pick a depth. Each prompt opens in your AI pre-loaded with the lesson. Click a row to preview the prompt.
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.
// 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.