LND

This commit is a simple internal variable rename from 'storedPaymentSeq' to 'storedSeq' in the payments database code. It does not change any logic, behavior, or security properties of the software.

This commit simply renames an internal mutex variable from paymentSeqMx to seqMu. It is a non-functional code cleanup with no behavior change and no security relevance.

This commit adds a new logging subsystem for the payments database package in LND. It only introduces logging infrastructure (a logger variable, subsystem name, and registration with the main logger setup) and does not change any payment-handling logic, database queries, or security behavior. There is no security issue visible in this change.

This commit is a code cleanup and refactoring change in LND's payment database. It moves the 'keep failed payment attempts' setting from the main channel database struct into the dedicated payments key-value store, and makes the payments store accept any compatible key-value backend rather than only the full ChannelState database. There is no direct security vulnerability visible in the diff; it is primarily an architectural change to prepare for future database backends.

This commit is a straightforward code reorganization: it creates a new paymentsDB package and moves payment-related error definitions from the channeldb package into it. All existing error values are preserved unchanged, and callers are updated to import them from the new location. There is no functional change to how payments are processed or validated.

This commit is a straightforward internal code cleanup. It adds a context parameter to a database query method so the same interface can be used by both the existing key-value store and a future SQL implementation. The new context is not used for any security purpose in this change, and no behavior of the application changes.

This commit simply replaces one PGP public key file for a contributor named 'hieblmi' with a newer version of the same key. It is a routine key rotation/update with no code changes and no apparent security vulnerability.

This commit only changes the wording of an error message. It does not alter any logic, permissions, or security behavior. The new message more accurately tells standalone lnd users that taproot overlay channels are not supported in their build, rather than sounding like a forgotten configuration option.

This commit only updates the release notes documentation. It adds a description of a previously merged feature called NoOp HTLCs, which allows sending placeholder payment contracts that don't move money. There is no code change, no bug fix, and no security-related content in the commit itself.

This commit adds a new 'no-op HTLC' feature to LND's lightning channel state machine. A no-op HTLC is a special payment-like message that, when settled, may credit the amount back to the sender rather than transferring it to the receiver. It is only intended for channels using a custom tapscript root and is triggered by external software via custom TLV records. The change touches balance calculations, settlement logic, and how HTLCs are restored from disk. Because it alters fundamental accounting rules, any bug in the logic could affect funds, but the commit itself is a feature addition with guardrails (reserve checks, tapscript-root gating) rather than a clear-cut fix for a known vulnerability.

This commit only adds a new automated test for an existing internal helper function in LND's Lightning wallet code. It does not change any production code, fix a bug, or alter behavior. There is no security risk.

This commit only adds a new test case to an existing unit test. It does not change any production code. The new test verifies that when a special 'noop' (no-operation) HTLC is retransmitted after a restart, it matches the original HTLC exactly, so that both channel partners agree on the commitment signature and avoid accidentally force-closing the channel. Because no real code behavior is changed, this commit by itself does not introduce or fix a live security vulnerability.

This commit only adds new test code for an existing 'noop HTLC' feature in the Lightning Network Daemon (LND). It does not change any production logic, so it cannot introduce a security vulnerability or fix one. The tests verify that special zero-balance HTLCs do not alter channel balances and behave correctly when a party is below its reserve.

This commit adds a small helper method called IsAdd to a data structure in LND's wallet code. It simply tells callers whether an HTLC (a payment channel transaction) is an 'add' type. There is no security issue visible in the change itself.

This commit adds a new internal bookkeeping label called NoOpAdd for a special kind of Lightning payment. The label marks HTLCs whose funds can return to the sender when settled, instead of always going to the receiver. The change only defines the label and makes existing log/commitment logic treat it like a normal Add. There is no actual implementation of the new behavior here, and the commit message says the feature must be explicitly enabled by external software. On its own, this patch does not appear to introduce a vulnerability, but it is a partial change that future code will build on.

This commit only adds a line to the release notes document describing a bug fix from another pull request. It does not change any program code, so it has no direct security effect on its own. The referenced fix relates to payment cleanup after a timeout, but this commit itself is purely documentation.

This change moves a timeout/context check to the very start of each loop iteration in LND's payment lifecycle logic. The goal is to ensure that when a payment attempt times out or the context is cancelled, any remaining in-flight HTLC attempts are resolved and the payment state is updated before the loop exits. The commit message frames this as a correctness fix for resolving attempts after a timeout, but does not describe it as a security vulnerability.

This commit only edits release notes documentation. It adds a bullet point mentioning that the Go compiler version was upgraded to v1.23.12 to fix a potential issue with the SQL API, and fixes a minor list formatting dash. There are no code changes in this commit, so it cannot by itself introduce or fix a security vulnerability.

This commit updates the Go programming language version used to build LND from 1.23.10 to 1.23.12 across build files, Docker images, and documentation. Go patch releases typically include bug fixes and security fixes in the Go runtime and standard library. The commit itself does not change any LND application code, but it may pull in upstream security fixes from the Go toolchain. Without explicit vendor disclosure or a CVE reference in the commit, we cannot confirm which specific vulnerabilities are being addressed.

This commit simply replaces one PGP public key file with an updated version for the same person, extending the key's expiration date. It is a routine key rotation with no code changes and no apparent security vulnerability.

This commit is a performance optimization for LND's channel graph database queries. It replaces a one-by-one loading approach with batch loading when retrieving Lightning channel updates within a time window. The change makes the operation roughly 9-30 times faster depending on the database backend, but it does not appear to fix a security vulnerability or change any security-critical behavior.

This commit fixes a missing counter increment in a database migration that copies Lightning Network channel data from an old key-value store to a new SQL database. The `chunk` variable was supposed to count how many channels had been processed since the last progress report, but it never increased. As a result, progress logging and possibly batching logic would behave incorrectly, potentially making the migration appear stuck or run inefficiently. There is no direct evidence in the commit that this caused a security vulnerability.

This commit refactors how LND fetches multiple channel records from its database. Instead of building each result one-by-one inside a loop, it first collects all raw rows and then builds them in a single batch. The change appears to be a performance optimization with no obvious security impact. There is no mention of fixing a vulnerability, and the diff does not introduce new input handling or access controls.

This commit refactors how LND removes old, closed channels from its network graph database. Instead of building and deleting each channel one at a time inside a loop, it first collects all matching channels, then builds their details in a batch, and finally deletes them together. There is no visible security fix here; it appears to be a performance and code-cleanup change.

This commit is a routine performance refactor. It changes how LND's graph database removes channel data when a block is disconnected, switching from one-by-one processing to batch processing. There is no indication this fixes a security bug; it appears aimed at efficiency and code cleanup.