What the developer wrote
Authored by ziggie
docs: move gossip bounds note to v0.21.2
What changed, and why it matters
This commit only moves an existing release-note entry from one version's notes (v0.22.0) to another (v0.21.2). It does not change any code, build files, configuration, or tests. The change is purely editorial documentation bookkeeping.
No action required; this is a documentation-only reorganization. Review the actual code change in PR #10992 separately if assessing the underlying security fix.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff is a literal cut-and-paste of a release-note bullet about bounding memory during channel-graph gossip sync. The text is removed from docs/release-notes/release-notes-0.22.0.md and inserted into docs/release-notes/release-notes-0.21.2.md, with corresponding contributor-list line moves. No source code is modified.
Changed components
docs/release-notes/release-notes-0.21.2.mddocs/release-notes/release-notes-0.22.0.mdInspect captured patch +11 / −11
diff --git a/docs/release-notes/release-notes-0.21.2.md b/docs/release-notes/release-notes-0.21.2.md
index cc96ab6..82c8d42 100644
--- a/docs/release-notes/release-notes-0.21.2.md
+++ b/docs/release-notes/release-notes-0.21.2.md
@@ -43,6 +43,16 @@
v0.20-era mandatory version so the v0.21 waiting proof migration runs
without replaying older migrations against an already-initialized database.
+* [Bounded the memory used while syncing the channel
+ graph](https://github.com/lightningnetwork/lnd/pull/10992). A peer replying
+ to our `query_channel_range` could previously make us buffer an
+ unpredictable number of short channel IDs, as the only limit was a coarse
+ 67MB cap on the bytes a single zlib-compressed reply could decompress to.
+ Replies are now capped at a precise number of short channel IDs, both
+ per-message and in aggregate across a single query, and the accumulated
+ reply state is released as soon as any reply fails validation so that a
+ peer cannot pin it by deliberately forcing an error.
+
# New Features
## Functional Enhancements
@@ -107,3 +117,4 @@
* bitromortac
* Jared Tobin
+* Olaoluwa Osuntokun
diff --git a/docs/release-notes/release-notes-0.22.0.md b/docs/release-notes/release-notes-0.22.0.md
index 911782f..750a200 100644
--- a/docs/release-notes/release-notes-0.22.0.md
+++ b/docs/release-notes/release-notes-0.22.0.md
@@ -55,16 +55,6 @@
the reported network statistics such as total network capacity, channel
count and max out degree.
-* [Bounded the memory used while syncing the channel
- graph](https://github.com/lightningnetwork/lnd/pull/10992). A peer replying
- to our `query_channel_range` could previously make us buffer an
- unpredictable number of short channel IDs, as the only limit was a coarse
- 67MB cap on the bytes a single zlib-compressed reply could decompress to.
- Replies are now capped at a precise number of short channel IDs, both
- per-message and in aggregate across a single query, and the accumulated
- reply state is released as soon as any reply fails validation so that a
- peer cannot pin it by deliberately forcing an error.
-
# New Features
## Functional Enhancements
@@ -169,4 +159,3 @@
* Boris Nagaev
* Erick Cestari
* Jared Tobin
-* Olaoluwa Osuntokun
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.