lnwire: remove legacy zlib encoding for channel queries

[TechLateef]

Change Description

This PR removes support for the deprecated EncodingSortedZlib format (type 1) which was officially dropped from the BOLT 7 specification in lightning/bolts#981.

Changes:

• Removes all zlib compression/decompression logic from lnwire messages.
• Marks the EncodingSortedZlib constant as Deprecated to retain protocol documentation.
• Updates the decode path to explicitly return an error when a peer attempts to send zlib-encoded data, providing a clear error rather than falling through to a generic "unknown encoding" error.
• Removes zlib-specific chunking logic (maxQueryChanRangeRepliesZlibFactor) from the discovery syncer.
• Cleans up all testing suites (message_test.go, reply_channel_range_test.go, query_short_chan_ids_test.go) that previously verified zlib scenarios.
• Leaves channeldb/migration files untouched to ensure historical snapshots remain intact.

Fixes #10694

Steps to Test

1. Run make unit to ensure all lnwire and discovery tests pass.
2. Review the code to verify that no active code paths rely on EncodingSortedZlib.

Pull Request Checklist

Testing

• Your PR passes all CI checks.
• Tests covering the positive and negative (error paths) are included.
• Bug fixes contain tests triggering the bug to prevent regressions.

Code Style and Documentation

• The change is not insubstantial. Typo fixes are not accepted to fight bot spam.
• The change obeys the Code Documentation and Commenting guidelines, and lines wrap at 80.
• Commits follow the Ideal Git Commit Structure.
• Any new logging statements use an appropriate subsystem and logging level.
• Any new lncli commands have appropriate tags in the comments for the rpc in the proto file.
• There is a change description in the release notes, or [skip ci] in the commit message for small changes.

📝 Please see our Contribution Guidelines for further guidance.

[github-actions]

🔴 PR Severity: CRITICAL

Automated classification | 8 files | 269 lines changed

🔴 Critical (3 files)

• lnwire/encoding.go - Lightning wire protocol message encoding; marks EncodingSortedZlib as deprecated
• lnwire/query_short_chan_ids.go - Wire message encode/decode logic; removes zlib chunking/compression paths for query_short_channel_ids/reply_channel_range
• lnwire/test_message.go - lnwire package helper (not a _test.go file, so classified by package path)

🟠 High (1 file)

• discovery/syncer.go - Gossip protocol syncer; removes zlib-specific reply chunking factor (maxQueryChanRangeRepliesZlibFactor)

🟢 Low (4 files)

• docs/release-notes/release-notes-template.md - Docs
• lnwire/message_test.go - Test-only change
• lnwire/query_short_chan_ids_test.go - Test-only change
• lnwire/reply_channel_range_test.go - Test-only change

Analysis

