Modular C implementation of the Lightning Network protocol and node stack.
Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Aug 5 → Feb 61049 seen37 candidatesCompleteFeb 6 → Jun 6579 seen10 candidatesCompleteJun 6 → Jul 678 seen1 candidatesCompleteJul 6 → Aug 5147 seen16 candidatesCompleteMessage quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
Public Git author strings; identities are not independently verified.
Last scanned 4 minutes ago
This commit simply adds a new person's PGP public-key fingerprint to the list of trusted release signers in two documentation files. It does not change any code, fix any bug, or alter any security behavior of the software itself.
41278b4eby jaonoctus+2−02 filesThis is a tiny internal fix to make a bookkeeping migration produce stable event ordering. It changes the timestamp used when creating historical 'deposit' records during a one-time database migration, so the records sort consistently with…
498e5086by daywalker90+2−01 fileThis commit is a documentation-only cleanup of the JSON-RPC command help files. It corrects which numeric error codes are listed for each command so the published schemas match what the software actually returns. No program logic, validati…
d1b6963bby daywalker90+204−1224 filesThis commit fixes a bug where a setting that controls whether unexpected transaction signatures are allowed was not initialized when the channel daemon starts. If a peer sent such signatures before the channel was fully ready, the program …
c09c4520by Erick Cestari+1−01 fileThis commit fixes the project's internal nightly code-coverage CI workflow. It changes how test coverage files are collected, ensures the same LLVM compiler version is used to generate and merge coverage data, and uploads a Codecov-compati…
5685c9a3by cdecker+12−211 fileThis commit is a large cleanup of Core Lightning's API schemas, generated RPC bindings, and related plugin code. The stated goal is to make the documented 'required' fields match what the C code actually always produces or expects. In prac…
ddbd2963by daywalker90+1786−173950 filesThis commit only updates documentation. It adds error code 313 to the documented error lists for several Core Lightning commands (fundpsbt, utxopsbt, txprepare, multiwithdraw, and upgradewallet). The error code already existed in the code …
a34b9758by Peter Neuroth+30−86 filesThis commit fixes a release-script check that verifies the cryptographic signature on a file of checksums. Previously, the script only told GPG to verify the signature file itself. If someone replaced that signature file with an inline-sig…
8e495707by Peter Neuroth+5−21 fileThis commit updates Core Lightning's release documentation to tell users and release managers to run gpg --verify with both the signature file and the manifest file named explicitly. The old one-argument form can silently succeed even if t…
2dee8699by Peter Neuroth+9−62 filesThis commit is a routine update to the Rust dependency lock file (Cargo.lock), bumping many third-party libraries to newer patch or minor versions. The commit message gives no security reason for the update, and no verified references link…
c1551c55by daywalker90+298−2761 fileThis commit fixes a stack-overflow risk in Core Lightning's JSON parser. Before the fix, an attacker could send a valid JSON-RPC message containing thousands of nested brackets or braces. The parser's own helper functions used recursion fo…
83f92e4bby Níckolas Goline+90−22 filesThis commit only fixes typos and comment style. It changes two C-style comments from // to /* */ and corrects a grammar error in a documentation comment ('element' to 'elements'). There are no code behavior changes, no bug fixes, and no se…
273d7f02by w3lld1+3−32 filesThis change fixes a test-infrastructure bug in Core Lightning's Python testing helpers. When running tests against a PostgreSQL database, very long test names could be silently shortened by PostgreSQL, causing different test runs or nodes …
c4fe4cbaby Peter Neuroth+59−12 filesThis fix prevents Core Lightning from trying to use freshly created bitcoins (immature coinbase rewards) as emergency funds for fee-bump transactions. Such a transaction would be invalid under Bitcoin's rules and would be rejected by the n…
34883ff7by cdecker+5−12 filesThis commit fixes a bug in Core Lightning's askrene plugin that could prevent a node from restarting. When a saved routing layer contained a node bias with a description, the plugin accidentally freed the description's memory while using i…
4681177dby Vincenzo Palazzo+2−32 filesThis commit only fixes a test case so it actually exercises the intended code path. It does not change any production code, so it cannot introduce or fix a real-world security vulnerability by itself. The test change is a reproducer for a …
0f3f67a0by Vincenzo Palazzo+3−21 fileThis commit fixes a bug in Core Lightning's experimental dual-funded channel feature. When another node tried to open a channel, Core Lightning was not checking whether the proposed transaction fees were reasonable. A peer could request a …
ba08356fby cdecker+140−04 filesThis commit adds regression tests for three related bugs where wildly wrong Bitcoin transaction feerates could enter Core Lightning. In the worst case, a malicious or broken fee source could make the node think a feerate was zero (due to a…
65bdbc47by cdecker+137−02 filesThis update fixes a crash bug in Core Lightning. When the software tried to list details of a channel opening in progress, it could crash if a stored fee rate was extremely large or zero. The crash happened because the code used an interna…
d67c4936by cdecker+72−227 filesThis commit fixes a bug where Core Lightning nodes could get stuck in a crash loop. If a node had previously stored an extremely high or zero fee rate for an in-progress channel funding operation (a 'splice' or dual-funded channel RBF), a …
f057c692by cdecker+34−01 fileExpand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
e3e08135 · Aug 13, 2025 · 1 fileLow 31splice: Sign shared output early
When doing a multi channel splice, we need to break the deadlock by signing the shared output early (even though it is not sent to the peer until later).
This change adjusts how Core Lightning handles 'splicing' (a way to resize a Lightning channel's on-chain funding). When a user splices multiple channels at the same time, the software now signs a shared piece of the transaction earlier than before, so it can build a complete signatures message for all peers. The commit describes this as fixing a deadlock, not as a security vulnerability. There is no direct evidence in the commit or supplied references that this is exploitable by an attacker.
87ae3559 · Aug 13, 2025 · 1 fileInformational 16splice: Add details to log message
Make the failure reason more clear by adding more information to the signature failure message.
This change only improves an error message shown when a splicing (channel funding update) negotiation fails because the remote peer did not send enough signatures. It adds a count of how many remote inputs need signatures and how many signature bundles were actually received. There is no code behavior change that fixes or introduces a vulnerability; it is purely a diagnostic/logging improvement.
dd1e183b · Aug 13, 2025 · 1 fileLow 43splice: Change abort rules to sent sigs
Previous behavior was to fail on abort when we have signatures in the inflight — change this behavior to fail on abort if we have sent our peer our signatures.
This commit tightens the conditions under which Core Lightning's channel daemon will abort a splice operation. Previously, the daemon treated a splice as unabortable if any signatures existed in the 'inflight' (pending) channel state. Now it only blocks abort if this specific node has actually sent its signatures to the peer. The change is one line and appears aimed at preventing a node from backing out of a splice after it has already committed to it cryptographically, which could otherwise let a malicious or buggy peer exploit inconsistent state.
a8ff8ce7 · Aug 13, 2025 · 12 filesInformational 24splice: Add field to DB to track if we’ve sent sigs
We used to use a check on the active psbt to see if our splice signature was in it — but now we need to generate the signature early.
So we have to add a field tracking if we’ve sent it and add it to the database, wire protocols, and inflight objects.
This commit adds a new bookkeeping flag, 'i_sent_sigs', to track whether a splice signature has already been sent. It changes how the node decides that question: previously it inspected the active PSBT, but now it records the fact explicitly in memory, wire messages, and the wallet database. The change is described as a refactor to support generating splice signatures earlier. There is no direct evidence in the commit of a security vulnerability, but any mismatch in this flag could in principle cause a node to send signatures twice, omit them, or resume a splice incorrectly after a restart.
2e660d9f · Aug 13, 2025 · 1 fileLow 41splice: Fix cross-channel splices
When doing a cross channel splice, inputs move from having no SIGHASH to having SIGHASH_ALL assigned.
This causes psbt_get_changeset to flag the input as having changed, as the sighash value is compared.
This causes the second channel splice to `tx_remove_input` the input as it doesn’t match anymore, breaking the splice.
We fix this by removing the sighash value from input comparisions.
This commit fixes a bug in Core Lightning's splicing feature where a transaction input could be incorrectly removed during a 'cross-channel splice' because the software compared a newly-added signature hash flag. The fix tells the comparison logic to ignore the signature-hash value so the input is not treated as changed and wrongly dropped. It is a functional bug fix rather than an obvious security vulnerability, but it could cause a splice to fail or funds to be handled incorrectly.
a5a71f3b · Aug 13, 2025 · 1 fileLow 32psbt: don’t accumlate 0 lenth widtness data
Why it was queuedThis commit fixes a small bug in how Core Lightning builds Bitcoin witness data from a PSBT. Previously, when a witness item had a declared length of zero, the code would still try to copy data from a pointer that could be NULL. The fix skips the copy when the length is zero and adds an assertion that the pointer is valid when length is non-zero. This is a defensive correctness fix; it likely prevents a potential NULL-pointer read or undefined behavior rather than an obvious remote exploit.
122dae10 · Aug 13, 2025 · 1 fileModerate 52splice: Even if the psbt’s “match” the sig data may vary
Since the signature data may vary, we must copy the new psbt into splicing->current_psbt.
This never occured during normal operation, but when doing a cross splice there may be vital signature(s) in the psbt that came from another splice that get dropped without this step.
This change fixes a bug in Core Lightning's channel-splicing code. During a splice, two versions of a Bitcoin transaction structure (a PSBT) might look identical in their main transaction data but differ in their attached signatures. Previously, the code would skip copying the new PSBT if the main transaction hadn't changed, which could discard signatures from a related splice. The fix always copies the latest PSBT so signatures are preserved. The commit describes this as a bug that could affect 'cross splice' scenarios, but it does not label it as a security vulnerability.
d5c73185 · Aug 13, 2025 · 1 fileInformational 18plugin: Allow json_object and json_group_array functions in sql plugin
Changelog-Added: Plugins: `sql` also supports functions `json_object(key1, value1, ...)` to construct JSON objects and `json_group_array(value)` to aggregate rows into JSON array.
Security Considerations
- No new SQL injection risks: Functions only process explicitly provided column values (no arbitrary string parsing).
- Explicit column requirements: Wildcards (*) are not supported, all fields must be named (e.g., json_object('peer_id', id)).
- Permission-bound data access: Functions adhere to the same table/row permissions as the underlying query.
Performance Impact
- Optimized native execution: Leverages SQLite’s built-in JSON1 extension (when available) for efficiency.
- Moderate CPU overhead: Complex nesting may impact performance on large datasets but still faster than application-layer JSON conversion.
This commit adds two SQLite JSON helper functions, json_object and json_group_array, to the list of functions allowed by Core Lightning's SQL plugin. The change is a small whitelist expansion in the plugin's query authorization code. The commit message explicitly states this does not introduce new SQL injection risks and that the functions follow existing table and row permissions. There is no direct evidence in the commit of a security vulnerability.
e051ba6b · Aug 11, 2025 · 3 filesInformational 15sqlite3: consistently comment where we want to upgrade.
Now you can grep for 'sqlite3 version' and see where we would like
to update.
Debian 11 (Bullseye) and Ubuntu 20.04 (Focal) ship with SQLite 3.31.1.
RHEL 9 ships with 3.34.1. Fedora 38+ uses SQLite 3.40+.
Unfortunately, RHEL8 ships with 3.26.0, and is still on maintenance Support
(security fixes, no new features): runs until May 31, 2029.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only adds and rewords comments in the source code to make it easier to find places where the project would like to require a newer SQLite version in the future. It does not change any actual behavior, fix any bug, or alter any security-related logic.