LND

This commit only updates the human-readable documentation comments for two existing fields in the LND API (FlapCount and LastFlapNs). It adds a note that these fields are only populated when the peer has at least one channel with us. No code logic, behavior, or security controls were changed.

This commit corrects only a test error message. When a test helper named ReceiveChannelEvent timed out, it previously reported the wrong message about intercepting HTLCs. Now it reports the correct message about receiving channel events. There is no change to production code, no security fix, and no user-facing behavior change.

This change fixes a minor logic bug in LND's channel-fitness monitoring. Previously, the code would create a monitoring entry for any peer that came online, even if there was no open channel with that peer. Now it ignores online events from peers that do not have an open channel. This is a correctness and resource-usage improvement, not a security vulnerability.

This commit fixes a bookkeeping bug in LND's channel-fitness monitoring. Previously, a peer could be counted as 'online' before it had any actual channel with the local node, which could distort uptime and flap-count statistics. Now the monitor only starts tracking a peer as online when the first channel is opened. There is no direct way for an attacker to exploit this, but it could have led to misleading node-reliability metrics.

This commit fixes three places in the LND (Lightning Network Daemon) code where a map was being reset by assigning it to nil. The fix uses Go's `clear()` function instead, which empties the map while keeping the underlying map object. This is a code-correctness fix that prevents potential runtime panics if the same map variable is later used after a reset callback runs, but it is not a clear-cut exploitable security vulnerability based on the diff alone.

This commit updates two Go library dependencies—bbolt (a database engine used by LND) and pflag (a command-line flag parser)—to newer versions. The commit message says the new bbolt version contains 'important bugfixes,' but it does not say those bugfixes are security issues, and no specific vulnerabilities are named in the commit or supplied references. The change is a routine dependency bump, not a patch to LND's own code.

This commit only adds a line to the release notes document describing a previously fixed bug. It does not change any program code, so it cannot by itself introduce or fix a security issue. The release note mentions a sweeper bug where some outputs were not resolved due to an error string mismatch, but no details are provided about whether that bug had security implications.

This commit fixes a bug in LND's transaction fee estimation when 'overlay channels' are used. Previously, the code forgot to count an extra output when estimating how large (and therefore how expensive) the sweep transaction would be. That could lead to paying too little in fees, making the transaction slow to confirm, or in edge cases disrupt the sweep. The fix adds the missing output to the weight estimate and adds tests to confirm the behavior.

This commit changes a log message in LND's transaction notifier so that when a taproot public-key script is used, the log prints a placeholder instead of the actual script bytes. It is a hardening/logging hygiene change, not a fix for an active vulnerability. There is no evidence it prevents exploitation on its own.

This commit changes a single value in a test mock file from false to true. It only affects test code, not the real LND software that users run. There is no security issue in production code here.

This patch teaches LND to recognize a second type of Bitcoin network fee-rejection error ('minimum relay fee not met') alongside the one it already handled ('mempool minimum fee not met'). Without the change, transactions rejected for the new reason would not be retried or fee-bumped automatically, potentially leaving channel-closing or penalty transactions stuck instead of being rebroadcast with a higher fee.

This commit only updates a dependency version number in LND's build files (go.mod and go.sum). It does not contain any code changes, security explanations, or references to a security issue. There is no evidence in the commit itself that this is a security fix.

This commit only reformats the release notes markdown file. It changes how a list of pull request links is displayed (from bullet points to a single bracketed list) with no changes to code, configuration, or documentation content. There is no security relevance.

This commit only adds a single line to the release notes for version 0.20.0, documenting that a new feature (P2TR fallback addresses in BOLT-11 invoices) was added via a prior pull request. There are no code changes, no bug fixes, and no security-related content in the diff.

This commit only adds new test cases for handling Taproot (P2TR) fallback addresses in Lightning invoices. It does not change any production code, fix a bug, or alter security behavior. The change is purely to ensure the existing code correctly recognizes and processes a newer Bitcoin address type in tests.

This commit adds support for a new type of Bitcoin fallback address (P2TR, also known as Taproot) when encoding and decoding Lightning Network payment invoices. Previously, LND could not include or read Taproot fallback addresses in invoices. This is a feature addition rather than a clear security fix, but missing support could have caused payment failures or forced users onto older address types when Taproot was preferred.

This commit only adds documentation to the release notes. It describes a previously merged feature that adds two informational fields to a pending-channel RPC response and stores a confirmation height in the database. There is no code change, no bug fix, and no security relevance in the diff itself.

This commit only adds new integration tests for two existing RPC fields, ConfirmationsUntilActive and ConfirmationHeight. It does not change production code, fix a bug, or alter any security-relevant behavior. There is no indication this is a security patch.

This commit adds two new informational fields to the 'pending channels' API response in LND: one showing how many more block confirmations a channel needs before it becomes active, and another recording the block height where the funding transaction was first confirmed. It is purely a visibility/UX improvement and does not change any security-sensitive logic.

This commit changes how LND records when a new Lightning channel's funding transaction is first confirmed on the Bitcoin blockchain. Previously, the exact block height of first confirmation was not reliably saved. Now it is written to the database as soon as the first confirmation is seen, and reset to zero if a blockchain reorganization removes that confirmation. This is a correctness and reliability improvement rather than a fix for an active exploit, but it helps prevent state inconsistencies that could affect channel safety after restarts or reorgs.

This commit adds a new database field and helper method to record the block height at which a Lightning channel's funding transaction was first confirmed. It is a straightforward data-model and persistence change with no obvious security implications. There is no indication in the commit that this fixes a vulnerability or is being made for security reasons.

This commit is a small API enhancement for LND's internal transaction notification system. It changes the 'Updates' progress channel so that, instead of only reporting how many confirmations are still needed, it also reports the block height where the transaction was included. There is no indication this fixes a security bug; it appears to be a feature improvement to give callers more information.

This change fixes a notification bug in LND's transaction confirmation tracker. Previously, if a transaction had been seen in a block but had not yet reached the required number of confirmations, and then that block was reorged (removed from the chain), subscribers were not told about the reorg. Now they are notified earlier, so downstream logic can react to the lost confirmation instead of waiting for a confirmation that may never come.

This commit is a massive repository import or initial commit adding the entire LND codebase plus CI, docs, and tooling. The PR title mentions relaxing a feature-bit check for peer features, but the supplied diff does not show any code changes related to that title—it only shows newly added files. There is no visible security patch or vulnerability fix in the provided materials.

This commit updates how LND validates a new style of Lightning channel announcement (ChannelAnnouncement2) so it correctly handles both older P2WSH-style channels and newer P2TR (Taproot) channels. Before this change, the validation logic appears to have assumed P2TR channels, which could have caused LND to reject valid announcements for older P2WSH channels or, in the worst case, accept invalid ones. The change also switches the gossiper from using a raw chain hash to carrying full chain parameters, which is needed to interpret on-chain scripts correctly.