Transaction Weight

Overview

Bitcoin transaction weight was introduced with Segregated Witness to measure block resource use. Base transaction bytes are counted more heavily than witness bytes, and the resulting weight units determine how much of the block limit a transaction consumes. Virtual size is derived from weight and is commonly used for fee-rate calculations.

The distinction means two transactions with the same raw Transaction Size can consume different effective capacity if their witness composition differs. A wallet estimating fees must know the input script types and expected signatures before it can calculate accurate weight. Legacy, P2SH-wrapped SegWit, native SegWit, and Taproot spends can have different weight profiles.

Weight is primarily a Bitcoin-specific consensus and fee-accounting concept. Ethereum gas and Solana compute or packet limits are not interchangeable with it. Some applications use “weight” informally for transaction priority or complexity, but those values should be labeled separately to avoid confusing them with Bitcoin’s defined formula.

Payment and custody systems should store weight, virtual size, fee, and fee rate when monitoring Bitcoin transactions. Fee bumping and coin selection should consider the final signed weight, including witness data. Optimizing only output amount or raw byte count can produce inaccurate fees, delayed confirmation, or unnecessary block-space consumption.

The supporting record should capture the final Bitcoin weight units, virtual size, input script types, witness data, fee, and fee rate. Without that context, teams may miss that raw bytes alone do not capture SegWit’s discounted accounting and unsigned estimates can omit final witness size. Appropriate controls should estimate from the actual spend types and recheck after signing before fee-sensitive broadcast.

Fee tools should calculate it from the final Signed Transaction rather than an incomplete unsigned estimate.