Segregated Witness (Peer Services)

Summary

The peer-to-peer side of SegWit: how witness data is serialised and relayed. Where BIP141 defines the witness as a consensus structure, this BIP defines how nodes advertise support for it and exchange it. In the new serialisation, two bytes follow the version field — a marker that must be zero and a flag that must be non-zero — and each input's witness is placed before the locktime. To an old parser the zero marker reads as a transaction with no inputs, so software that does not understand witnesses cannot mistakenly accept the new format; transactions with no witness data keep using the old serialisation. Transaction ids are still computed from the witness-free serialisation, and the hash covering the witness is treated as a separate identifier. A node advertises witness capability through the NODE_WITNESS service bit, and witness data is only sent when a peer explicitly asks with MSG_WITNESS_TX or MSG_WITNESS_BLOCK in getdata; otherwise the data arrives stripped, so un-upgraded nodes keep working unchanged.

Why it matters

This is the layer that actually makes SegWit deployable without upgrading every node at once: old peers keep receiving transactions they can parse while upgraded peers exchange the witness. The pattern — negotiate a capability, then serve the richer format only on request — became a template for later network-level extensions.

Related BIPs

• BIP 141 — Segregated Witness (Consensus layer)
• BIP 143 — Transaction Signature Verification for Version 0 Witness Program

Related articles

• Transactions Deep Dive
• Running a Bitcoin Node — Verifying for Yourself