Core Lightning

This commit only adds test data files (a fuzzing seed corpus) for a new fuzz test called fuzz-amount-arith. It does not change any production code, so it cannot introduce a security vulnerability or fix one. It is purely a testing/development aid.

This commit changes a project Makefile so that a code-style check no longer scans files in the fuzz-testing directory. The check normally flags direct access to internal Bitcoin-amount fields (satoshis/millisatoshis) because that can lead to arithmetic overflow bugs. The change lets fuzz tests read those raw fields directly without causing a CI failure. It is a tooling/CI exemption, not a change to wallet, cryptographic, or network code, and it does not introduce a vulnerability on its own.

This change fixes a bug in Core Lightning's channel backup plugin. Previously, when recovering a backup from a peer, the node would save whatever backup the peer sent, even if it was older than the backup already stored. Now it checks a timestamp inside the backup and only keeps the newest one. Using an old backup during recovery could, in edge cases, lead to stale or incorrect channel state being restored.

This commit only adds extra informational fields to the getemergencyrecoverdata RPC. It tells users whether their backup file can create penalty transactions and lists the backed-up channel IDs. There is no security fix or vulnerability being patched; it is a user-facing diagnostic improvement.

This commit adds a new test case that demonstrates a bug in Core Lightning's xpay feature when paying over a 'blinded path' where the payer is the first hop. The test shows that the payer incorrectly adds fees to the amount it forwards to its direct peer, even though it is effectively paying itself. The test is marked as expected to fail (xfail), meaning the bug is known but not yet fixed in this commit. It is a test-only change, not a code fix.

This commit fixes a bookkeeping bug in Core Lightning's xpay plugin. Previously, when a payment was routed through the user's own node, the plugin incorrectly reported that the user had paid fees to themselves. The fix separates the amount actually injected into the network from the amount reported as sent, so self-routed payments no longer show a fake fee. This is a reporting/accounting issue, not a way for an attacker to steal funds.

This commit fixes a bug in Core Lightning's `injectpaymentonion` RPC command. Previously, when a user manually injected a payment onion (a way to send a Lightning payment with a pre-built route), the command treated the `amount_msat` parameter as the amount to forward to the next peer, rather than the amount this node is expected to receive. For normal routes this was fine, but for blinded paths—where the true recipient and fees are hidden inside an encrypted onion—the node could accidentally send too much money to the next hop, effectively overpaying fees or losing funds. The fix changes the code to use the amount encoded inside the onion payload (`amt_to_forward`) as the actual amount to send onward, which is correct for blinded paths. The commit also removes an 'expected failure' marker from a test, showing the bug is now fixed.

This commit fixes a bug in Core Lightning's channel-funding command. If a user supplied an unsigned old-style (non-SegWit) bitcoin input when completing a channel open, the software would compute a transaction ID that could change later when the user actually signed and broadcast the transaction. The node would then wait forever for a funding transaction it would never recognize, leaving the channel opening process stuck. The fix rejects such inputs up front with a clear error message.

This commit removes a broken build-time check that tried to detect whether the Python 'mako' template library was installed. The test was failing everywhere because it needed to run under a newer Python environment manager called 'uv'. The change simply deletes the non-working detection and makes the related tool tests always run instead of being skipped. There is no security issue here.

This commit only adds a new 32-bit cross-compilation job to the project's GitHub Actions CI workflow. It does not change any application code, cryptographic logic, network handling, or user-facing behavior. There is no security issue in this change.

This commit changes the build configuration script so that Python version and pytest checks are run inside a 'uv run' environment. The author says the old checks were 'misleading' because they could report results from a Python/pytest installation that is not the one actually used by the project. There is no security fix here—just making the build setup more accurate.

This commit changes the build system so that compiler warnings no longer stop the build by default. It only enforces that strict rule ('-Werror') for debug builds and for developers/CI. This is a build-configuration change, not a fix for a software vulnerability.

