rust-lightning

This commit only adds a new fuzz test target. Fuzz tests are automated tools that throw random or crafted input at a piece of code to look for crashes or bugs. The commit does not change any production code, protocol behavior, or user-facing functionality, so it does not introduce or fix a security issue by itself.

This is a routine update to the project's automated reviewer-assignment workflow. It prevents the bot from accidentally adding a second random reviewer when one is already assigned, and adds a manual trigger so maintainers can request an additional reviewer on demand. There is no security-relevant change here.

This is a one-line fix to a Forgejo workflow that assigns reviewers. The workflow requests a temporary identity token from the CI system so it can call another service. The change adds an explicit audience parameter to that token request, ensuring the token is only valid for the intended recipient. Without this, the token might be accepted by a broader set of services or rejected by the intended one, depending on how the CI and target service are configured. It is a hardening/configuration fix rather than a user-facing vulnerability in the Lightning library itself.

This commit changes when users of the Lightning Dev Kit library are notified about a 'splice'—a way to resize a Lightning channel's on-chain funding. Previously both sides got an event when a splice was negotiated. Now only the side that actually added or removed money (a 'local contribution') gets the event. The other side still learns about the locked splice later through a different event. This is a user-interface cleanup, not a security fix, and does not change how funds are protected.

This commit simply corrects a username in an automated reviewer assignment workflow. It changes one reviewer handle from 'joost_spiral' to 'joostjager' so the right person stays in the rotation. There is no security issue here.

This commit is a routine packaging fix. It updates the minimum required version of the rust-bitcoin library for the lightning-invoice crate from 0.32.4 to 0.32.7 because the code no longer compiles against older 0.32.x releases. It does not change any application logic, cryptographic operations, or network behavior, and there is no indication it fixes a security vulnerability.

This commit adds a harmless automation script that randomly picks a code reviewer when a new pull request is opened. It does not change any payment, cryptography, or network code, and it does not introduce any obvious security flaw.

This commit removes a small, custom one-byte buffering helper that was only needed to make older versions of a dependency (rust-bitcoin) happy. After the dependency changed its requirements, the wrapper became unnecessary. There is no security issue here—just routine cleanup of dead code.

This is a small cleanup change that removes an unnecessary BufReader wrapper when deserializing Bitcoin consensus objects. The underlying rust-bitcoin library now accepts a simpler 'Read' trait directly, so the code was updated to match. There is no security issue visible in the change.

This commit removes a duplicate import of the `Hasher` trait in a Rust source file. It is a code cleanup change with no functional or security effect. The `Hasher` symbol was already imported elsewhere in the same scope, so the duplicate import only generated a compiler warning. No behavior of the Lightning Dev Kit code changes as a result.

This commit fixes a denial-of-service risk when rust-lightning reads saved data containing HashMaps. A corrupted or malicious length field could previously trick the program into reserving a huge amount of memory before it had read any actual entries. The patch now caps the initial allocation to a safe maximum based on the largest buffer size the code is willing to handle. The commit message says the affected deserialization paths were mainly ChannelManager and scorer data, with scorer data sometimes coming from a semi-trusted source.

This commit fixes a programming bug in rust-lightning's send_to_route function. When a user supplied a payment route with no paths or an empty first path, the code tried to create a fallback 'dummy' public key using 32 bytes of data, but public keys require 33 bytes. That mismatch caused the program to panic and crash. The fix simply changes the dummy data to 33 bytes so the fallback public key is valid and the unwrap succeeds. It is a denial-of-service/crash bug, not a theft-of-funds vulnerability, because the panic aborts the operation rather than letting an attacker manipulate funds.

This commit fixes a mismatch in how Lightning feature flags are read from the wire. Previously, a feature set whose serialized byte length was exactly 65,535 bytes (u16::MAX) could be deserialized incorrectly because the code used a generic vector reader that may interpret the length differently. The fix reads the length as a u16 and then reads exactly that many bytes, matching the write side. The commit message says this 'shouldn't really matter in practice.'

This commit fixes a bug where a remote peer could crash a Lightning node by sending a specially chosen custom message. The crash happened because a message-routing helper assumed a sub-component would always recognize any message type matching its declared pattern, but sub-components can legitimately decline to decode some types within their pattern. The fix replaces an internal 'this should never happen' crash with a graceful 'unknown message' response.

This change fixes a crash and duplicate-queue bug in the Lightning Dev Kit's LSPS2 payment queue. After a restart, previously seen intercepted HTLCs can be replayed; the old code would panic (in debug builds) or add duplicates, while the new code returns the existing payment status instead. It is a reliability/idempotency fix rather than a direct theft-of-funds vulnerability, but a panic on restart could disrupt a liquidity service.

