rust-lightning

This commit only changes how log messages are formatted. It makes peer IDs, channel IDs, and payment hashes appear more clearly in log output so developers and operators can more easily trace what a log entry refers to. There is no security vulnerability or behavior change to the Lightning protocol itself.

This commit is a straightforward cleanup of log messages. It removes duplicate channel IDs from the text of log lines when the same ID is already attached as a structured field. There is no change to program logic, network behavior, cryptography, or access control. It only affects what developers and operators see in logs, making them more consistent and easier to read.

This commit is a cosmetic formatting change to log output. It pads log level names (like 'INFO' or 'DEBUG') so that 4-letter and 5-letter levels line up visually in log files. There is no security relevance.

This commit is a minor code cleanup in test-only logging code. It replaces several hand-written log formatting blocks with a single shared Display implementation for log records. There is no functional change to production code and no security relevance.

This commit adds a standard way to print log records and updates test code to use it. It is a code cleanup/refactoring change with no security relevance.

This commit is a pure code cleanup: it removes a Rust macro used in tests and replaces every call to that macro with an equivalent function call. The behavior of the tests remains the same; no production code or security logic was changed.

This commit removes an older, now-redundant HMAC/nonce authentication mechanism from LDK's blinded payment paths. The code had already introduced a newer 'ReceiveAuthKey' way to authenticate the same data, so the old (hmac, nonce) fields are being stripped out to simplify the codebase. The change is described by the project as a cleanup, not a security fix, and the diff shows the old verification checks being replaced by reliance on the newer mechanism. There is no direct evidence in the commit of an exploitable vulnerability, but removing a redundant authentication layer is a normal hardening step.

This commit changes how hidden (blinded) Lightning payment paths are created and checked. It adds a new 'receive authentication key' used when encrypting the final hop's details, and it makes the receiving node verify that the final hop was encrypted with that key. This is a defensive hardening change that reduces the data sent in payment paths and makes the verification logic consistent with another similar feature (blinded message paths).

This commit is preparatory plumbing for a future fix. It changes how Lightning gossip messages are internally forwarded so that the peer handler knows which two nodes are on each side of a channel. The commit itself does not change any forwarding rules, but the next commit is expected to use this information to ensure a node always forwards gossip about its own public channels, even to peers that have asked to stop receiving gossip. That addresses a real-world routing problem where LSPs could become isolated from the wider network, but it is not a direct security vulnerability and does not introduce one.

This commit fixes a Lightning network gossip propagation bug. Some peers ask nodes not to send them gossip updates. Previously, LDK honored that request too strictly: if a node had only one connection to the rest of the network and that connection asked for no gossip, information about the node's own public channels would not spread to other peers. The change ensures that gossip about channels the node itself participates in is always forwarded to all peers, even those that normally filter out gossip. This improves network visibility of the node's own channels but does not create a direct way to steal funds or crash the node.

This commit is a preparatory refactor for a future Lightning Dev Kit change. It adds the two node IDs of a channel to the internal `BroadcastChannelUpdate` message event, but does not yet change any actual gossip-sending behavior. The goal is to later allow LDK to forward gossip about its own public channels even to peers that normally ask not to receive gossip. As it stands, this commit only carries extra metadata and updates call sites; it does not by itself fix or break security.

This commit only adds new test code. It introduces test vectors for a new Lightning channel type (v3 / zero-fee anchor commitments) and a small helper function for converting hex strings to payment hashes in test utilities. There is no change to production code, no bug fix, and no security patch.

This commit only changes test code. It updates a Lightning channel test helper so that test vectors explicitly provide payment preimages instead of the helper guessing them from a hardcoded loop. There is no change to production code and no security risk to users.

This commit only changes a test file inside the Lightning Dev Kit codebase. It updates how a test macro calculates signature types and output indexes for different channel feature combinations. There is no change to production code, no bug fix, and no security-relevant behavior change.

This commit is a pure code cleanup in the project's test files. It removes markers that told the automatic formatter (rustfmt) to skip certain test code, then reformats that code and moves a few small helper functions to a shared test utilities file. There is no change to the actual Lightning protocol logic, wallet behavior, or any code that runs in production.

This commit is a simple code cleanup: it moves three small helper functions used only in tests from one test file into a shared test utility file. There is no change to production code, no security fix, and no behavior change.

This commit is a pure test-code refactoring. It moves a large macro used to check commitment transactions from inside one specific test function to a shared location so it can be reused by upcoming tests. No production code, user behavior, or security logic is changed.

This commit is a straightforward internal cleanup in the rust-lightning test code. It removes a helper macro called `get_htlc_update_msgs!` and replaces every use of it with an already-existing function of the same name. There is no change to production code, user-facing behavior, or security logic.

This commit is a test-only change. It replaces fuzz-testing coverage for the older 'quiescence' protocol with coverage for the newer 'splicing' feature in a Lightning channel consistency fuzz target. It adds test wallets, message handlers, and fuzz actions to exercise splicing, but makes no changes to production code that handles real user funds or network messages.

This is a routine code cleanup that removes a helper method and copies its logic directly into the two places that used it. There is no security fix or behavior change visible in the diff.

This commit removes a debug-only assertion in the code that handles splicing (a way to resize a Lightning channel). The assertion incorrectly assumed two commitment counters would always match during a splice, but they can legitimately differ when both channel peers propose updates at the same time. The change only affects debug builds and does not alter production behavior, so it is unlikely to be directly exploitable. It is a code-correctness fix rather than a security patch for a live vulnerability.

This change fixes a minor user-experience issue in the Lightning Dev Kit's channel splicing flow. Previously, if a user requested a splice but the internal state machine wasn't ready to send the required 'stfu' (stop, wait for update) message immediately, the code would return an error to the caller even though the splice was still pending and would proceed later. Now it logs the condition and returns success with no message, avoiding an unnecessary and confusing error.

This commit fixes a bug in how the Lightning Dev Kit tracks money that is already traveling along hidden ("blinded") payment paths. Previously, when retrying a payment split across several blinded paths, the software could over-send because it did not count how much was already in-flight on each blinded path. The patch adds tracking for those blinded paths and uses it when scoring routes, preventing attempts to exceed each path's stated maximum.

This commit adds a simple public helper method that exposes the internal Utxo field of a FundingTxInput object. It is a pure API convenience with no security-relevant behavior change.

This commit fixes how rust-lightning estimates the final size of a Bitcoin transaction during the interactive-tx protocol used to build funding transactions for Lightning channels. The old estimate double-counted a fixed empty-signature weight and forgot to add the SegWit marker/flag bytes, so it could wrongly allow a transaction that is actually too large to be accepted by the Bitcoin network. Such a transaction would not propagate through standard Bitcoin nodes, potentially causing a channel-funding attempt to fail or get stuck.