LND

This commit simply replaces GitHub's free-text bug report template with a structured form. It does not change any LND code, configuration defaults, network behavior, or security controls. There is no security issue here.

This commit only updates the release notes documentation. It adds a single bullet describing a prior code change that limits two peer-tracking metrics to peers that share channels. There is no code change, no bug fix, and no security-relevant content in the commit itself.

This change makes the ListPeers RPC more reliable. Previously, if the system couldn't retrieve a peer's 'flap count' (a count of connection up/down events), the entire ListPeers request would fail. Now it logs the error and continues, returning the rest of the peer information. This is a robustness improvement rather than a typical security vulnerability, but the original behavior could have been used to deny access to peer information.

This change is a small hardening fix in LND's RPC server. It makes the code gracefully handle a newly introduced error case—when a peer is not yet known to the channel event store—instead of potentially failing or returning unexpected behavior. It is not a fix for an active exploit, but it prevents a class of operational/logic errors from surfacing to users.

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 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 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 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 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 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 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 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 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.