Skip to content
Satnam SatoshiIn service of humanityFind your place ↗
Menu

Sikh Bitcoin · Advanced · Lesson 11 of 21

SegWit and transaction weight

Connect a structural change to practical fee accounting.

About 14 minutes with practice. You only need something to take notes with. No real wallet details or payments are part of this lesson.

Course contents · Lesson 11 of 21
  1. Read the whitepaper as an argument
  2. Hashes and Merkle commitments
  3. UTXOs, change and accounting
  4. Scripts describe spending conditions
  5. Signatures and what they authorize
  6. Block headers and the chain of work
  7. Difficulty, hashrate and noisy observations
  8. Issuance, fees and incentives
  9. Mempools and policy are not consensus
  10. Fee changes: RBF and CPFP
  11. SegWit and transaction weight
  12. Taproot and Schnorr: useful, not magical
  13. HD wallets and derivation paths
  14. PSBT: separate construction from signing
  15. Descriptors make a wallet policy portable
  16. Full nodes, pruning and verification
  17. Reorganizations and lightweight evidence
  18. Lightning channels and HTLCs
  19. Lightning liquidity has direction
  20. Soft forks, proposals and human coordination
  21. Capstone: trace a payment end to end

What you will learn

  • Explain witness separation at a high level.
  • Calculate virtual size from weight.

Witness data has a distinct role

Segregated Witness, described in BIP 141, separates witness information used to satisfy spending conditions from the traditional transaction serialization used for the transaction identifier. This addresses important transaction-malleability concerns for the relevant forms and introduces a weight-based way to constrain block resources. It does not mean that signatures disappear or stop being validated.

Weight and virtual bytes are related

Transaction weight combines base size and total size according to the specified formula. Virtual size is weight divided by four, rounded up. Wallet fee estimates commonly use virtual bytes, so a comparison based only on raw file length can be misleading. The output and input types influence the data that needs to be represented.

Explain benefits without universal promises

A SegWit label does not guarantee that every transaction is cheaper than every older-format transaction. Input counts, script structure and fee rates still matter. Likewise, a protocol improvement does not make an unknown wallet implementation safe. When reviewing a technical claim, separate the deployed consensus feature from product support and a particular transaction’s measured characteristics.

For a practical estimator, label whether its input is bytes, weight units or virtual bytes before applying a fee rate. A correct multiplication with the wrong unit still produces a wrong fee.

Practice on paper

A hypothetical transaction weighs 561 weight units. What virtual size should be used before multiplying by a fee rate?

Reveal the worked answer

Divide by four to get 140.25 and round up: 141 virtual bytes. At an illustrative 3 sats/vbyte, the corresponding fee calculation is 423 sats.

Check your understanding

Choose an answer in your head or on paper, then reveal the explanation. Retry whenever you like. Answers are not submitted or scored; completion marks are your own learning notes.

1. Does witness separation mean signatures are no longer checked?

  • Yes
  • No
Reveal answer 1

No. Witness data remains part of validation.

2. Should virtual size round down when weight is not divisible by four?

  • Yes
  • No
Reveal answer 2

No. BIP 141 specifies rounding up.

Take this with you

Use the protocol’s resource units when comparing fees.

Your learning, at your pace

Read every lesson freely. Optional progress tracking needs JavaScript and browser storage; it does not require an account or wallet.