BIP 144 Explained: How SegWit Transactions Relay Between Nodes

BIP 144 SegWit relay explained: understand witness serialisation, NODE_WITNESS negotiation, inventory flags and witness-aware block requests.

Consensus and relay are separate layers

BIP 141 defines SegWit consensus commitments and script rules. At the same time, BIP 144 defines how capable peers serialise and request witness-aware transactions and blocks. A node can understand witness consensus only if its software implements both validation and suitable networking. Relay negotiation does not activate consensus, and receiving a witness serialisation does not make the transaction acceptable to the local mempool.

Start with the validating node, because the ASIC only hashes the candidate header it receives. Record the node release and the pool component that assembled the block. If those facts are unknown, the operator cannot show which rules were actually applied before electricity was committed to the work.

Witness transaction serialisation

The extended format inserts a marker and flag after the version, retains normal inputs and outputs, then appends a witness stack for every input before locktime. Each stack item uses compact lengths. Transactions with empty witnesses continue to use legacy serialisation. Parsers must reject ambiguous or malformed encodings and calculate TXID and WTXID from the correct forms.

Treat status dashboards as observations, not as the source of truth. Compare them with an independently operated node and retain the raw deployment or template response. Period boundaries, chain reorganisations and cached pool pages can otherwise make a correct-looking percentage describe the wrong state.

NODE_WITNESS service signalling

A peer advertises NODE_WITNESS to state that it can provide witness data. Other nodes inspect service flags before making witness-specific requests. The flag describes capability, not trust, chain tip or archival depth. Peer selection should combine it with network service, latency, diversity and observed behaviour. A misbehaving capable peer can still delay or send invalid data that must be checked.

Build the failure response before the boundary arrives. Define which rejection messages trigger an alert, who can pause a template source and how failover is prevented from returning miners to the same faulty validation stack. A second hostname is not independent when both endpoints share one node.

Witness inventory flags

BIP 144 adds witness-qualified inventory request flags for transactions and blocks. They are used in getdata so the response includes witness serialisation. Announcements generally retain established identifiers under the specified flow. Later WTXID relay improves transaction announcements further. Operators must distinguish requesting witness data from identifying an announcement by WTXID.

Separate readiness, signalling and enforcement in the operating log. Readiness is a claim about software and process, signalling is data carried by blocks, and enforcement is a validation result. Combining them into a single supported or unsupported label hides the point at which revenue is actually at risk.

Block relay and compact blocks

A witness-aware block request returns transactions with witness data so the receiver can validate the witness commitment and scripts. Compact block relay version two uses WTXID-derived short identifiers. Mixing incompatible versions or stripping witness can make reconstruction fail and trigger full-block fallback. Pool gateways and custom proxies should pass negotiation and request types exactly rather than translating loosely.

Map responsibility across the full path: validating node, template server, pool protocol, proxy, firmware and ASIC. For each layer, state what it can alter and what it merely relays. This prevents a version-bit setting in firmware from being mistaken for complete consensus-rule support. Relate that responsibility map to the pool and job-control boundary in our Stratum V2 guide.

Mining-node relevance

A miner’s final block must include valid witness data and the correct coinbase commitment. Template nodes need reliable witness relay from peers and local submissions. A pool server handing only header work to ASICs still owns full transaction validation. Monitor whether candidate construction uses the intended node and whether failover nodes have matching witness capability, policy and chain state.

Test the primary and failover paths with the same checks. Compare chain tip, chainwork, deployment state, required rules and template age, then save the result with a timestamp. The process should be repeatable by another operator without relying on an undocumented pool conversation.

Compatibility test

Connect supported and older nodes in controlled combinations. Inspect service bits, witness getdata flags, transaction serialisation, TXID, WTXID and compact-block version. Submit malformed and stripped witness cases only on test infrastructure and verify rejection. Then compare block arrival and reconstruction metrics. Keep exact client versions in the record because deployed peer behaviour spans several related BIPs.

Turn the conclusion into a business decision. State which chain and settlement venues the operation intends to serve, the maximum acceptable stale-block exposure and the point at which mining pauses. This connects protocol evidence to electricity cost, pool revenue and payout finality.

Operator decision record

A concise decision record for BIP 144 SegWit relay should name the source documents, their dates, the node release tested, the responsible pool or template provider and the exact trigger for action. Include screenshots or machine-readable output for the deployment state. But keep the raw node response as the stronger evidence.

State whether a change affects policy, block construction or consensus validity, because those layers have different failure costs.

Run the check on every production and failover path. Confirm that monitoring alerts on stale templates, unexpected chain tips, rejected proposals and a rise in stale shares. Keep rollback instructions for node and pool configuration. But do not roll back across an active consensus boundary without understanding the rules the older release enforces.

If the evidence conflicts, pause the affected path and investigate before committing more electricity to uncertain work.

For related background, read our plain-English BIP-110 guide and technical BIP-110 review. Those articles use a modern proposal to show why signalling, activation, template construction and accepted chain history must be examined separately.

Conclusion

Bip 144 segwit relay is best understood as a defined interaction between validating software, mining infrastructure and economic acceptance. The safest operator does not infer consensus from a dashboard percentage or a pool slogan. They verify the rule source, the activation boundary, the template fields and the chain their payouts ultimately settle on.

That discipline reduces the chance of hashing an invalid or commercially unwanted block.