The highest-severity files are in lnwire/*, which defines the Lightning wire protocol messages exchanged with peers — changes here directly affect interoperability and message parsing for gossip queries (query_short_channel_ids, reply_channel_range). This PR removes the deprecated EncodingSortedZlib (type 1) encoding per BOLT 7's removal of zlib support, replacing the decode fallback with an explicit error. Although the change is a net deletion of legacy code, it touches wire-level decode paths that peers rely on, so it warrants expert review to confirm no peer compatibility regressions (e.g. correctly erroring rather than silently mis-parsing legacy zlib-encoded payloads) and that channeldb/migration snapshots (explicitly left untouched per the PR description) remain unaffected.

No severity bump applied: only 5 non-test files and ~189 non-test lines changed (well under the 20-file/500-line thresholds), and only one critical package (lnwire) is touched.

---

_{To override, add a severity-override-{critical,high,medium,low} label.}

[saubyk]

Please correct the file for the release note entry

[saubyk]

/gateway review

[lightninglabs-gateway]

Gateway review — 2 findings

🔴 0 Blocker · 🟠 1 Major · 🟡 1 Minor · 🔵 0 Nit

Summary

This PR removes the deprecated EncodingSortedZlib (type 1) gossip-query encoding, matching its removal from BOLT 7. The bulk of the change is clean deletion: the zlib encode block, the maxZlibBufSize/zlibDecodeMtx memory guards, the maxQueryChanRangeRepliesZlibFactor reply multiplier, and the corresponding test fixtures. The processChanRangeReply and encode-side removals are effectively dead-code cleanup — both key off g.cfg.encodingType, which only ever holds EncodingSortedPlain (encodingTypeToChunkSize has no other entry).

The one change that alters behavior on untrusted input is the decode path: decodeShortChanIDs now returns a hard error for type 1 instead of decompressing, and this function backs both QueryShortChanIDs.Decode and ReplyChannelRange.Decode. That behavior change, and its effect on peers that still emit zlib, is the main thing to confirm before merge. A secondary API-hygiene issue remains around the retained-but-unencodable exported constant.

Bot commands

• /gateway re-review — re-run after pushing changes
• /gateway dismiss <id> — silence a finding (maintainers)
• /gateway explain <id> — elaborate on a finding (anyone)

[lightninglabs-gateway]

🤖 gateway audit metadata for this PR — auto-generated, please don't edit.

[saubyk]

/gateway re-review

[lightninglabs-gateway]

Gateway review — 2 findings

🔴 0 Blocker · 🟠 1 Major · 🟡 1 Minor · 🔵 0 Nit

Summary

Since the last review the author addressed F2: encodeShortChanIDs now has an explicit case EncodingSortedZlib returning ErrZlibNotSupported instead of falling through to the misleading ErrUnknownShortChanIDEncoding, and the EncodingSortedZlib doc in encoding.go now states the constant is "retained for detection on the decode side only — it must never be used for encoding."

F1 remains unresolved. The decode side still hard-rejects a peer-controlled type-1 encoding byte with a wire-decode error. The specialist pass sharpens, but does not clear, the concern: the guard removal itself is safe within lnwire (the maxZlibBufSize limit and zlibDecodeMtx only ever protected the now-deleted inflate loop, and both were unexported so channeldb/migration could never have referenced them), so the live risk is the interop/propagation behavior against not-yet-upgraded peers, which still cannot be confirmed from the loaded context.

One genuinely-new minor finding: the new encode-side error branch has no test.

---

Status of prior findings

• F2 addressed: Fixed in lnwire/query_short_chan_ids.go — encodeShortChanIDs now has an explicit case EncodingSortedZlib returning ErrZlibNotSupported (no longer falling through to ErrUnknownShortChanIDEncoding), and lnwire/encoding.go tightens the Deprecated doc to state the constant is "retained for detection on the decode side only — it must never be used for encoding."

Bot commands

• /gateway re-review — re-run after pushing changes
• /gateway dismiss <id> — silence a finding (maintainers)
• /gateway explain <id> — elaborate on a finding (anyone)

[saubyk]

/gateway dismiss F1 per #10980 (comment)

[lightninglabs-gateway]

🚫 Dismissed F1 (major) by @saubyk — per #10980 (comment)

Open findings on this PR: 🟡 F3 (minor)

[saubyk]

/gateway re-review

[lightninglabs-gateway]

Gateway review

No findings.

---

Status of prior findings

• F2 addressed: Addressed — encodeShortChanIDs carries an explicit case EncodingSortedZlib returning ErrZlibNotSupported (lnwire/query_short_chan_ids.go), and the Deprecated: doc comment in encoding.go now states the constant is decode/detection-only.
• F3 addressed: Addressed — TestEncodeShortChanIDsZlibRejection (lnwire/query_short_chan_ids_test.go) asserts encodeShortChanIDs(&b, EncodingSortedZlib, nil) returns ErrZlibNotSupported via require.ErrorIs, covering the encode branch that was previously untested.

Bot commands

• /gateway re-review — re-run after pushing changes
• /gateway dismiss <id> — silence a finding (maintainers)
• /gateway explain <id> — elaborate on a finding (anyone)

[saubyk]

/gateway approve

[lightninglabs-gateway]

✅ Approved — all prior findings addressed.

Findings recap

Findings:

• F1 (major) — unresolved: decodeShortChanIDs now returns fmt.Errorf("zlib encoding (type %d) is no longer supported", ...) for a type-1 payload instead of decodin…
• F2 (minor) — addressed: EncodingSortedZlib remains an exported constant, but the EncodingSortedZlib case was fully removed from encodeShortChanIDs, so it now …
• F3 (minor) — addressed: The new EncodingSortedZlib branch in encodeShortChanIDs returns ErrZlibNotSupported, but only the decode-side rejection is covered by …

Dismissed:

• F1 by @saubyk — per #10980 (comment)

---

Approved by @saubyk via /gateway approve. Last reviewed at 7b27191. Skill v0.3.0, model claude-opus-4-8.