This commit fixes a security hole in how a Bitcoin Lightning wallet talks to Electrum servers. Previously, the wallet asked a server for a specific transaction by its ID, but it did not check that the returned transaction actually matched that ID. A malicious or compromised Electrum server could send a different transaction instead, and the wallet would trust it. The fix adds a simple verification step: after receiving a transaction, the wallet recomputes its ID and rejects it if it does not match what was requested. The commit message explicitly says this prevents a malicious server from substituting an unrelated transaction and providing matching proof data.

This commit fixes a guard condition in LDK's Esplora transaction-sync code. The code tries to skip 64-byte transactions because such transactions can be abused in a known Bitcoin Merkle-tree weakness. The bug was that it measured total transaction size, which includes witness data. A transaction with witness data could be larger than 64 bytes in total size while still having a 64-byte non-witness serialization, so the guard could be bypassed. The fix uses a helper that checks the base (non-witness) size instead.

This commit fixes a bug in how rust-lightning's Electrum transaction sync checks for a known Bitcoin Merkle-tree weakness. The old code rejected transactions whose total byte size was exactly 64, but an attacker could pad a transaction with extra witness data to push the total size above 64 while keeping the non-witness (base) size at 64. Because Bitcoin txids and Merkle leaves are computed from the non-witness data, the bypass could let a malicious 64-byte-base transaction be treated as a valid Merkle leaf, potentially allowing fake transaction confirmations. The fix checks the base (non-witness) size instead of total size and applies the check in more code paths.

This commit fixes a subtraction underflow bug in the code that decides how much of a Lightning payment a blinded intermediate node should forward. With extremely high proportional fees and a small incoming payment amount, the code subtracted a larger fee from a smaller amount, which would crash in debug builds and silently produce a wrong, too-small result in release builds. In release builds that wrong result could have allowed a payment to be relayed that should have been rejected because it could not cover the node's fee. The fix uses Rust's checked subtraction so the function returns 'None' instead of underflowing.

This commit fixes a bug in the Lightning Dev Kit where, after a peer reconnects, the same cryptographic 'revoke_and_ack' message could be generated and sent twice. The duplicate would contain a secret the peer had already accepted, so the peer would reject it and force-close the payment channel. The fix clears an internal 'monitor-pending' flag when the signer-resume path actually produces the message, preventing the later duplicate.

This commit fixes a fee-reservation bug in a Lightning Network node implementation. When a node calculates how much money it can still send through a channel, it must set aside enough funds to pay the on-chain transaction fee if the channel later closes. Previously, the calculation only considered the node's own view of the commitment transaction. Because the two channel partners can agree on different 'dust limits,' the actual fee on the partner's version of the commitment can be higher. If the node did not reserve enough, it could propose a payment that is valid by its own numbers but violates the protocol when the partner checks it, potentially causing the channel update to be rejected or the channel to become inconsistent. The patch now reserves the larger of the two possible fees.

This commit is a pure code cleanup: it takes one large function that calculates how much money can still be sent over a Lightning channel and splits it into smaller, named helper functions. The actual arithmetic and rules appear unchanged, and the commit message explicitly says most of the changes are code moves. There is no indication this fixes or introduces a security problem.

This commit fixes a bug in how the Lightning node calculates the maximum amount a user can splice out of a channel. Previously, the calculation only looked at the user's own view of the channel (the local commitment). It now also checks the peer's view (the remote commitment). If the two views differ because an HTLC is considered 'dust' (too small to be worth including as an output) on one side but not the other, the old code could advertise a splice-out limit that the node's own safety rules would later reject. In debug builds this triggered an internal assertion failure; in release builds it could lead to inconsistent or rejected splice attempts. The fix makes the advertised limit valid under both commitments.

This commit relaxes a safety check in how Lightning channels calculate available balances during fee spikes. Previously, the code tried to ensure a commitment transaction would still have at least one output even if fees spiked. The change says that for one specific calculation (get_available_balances), it's okay not to guard against the 'no outputs' case under fee spikes, because the worst outcome is that an HTLC you just sent gets failed back by the receiver. The change keeps the stricter guard in another function (get_next_commitment_stats).

This commit fixes a bug in the Lightning Dev Kit's filesystem storage module. Previously, leftover temporary and 'trash' files from crashes or interrupted operations were mistakenly treated as real data folders during listing and migration. The patch makes the code skip these stale artifacts, preventing potential confusion or errors during data migration. It is a defensive hardening fix rather than a directly exploitable vulnerability.