This commit only adds a new test case that demonstrates a known bug in Core Lightning's wallet handling. When a `withdraw` command fails because the Bitcoin node rejects the transaction broadcast (for example, the fee is too low), some funds can remain marked as 'reserved' even though they were never actually spent. The test documents the bug and includes a manual workaround using `unreserveinputs`. It does not fix the underlying issue, so user funds can appear stuck until manually unreserved.

This change only adjusts a test that measures network timing behavior. It makes the test more flexible so it passes on macOS, where a particular network delay (called Nagle delay) is shorter than on Linux. There is no change to the actual Core Lightning software that users run, and no security issue is present.

This commit removes a single blank line containing trailing whitespace from a test file. It is a cosmetic lint cleanup with no functional or security relevance.

This is a routine weekly update to the Rust dependency lock file (Cargo.lock). It bumps several third-party library versions, including the TLS/encryption library rustls, the HTTP client reqwest, and some Java/Windows helper crates. The commit message gives no security reason for the update, and no verified security advisory was supplied. Dependency updates can in principle fix security bugs, but this diff alone does not show any specific vulnerability being patched or any change to Core Lightning's own code.

This commit is a routine version-bump housekeeping change. It updates release dates in the pull-request template, shifts the previous/next release version numbers in the Makefile and CI configuration, and replaces one internal test flag with a newer equivalent. There is nothing here that fixes, introduces, or discusses a security issue.

This commit is a housekeeping change to two patch files used when regenerating Lightning protocol wire definitions. It merges two separate patches into one and updates the generated diff context so that running `make extract-bolt-csv` produces no unexpected changes. There is no runtime code change, no bug fix, and no security-relevant behavior described.

This commit updates Core Lightning to follow a newer version of the BOLT (Basis of Lightning Technology) specification. The change makes the `channel_type` field mandatory during channel opening, but the code already required it in practice. The patch is mostly textual: it updates comments, error messages, and the reference BOLT version. There is no evidence of a security vulnerability being fixed.

This commit updates Core Lightning's implementation of the Lightning protocol 'splicing' feature to match a newer version of the BOLT specifications. It changes how nodes re-send commitment signatures after reconnecting during a splice operation. The code includes an explicit 'FIXME' note indicating the new 'retransmit_flags' field is not yet fully handled, meaning the update is partial and still under review.

This commit tightens how Core Lightning decodes bech32 strings—the format used for things like Bitcoin addresses and BOLT 12 offers. Previously, extra padding bits at the end of a bech32 string were silently thrown away, even if they were non-zero or unnecessarily long. Now the decoder rejects those cases. The change is driven by a new BOLT test vector that requires stricter decoding, and it could prevent subtle malleability or parsing-confusion issues where two different-looking bech32 strings decode to the same data.

This commit tightens validation of BOLT12 payment offers by rejecting any offer whose amount is set to zero. Previously, Core Lightning accepted zero-amount offers, which could let a malicious or misconfigured party create an offer that looks valid but requests no payment. The change also updates the embedded BOLT specification reference and adds tests so the new rule is enforced consistently across normal decoding and the developer command-line tool.

This commit updates Core Lightning to recognize a new Lightning protocol feature bit called 'channel_type' as defined in the latest BOLT specification. It does not change any active behavior or fix a bug; it simply adds support for advertising this feature in the right places so future channel negotiations can use it. There is no security issue here.

This commit changes how long Core Lightning nodes remember closed Lightning channels in their network map. The delay is increased from 12 blocks to 72 blocks after the funding output is spent, matching an update to the BOLT protocol specification. This is a protocol-compliance and robustness change, not a fix for an active security vulnerability. The main effect is that nodes keep stale channel information longer, which can slightly delay routing around dead channels but also gives more protection against blockchain reorganizations.

This commit tightens validation of a special kind of Lightning payment request called a BOLT12 offer. Previously, the software treated an offer that explicitly listed zero supported blockchains the same as one that didn't list any at all. The updated specification says such an empty list is invalid, so the code now rejects it. The commit message notes this is mostly a formality because the node couldn't actually pay these offers anyway, but it fixes a spec-compliance edge case and a test-vector mismatch.