LND

This commit is a simple test-only rename. It changes the names of two internal helper functions used only in test files: `assertPaymentStatus` becomes `assertPaymentstatus`, and `assertPayments` becomes `assertDBPayments`. No production code is modified, and no behavior changes. There is no security relevance.

This commit only fixes a mismatch between error messages and actual timeout durations in test helper code. It does not change production behavior or fix any security issue.

This commit is a routine code cleanup titled 'fix linter'. It removes blank lines, unused test variables, and outdated linter suppression comments. The only functional change is adding a type-safety check when reading payment updates from a stream, which now returns a clear error instead of potentially panicking if an unexpected type appears. There is no indication this fixes an active security vulnerability.

This commit is a large but straightforward code refactor: it moves payment-related data structures, database logic, and tests out of the `channeldb` package into a new `payments/db` package. The commit message explicitly says it is the smallest move possible to avoid import cycles and keep the change set small. No security fixes, behavior changes, or vulnerability patches are visible in the diff.

This commit removes an expired PGP public key belonging to a former release signer from the project's install verification script. It is a routine key hygiene change: keeping an expired key in the trusted key list could cause signature verification to fail or accept stale signatures, but the commit itself does not introduce any code vulnerability.

This commit only adds stopwatch-style timing to log messages that already existed. It records how long database migration steps take and prints the duration in the log. There are no changes to security logic, access controls, cryptography, or data handling.

This commit simply deletes a two-line TODO comment from a benchmark test file. A TODO is a developer note, not code. There is no functional change, no bug fix, and no security relevance in the diff itself.

This change is a performance optimization for LND's database code. It moves a 'does this channel already exist?' check from inside a helper function to the caller, so the check is skipped during database migrations where it isn't needed. The commit message says this significantly speeds up migrations on PostgreSQL. There is no direct evidence this fixes a security vulnerability.

This commit simply removes a three-line comment (a TODO note) from a Go source file. No code behavior changed, no bug was fixed, and no security issue is present in the diff.

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 is a simple internal rename of a variable from currPaymentSeq to currSeq. It does not change any behavior, logic, or security properties of the code. There is no security issue present.

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