Core Lightning

This is a one-line code generator fix in Core Lightning's wire protocol tooling. Previously, when a variable-length array field (common in newer Lightning protocol messages like BOLT 12) had zero elements, the generated code set the pointer to NULL. Now it always allocates an empty array. This corrects behavior where an empty-but-present list could be mistaken for a missing list, which could cause protocol compliance failures or logic errors in BOLT 12 features.

This commit simply adds a missing CI (continuous integration) check back into the project's Makefile. The check verifies that quotes from the BOLT specification are still accurate in the source code. It is a build/process fix with no security relevance to running Lightning nodes.

This change removes a deprecated option that let Core Lightning's xpay plugin split BOLT12 invoice payments into multiple parts even when the invoice did not explicitly allow it. Going forward, xpay will respect the invoice's feature flags and avoid multi-part payments unless permitted. The commit notes this behavior actually changed by default in the previous release without anyone noticing, and this patch cleans up the leftover override and deprecation.

This commit adds a new automated CI check that ensures wire protocol CSV files and their associated patches stay in sync with the official BOLT specifications. It does not change any runtime code, protocol handling, or user-facing behavior. It is purely a build/validation improvement to catch manual edits that should instead go through patch files.

This commit updates the version of the Lightning BOLT specification used by Core Lightning and adds a test case for a new BOLT #11 example that includes a Taproot (P2TR) fallback address. It does not change production code behavior; it only adds test coverage for parsing a Taproot fallback in a BOLT11 invoice. There is no direct security vulnerability visible in the diff.

This commit only updates comments, documentation strings, and the order of wire protocol definitions to match a newer version of the Lightning specification (BOLTs). No actual program logic, checks, or behavior were changed. It is not a security fix.

This commit changes how Core Lightning advertises support for two Lightning network features: 'payment_secret' and 'option_channel_type'. Previously these were actively announced as supported; now the code treats them as assumed to be supported by all modern nodes. The commit message notes a caveat: payment secrets still won't be present in 'keysend' payments, which don't use them. This is a protocol-level behavior change, not a fix for an active vulnerability, and the commit itself does not describe any security issue.

This commit only updates the project's internal documentation checklist used after making a software release. It adds instructions for updating version numbers, test files, compatibility tools, and how to remove old deprecated features. There is no code change and no security issue.

This commit is routine release bookkeeping. It adds a new version marker (v26.04) to the downgrade tool and a comment in the database migration list so that users who later downgrade from v26.04 to an earlier release have the correct metadata. There is no bug fix, behavior change, or security-sensitive code change.

This commit is a trivial documentation-only fix in a source code comment. It adds a missing comment-closing marker so that a block of text describing protocol feature bits is properly formatted. No executable code, logic, or behavior was changed.

This commit is a documentation and code-comment cleanup. It splits BOLT (Bitcoin Lightning specification) quote comments so a new internal tool can check them more accurately, and removes a few stray leading ellipses from comments. There is no change to actual program logic, network behavior, or security-sensitive code.

This commit only updates code comments that quote the BOLT (Basis of Lightning Technology) specification. No program logic, behavior, or security checks were changed. It is a documentation/comment cleanup with no security relevance.

This commit only updates documentation-style comments and test fixture strings to match the current BOLT #11 specification. It changes how a specification quote is split across comment blocks and updates hard-coded Bech32 invoice strings in unit tests to reflect corrected examples. There is no code behavior change and no security relevance.

This commit adds a brand-new Python developer tool that checks whether comments in the source code accurately quote the BOLT (Bitcoin Lightning) protocol specification documents. It does not change any runtime code, network handling, cryptography, or wallet logic. There is no security issue visible in this commit.

This commit updates an internal developer tool (check_quotes.py) that verifies whether comments in the source code accurately quote the BOLT specification. The changes add a keep-going option, improve wildcard matching, and handle single-line comment markers. There is no runtime Lightning node code changed, no user-facing behavior, and no security issue present in the commit itself.

This commit replaces an internal developer tool used to check that source-code comments accurately quote the Lightning BOLT specifications. The old tool only handled C files; the new Python tool also checks Rust and Python files. It is a build/development tooling change with no runtime security impact.

This is a small code cleanup in the onion routing (sphinx) code. It removes an unused internal key container and adds explanatory quotes from the BOLT specification. There is no functional change to how packets are encrypted or verified, and no security bug is fixed.

This change fixes a privacy weakness in how Core Lightning processes returned error messages from the Lightning network routing protocol. Previously, the software stopped decrypting as soon as it found the error's origin, which could let a malicious routing node figure out its position in the payment path by measuring how quickly the sender reacted. The patch now always performs 27 decryption rounds and uses dummy keys after the real origin is found, following the BOLT 4 specification's 'paranoid' advice to make the process take the same amount of time regardless of where the failure occurred.

This commit fixes a protocol compliance bug in Core Lightning. When a payment failed and the node sent back an error message, it could attach a 'channel_update' for a different channel than the one the sender had asked to use. The fix makes sure the attached update matches the requested channel, and omits it if not. This mainly prevents routing confusion and fingerprinting rather than direct theft of funds.

This commit only rewords C code comments to avoid confusing an internal Python tool that checks documentation quotes. No program behavior, network protocol handling, or security logic is changed. It is a code-comment cleanup with no security relevance.

This commit adds two developer-only tools that track whether the project's source-code comments correctly quote the BOLT (Bitcoin Lightning specification) documents. It does not change any network, wallet, or consensus code, and it introduces no security-relevant behavior in the running node.

This change fixes Core Lightning's gossip daemon so that it silently ignores Lightning network gossip messages meant for other blockchains, instead of reacting to them (previously it may have sent warning messages or processed them inappropriately). This aligns the code with the protocol specification and reduces unnecessary or risky behavior when receiving cross-chain gossip.

This commit only adds a new Makefile target that reports which sections of the Bitcoin Lightning specification (BOLTs) are not yet quoted or covered by the codebase. It does not change any running code, network behavior, or security logic, so it has no direct security impact.

This change tightens how Core Lightning handles network addresses it receives from other nodes. Previously, the code would accept an address even if its port number was 0. The patch now treats port 0 as a signal to ignore the address, matching the Lightning protocol specification (BOLT 7). It also improves error reporting so callers can tell the difference between a malformed address, an unknown address type, and an address that should simply be skipped. The main risk is that a peer could announce a useless port-0 address and, before this fix, the node might have tried to use it in ways that caused confusion or minor failures.

This commit only updates a single test file to match a recent change in the public Lightning Network specification (BOLT #7). The default minimum final CLTV expiry delta was changed from 9 to 18 blocks, so the test's expected numbers, comments, and quotes from the spec were adjusted accordingly. There is no change to production code, no bug fix, and no security issue.