EP
← All projectsElements Project

Core Lightning

Modular C implementation of the Lightning Network protocol and node stack.

BitcoinLightning NetworkNormal
Repository coverage

1853 commits in the local evidence base

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.

158security candidates263second-pass queue137AI analyses
147commits · 30 days
225commits · 60 days
803commits · 180 days
1853commits · 365 days
Backfill bands
Aug 5 → Feb 61049 seen37 candidatesComplete
Feb 6 → Jun 6579 seen10 candidatesComplete
Jun 6 → Jul 678 seen1 candidatesComplete
Jul 6 → Aug 5147 seen16 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

70/100 average clarity
430Strong · 80–100
1163Adequate · 60–79
231Thin · 40–59
29Opaque · 0–39
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Rusty Russell9587363072
Sangbida Chaudhuri1463129066
Dusty Daemon771310066
ShahanaFarooqui931010063
daywalker908953062
Níckolas Goline4054076
Lagrang37642069
Christian Decker3643072
Vincenzo Palazzo833080
Chandra Pratap5622082
ekzyis222063
Peter Neuroth9711070
Analysis record

Published AI watches

Last scanned 21 minutes ago

Informational 23 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

downgrade: we need to remove "impressions" from askrene datastore when downgrading to v26.06.

This is a database downgrade helper fix, not a live network vulnerability. Core Lightning's downgrade tool previously failed to strip out new 'channel impression' records when rolling a database back to version v26.06. The patch teaches th…

Database downgrade path could leave incompatible records in older schemaOffline tool only; no remote or on-chain triggerFix prevents potential node startup failure after version rollback
4d926285by Rusty Russell+43−111 file
No security note in commit
Low 31 AI analysisMessage 68 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

downgrade tool: fix invalid memory bug

This commit fixes a typo in a database downgrade helper tool. The bug caused the tool to pass a negative number (turned into a huge positive size) when copying data, which led to an out-of-memory (OOM) error. The fix swaps two variable nam…

Integer underflow / negative-to-size_t wrap leading to excessive allocationOut-of-memory crash in maintenance toolMemory corruption potential if allocation somehow succeeded
42995326by Lagrang3+8−81 file
No security note in commit
Informational 16 AI analysisMessage 90 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

add a test for downgrading askrene datastore

This commit adds a regression test for Core Lightning's database downgrade path. It ensures that when a user downgrades from an upcoming v26.09 release to an older version (v26.06), the new 'impressions' data added by the askrene routing s…

Database downgrade path for new askrene schema (impressions table)Regression test only; no production code changeNo input validation, cryptography, network, or authorization changes
1818553eby Lagrang3+156−13 files
No security note in commit
Low 25 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

lightning-hsmtool: Fix getsecret does not show mnemonic after typing passphrase

This is a bug fix in a command-line helper tool used by Core Lightning node operators. The `getsecret` command was accidentally refusing to show the wallet recovery words (mnemonic) when the wallet was protected by a passphrase. After the …

Functional bug in secret-recovery pathError path blocked legitimate mnemonic recoveryNo input validation, memory-safety, or cryptographic change
8480f6c2by ekzyis+1−21 file
No security note in commit
Informational 12 AI analysisMessage 60 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

tests: add regression test for hsmtool commands with passphrase

This commit only adds and updates a regression test in the project's test suite. It checks that the hsmtool utility correctly handles both empty and non-empty passphrases when working with BIP39 mnemonic-based wallet secrets. There is no c…

Regression test added for passphrase handling in hsmtoolNo production code changes observedTest-only change to tests/test_wallet.py
8c42be35by ekzyis+47−201 file
No security note in commit
Low 33 AI analysisMessage 76 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wally: update libwally to v1.5.6

This commit updates the bundled libwally library to version 1.5.6. The practical effect is that calling the JSON-RPC `signpsbt` command on a PSBT that is already signed now succeeds as a harmless no-op, instead of returning an error on Bit…

Dependency update to incorporate upstream bug fixBehavior change from error to no-op on re-signing signed PSBTsTaproot keypath handling change in upstream cryptographic library
37526ca4by daywalker90+7−82 files
No security note in commit
Informational 15 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: rename b32script to scriptpubkey in PSBT change paths

This commit is a simple variable rename inside a Bitcoin/Lightning wallet file. The old name 'b32script' suggested all change addresses were bech32 format, but the project now uses a newer address type (p2tr) by default. The developer rena…

b8a60579by Sangbida Chaudhuri+12−141 file
No security note in commit
Low 44 AI analysisMessage 78 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: register scriptpubkey watches at startup

This change makes Core Lightning register long-lasting 'watches' for all wallet deposit addresses when the node starts up, so the new bwatch plugin can spot incoming payments from the first block it scans. It also removes a now-redundant p…

Change is part of an experimental chain-watcher (bwatch) featureAdds startup registration of scriptPubKey watches for all derived wallet keysRemoves a redundant unconfirmed-change watch, relying on the new blanket coverage
4a951d65by Sangbida Chaudhuri+89−114 files
No security note in commit
Low 29 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: dual-write chaintopology UTXO changes into our_outputs

This is a database refactoring commit in Core Lightning. It makes the wallet write UTXO (unspent transaction output) state to a new table called our_outputs in addition to the legacy outputs table, while reads still use the old table. The …

Database schema migration with dual-write mirror patternNo security claim in commit title or messageNo CVE, advisory, or researcher attribution in commit metadata
824e8195by Sangbida Chaudhuri+118−162 files
No security note in commit
Low 32 AI analysisMessage 68 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: record bwatch-discovered wallet outputs

This commit adds new wallet bookkeeping code for Core Lightning. It records Bitcoin deposits found by a new chain-watcher ('bwatch') into database tables and handles blockchain reorganizations by demoting transactions back to unconfirmed r…

New database write paths for wallet UTXOs and transactionsReorg revert logic demotes rather than deletes rows to preserve metadataOwner-string constructors added to avoid silent unwatch failures from format mismatches
bc021011by Sangbida Chaudhuri+543−07 files
No security note in commit
Informational 18 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: add our_outputs + our_txs schema migrations

This commit only adds two new empty database tables (our_outputs and our_txs) to Core Lightning's wallet. It is a preparatory schema change for a future feature; no code reads from or writes to these tables yet, and no existing behavior is…

Schema-only migration with no runtime codeNew tables are not yet populated or queried by any code pathDesign note: sentinel 0 replaces NULL for blockheight/txindex/reserved_til, which could reduce NULL-handling bugs in future code
ea4d1fcaby Sangbida Chaudhuri+38−01 file
No security note in commit
Low 28 AI analysisMessage 70 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: add migrate_backfill_bwatch_tables

This commit adds a database migration that copies existing wallet data into new tables used by an upcoming 'bwatch' wallet component. It is a data backfill, not a code fix for an active vulnerability. The main risk is that if the migration…

Database migration touching wallet UTXO and transaction tablesPotential for data inconsistency if mapping logic is wrongON CONFLICT DO NOTHING prevents overwrite but could hide duplicate-key anomalies
2e23893bby Sangbida Chaudhuri+513−04 files
No security note in commit
Low 27 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: mirror bwatch writes into legacy outputs table

This change is a behind-the-scenes bookkeeping patch for Core Lightning's wallet database. The project is moving to a new table (`our_outputs`) for tracking spendable coins, but older versions of the software still read from the old table …

Race-condition guard for foreign-key-backed confirmation_height and spend_height when bwatch is ahead of chaintopologyTemporary mirroring to keep legacy outputs table consistent with new our_outputs tableON CONFLICT DO NOTHING used for legacy insert to avoid duplicate-key failures
bba68e0aby Sangbida Chaudhuri+101−62 files
No security note in commit
Moderate 51 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: Update the max_index cache when issuing new addresses

This commit fixes a bug where Core Lightning's in-memory record of the highest address index could fall out of step with the database. When a user generated a new on-chain address, the code updated the database directly but left the cached…

Cache/database inconsistency in address index trackingPotential for stale lower index to overwrite newer persisted indexFreshly generated addresses invisible to wallet rescan/listing until restart
d05815f5by Christian Decker+37−292 files
No security note in commit
Informational 15 AI analysisMessage 83 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: Cache the max_index for bip32 and bip86 address indices

This commit is a straightforward performance optimization. It caches two address-index values in memory instead of reading them from the database twice for every transaction output in every scanned block. The change fixes a slowdown during…

565da833by Christian Decker+15−52 files
No security note in commit
Informational 18 AI analysisMessage 90 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

common: add randbytes() wrapper to override cryptographic entropy: $CLN_DEV_ENTROPY_SEED

This commit adds a developer-only feature that lets programmers override the randomness source used by Core Lightning during testing, via an environment variable. It is explicitly gated behind 'developer mode' and is not intended for produ…

New cryptographic-randomness override mechanism, but explicitly developer-mode onlyEnvironment-variable seeding could reduce entropy if accidentally enabled in productionNo production code changes visible in the diff
1c925e0aby Rusty Russell+29−05 files
No security note in commit
Low 37 AI analysisMessage 83 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

common: don't consume deterministic randbytes stream for trace ids

This change fixes a subtle bug in Core Lightning's tracing code. When running with a special developer-only deterministic randomness override (CLN_DEV_ENTROPY_SEED), trace IDs were being drawn from the same predictable random stream used f…

Deterministic RNG stream contamination by observability codeTransaction output divergence between instrumented and non-instrumented buildsDeveloper-only entropy override affecting reproducibility of transaction generation
23b4b38aby ShahanaFarooqui+18−31 file
No security note in commit
Informational 19 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

common: don't trigger siphash_seed() init from span hashing either.

This is a small bug-fix commit in Core Lightning's tracing code. It fixes a situation where enabling tracing accidentally changed the sequence of random numbers used elsewhere in the program, causing test outputs to differ between builds w…

No direct memory safety issueNo input validation bypassNo authentication or authorization change
e54fe678by ShahanaFarooqui+6−01 file
No security note in commit
Informational 15 AI analysisMessage 70 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

autogenerate-rpc-examples.py: disable entropy for generation.

This commit changes Core Lightning's internal test tooling so that automatically generated RPC documentation examples use predictable randomness and a fixed clock time. It only affects test/example generation code, not the production Light…

81443075by Rusty Russell+14−12 files
No security note in commit
Informational 15 AI analysisMessage 50 · Thin
EP Elements ProjectCore Lightning BitcoinLightning Network

autogenerate-rpc-examples.py: pin the full sorted UTXO set for multiwithdraw examples

This commit only changes an internal test script that automatically generates example RPC commands for documentation. It makes the examples more deterministic by explicitly selecting which coins the test wallet uses, so the generated docum…

6f464e46by ShahanaFarooqui+35−81 file
No security note in commit
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

Security candidateUpdate outdated BOLT quotes common/bolt11.c: Some BOLT quotes had changed slightly. run-bolt11.c: A test was updated to reflect nomenclature changes (from `signature recovery` to `public-key recovery`).by Níckolas Goline · b0e72857 · Jun 16, 2026 · 2 filesMessage 88 · StrongInformational 15Details
Commit message · Níckolas Goline

Update outdated BOLT quotes
common/bolt11.c: Some BOLT quotes had changed slightly.
run-bolt11.c: A test was updated to reflect nomenclature changes (from `signature recovery` to `public-key recovery`).

88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit only changes wording: it renames an internal error message from 'signature recovery failed' to 'public-key recovery failed' to match updated BOLT specification terminology. No program logic, cryptography, or behavior changes.

Security candidatecargo: update dependenciesby daywalker90 · fe0c4522 · Jun 16, 2026 · 2 filesMessage 58 · ThinInformational 21Details
Commit message · daywalker90

cargo: update dependencies

cargo update output:
Updating bitflags v2.11.1 -> v2.13.0
Updating cc v1.2.63 -> v1.2.64
Updating chrono v0.4.44 -> v0.4.45
Updating h2 v0.4.14 -> v0.4.15
Updating http v1.4.1 -> v1.4.2
Updating js-sys v0.3.99 -> v0.3.102
Updating log v0.4.30 -> v0.4.32
Updating memchr v2.8.1 -> v2.8.2
Updating prost v0.14.3 -> v0.14.4
Updating prost-build v0.14.3 -> v0.14.4
Updating prost-derive v0.14.3 -> v0.14.4
Updating prost-types v0.14.3 -> v0.14.4
Updating regex v1.12.3 -> v1.12.4
Updating regex-syntax v0.8.10 -> v0.8.11
Updating rustls-native-certs v0.8.3 -> v0.8.4
Updating smallvec v1.15.1 -> v1.15.2
Updating wasm-bindgen v0.2.122 -> v0.2.125
Updating wasm-bindgen-futures v0.4.72 -> v0.4.75
Updating wasm-bindgen-macro v0.2.122 -> v0.2.125
Updating wasm-bindgen-macro-support v0.2.122 -> v0.2.125
Updating wasm-bindgen-shared v0.2.122 -> v0.2.125
Updating web-sys v0.3.99 -> v0.3.102
Updating yoke v0.8.2 -> v0.8.3
Updating zerocopy v0.8.50 -> v0.8.52
Updating zerocopy-derive v0.8.50 -> v0.8.52
Updating zeroize v1.8.2 -> v1.9.0

Also upgraded quick-xml to 0.40

Changelog-None

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Why it was queued
memory safety
AI analysis · Informational 21/100

This commit is a routine update of third-party Rust libraries used by Core Lightning's REST plugin. It bumps versions in the package lock file and raises one direct dependency (quick-xml) from 0.39 to 0.40. The commit message does not say it fixes any security bug, and no verified security advisory was supplied. Dependency updates can sometimes include security fixes, but this change alone does not demonstrate a vulnerability in Core Lightning.

Security candidatetools: Fix `sign` and `docker` target detection when passed as single argumentby ShahanaFarooqui · 19992371 · Jun 10, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · ShahanaFarooqui

tools: Fix `sign` and `docker` target detection when passed as single argument

The sign target detection uses pattern matching that requires spaces on
both sides of "sign" in the TARGETS variable. When only "sign" is passed
as an argument, TARGETS becomes " sign" (leading space only), causing
the condition to fail.

Add an additional pattern match to detect "sign" with a leading space
but no trailing space, which occurs when "sign" is the only target or
the last target in the list.

This regression seems to have been exposed by GitHub Actions runner
updates (Ubuntu 22.04 → 24.04), which changed argument passing behavior.

Changelog-None: Fixes the release signing issue in CI only.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit fixes a shell-script pattern-matching bug in the release build tool. When a maintainer ran the release script with only 'sign' or 'docker' as the target, the script failed to detect it because it expected spaces on both sides of the word. The fix adds an extra check for when the word appears at the end of the target list. It is a CI/release workflow bug, not a vulnerability in the Lightning node software itself.

Security candidatecontrib: add nGoline's signing key Changelog-Noneby Níckolas Goline · bfe5dd4f · Jun 5, 2026 · 2 filesMessage 60 · AdequateTriage 0Details
Commit message · Níckolas Goline

contrib: add nGoline's signing key
Changelog-None

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundarydocumentation-only discount
Security candidatecontrib: add daywalker90's signing keyby daywalker90 · dfc7d557 · Jun 4, 2026 · 2 filesMessage 45 · ThinTriage 0Details
Commit message · daywalker90

contrib: add daywalker90's signing key

Changelog-None

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundarydocumentation-only discount
Security candidatecontrib: add Lagrang3's signing keyby Lagrang3 · 0bdb5b0c · Jun 4, 2026 · 2 filesMessage 60 · AdequateTriage 0Details
Commit message · Lagrang3

contrib: add Lagrang3's signing key

Changelog-None

Signed-off-by: Lagrang3 <lagrang3@protonmail.com>

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundarydocumentation-only discount
Security candidateaskrene: askrene-remove-channel-updateby Lagrang3 · 902242b0 · May 11, 2026 · 15 filesMessage 68 · AdequateTriage 12Details
Commit message · Lagrang3

askrene: askrene-remove-channel-update

Changelog-Added: askrene: askrene-remove-channel-update, a new RPC to remove channel_update entries from layers.

Signed-off-by: Lagrang3 <lagrang3@protonmail.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
boot or update path
Security candidatefix: release txprepare reservations on send failureby Vincenzo Palazzo · 1c5e6329 · May 11, 2026 · 2 filesMessage 100 · StrongLow 47Details
Commit message · Vincenzo Palazzo

fix: release txprepare reservations on send failure

Clean up the original PSBT reservation when withdraw/txsend fail after signing or broadcast.

Include the final withdraw regression coverage, including the liquid-safe address handling needed for CI.

Fixes #8925

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 47/100

This commit fixes a bug in Core Lightning's wallet code where, if a prepared Bitcoin transaction failed during signing or broadcast, the coins that had been set aside ('reserved') for that transaction were not released back to the wallet. The fix makes sure those reservations are cleaned up automatically on failure, so funds are not stuck and become usable again. The change also adds tests that simulate a broadcast failure and verify the funds are no longer reserved afterward.

Security candidatecommon: expose is_signature_field as is_tlv_signature_field.by Rusty Russell · bc2411b5 · May 11, 2026 · 2 filesMessage 65 · AdequateInformational 15Details
Commit message · Rusty Russell

common: expose is_signature_field as is_tlv_signature_field.

Proof code needs this.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit simply renames an internal helper function and makes it publicly available in a header file so other parts of the codebase can use it. There is no bug fix, behavior change, or security-sensitive logic alteration. It is a routine code-organization change.

Security candidatetests: add regression tests for withdraw returning unsigned txby Vincenzo Palazzo · c000fc90 · May 9, 2026 · 1 fileMessage 100 · StrongLow 46Details
Commit message · Vincenzo Palazzo

tests: add regression tests for withdraw returning unsigned tx

Adds two tests to reproduce issue #8701 where the withdraw command
returns an unsigned raw transaction in the 'tx' response field:

1. test_withdraw_returns_signed_tx: verifies that withdraw's 'tx' field
contains witness data for all inputs (basic wallet UTXOs).

2. test_withdraw_close_output_signed: verifies signing works when
withdrawing funds that include channel close outputs (anchor/P2WSH
with CSV locks), which was the exact scenario in the reported issue.

The root cause is that psbt_txid() uses WALLY_PSBT_EXTRACT_NON_FINAL
which strips signatures/witnesses, and the withdraw response returns
this unsigned tx instead of the finalized one.

Changelog-None
Signed-off-by: Vincenzo Palazzo <vincenzopalazzo@member.fsf.org>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundaryfuzzing or regression evidencesigning or wallet path
AI analysis · Low 46/100

This commit only adds two new automated tests that demonstrate an existing bug: the 'withdraw' command returns an unsigned raw transaction in its 'tx' field because an internal helper strips away signatures. The tests are marked as expected-to-fail, so the actual code flaw is not fixed here. A user relying on the returned transaction could receive a version that looks valid but would be rejected by the Bitcoin network because it lacks required witness data. The commit documents the regression but does not change the wallet logic itself.

Security candidatetxprepare: fix withdraw returning unsigned transactionby Vincenzo Palazzo · 16cf06b4 · May 9, 2026 · 2 filesMessage 100 · StrongLow 33Details
Commit message · Vincenzo Palazzo

txprepare: fix withdraw returning unsigned transaction

The withdraw command was returning an unsigned raw transaction in
its 'tx' response field. This happened because signpsbt_done() used
psbt_txid() to extract utx->tx, which internally calls
wally_psbt_extract() with WALLY_PSBT_EXTRACT_NON_FINAL — stripping
all signature and witness data.

The broadcast itself succeeded because sendpsbt internally finalizes
the PSBT via psbt_final_tx(), but the 'tx' field returned to the
user had empty scriptSigs and no witness data.

This is a regression from 908f834d6 ("Update libwally to 0.8.8,
support PSBTv2") which rewrote psbt_txid() from manually copying
final_scriptsig/redeem_script into the cloned tx, to using
wally_psbt_extract(WALLY_PSBT_EXTRACT_NON_FINAL) which strips all
signing data by design.

Fix by finalizing the signed PSBT in signpsbt_done() and extracting
the fully signed transaction via psbt_final_tx(). The txid
verification still uses psbt_txid() (which is correct for txid
computation since txids exclude witness data).

Fixes: https://github.com/ElementsProject/lightning/issues/8701
Changelog-Fixed: withdraw now returns a fully signed transaction in the `tx` response field.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzo@member.fsf.org>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarydefensive validationsigning or wallet path
AI analysis · Low 33/100

This commit fixes a bug in Core Lightning's 'withdraw' command where the transaction shown to the user was returned without valid signatures or witness data, even though the actual network broadcast worked correctly. The returned 'tx' field looked like a real transaction but would be rejected if a user tried to broadcast it themselves. The fix ensures the returned transaction is fully signed and final.

Security candidatebitcoin/tx.c: use 330 sat dust limit for P2TR/P2WPKH change outputs Fixes #8395 Fix by checking is_elements: Elements keeps 546 sat, Bitcoin uses 330 sat. Changelog-Fixed: Transactions now correctly create change outputs >= 330 sat for P2TR/P2WPKH instead of absorbing them as feesby Andezion · fcd6671a · May 8, 2026 · 2 filesMessage 81 · StrongLow 36Details
Commit message · Andezion

bitcoin/tx.c: use 330 sat dust limit for P2TR/P2WPKH change outputs Fixes #8395
Fix by checking is_elements: Elements keeps 546 sat, Bitcoin uses 330 sat.
Changelog-Fixed: Transactions now correctly create change outputs >= 330 sat for P2TR/P2WPKH instead of absorbing them as fees

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundary
AI analysis · Low 36/100

This commit fixes a bug in Core Lightning where small change outputs on Bitcoin were being treated as too tiny to keep, causing them to be silently added to transaction fees instead of returned to the user. The fix lowers the threshold for P2TR/P2WPKH change outputs on Bitcoin from 546 satoshis to 330 satoshis, matching current Bitcoin network rules. Elements/Liquid still uses 546. Users could previously lose small change amounts as extra fees.

Security candidateopening: reject fundchannel_complete with unsigned non-segwit inputsby wqxoxo · 508ce922 · May 7, 2026 · 2 filesMessage 73 · AdequateLow 49Details
Commit message · wqxoxo

opening: reject fundchannel_complete with unsigned non-segwit inputs

We can't know the txid of an unsigned PSBT with non-segwit (legacy
P2PKH/P2SH) inputs. wally_psbt_extract() fills in an empty scriptSig
for unsigned inputs, giving a txid that changes once the user signs
and broadcasts. openingd then waits forever for a tx it will never see.

Changelog-Fixed: fundchannel_complete: reject PSBTs with unsigned non-segwit inputs (txid is indeterminate until signed).

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundary
AI analysis · Low 49/100

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.

Security candidatewire: add shim patch for when we regenerate.by Rusty Russell · bcf4d72f · Apr 30, 2026 · 2 filesMessage 68 · AdequateTriage 12Details
Commit message · Rusty Russell

wire: add shim patch for when we regenerate.

The current BOLTVERSION doesn't match our implementation, so when we
`make extract-bolt-csv` we get a change.

Fold the changes into a single splice patch.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
boot or update path
Security candidatelightning-downgrade: prepare for downgrading to v26.04.by Rusty Russell · cc8c043f · Apr 30, 2026 · 2 filesMessage 65 · AdequateInformational 15Details
Commit message · Rusty Russell

lightning-downgrade: prepare for downgrading to v26.04.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
update trustsigning or wallet path
AI analysis · Informational 15/100

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.

Security candidatecommon: follow BOLT 4 requirements to make decryption constant time.by Rusty Russell · d5508e1e · Apr 30, 2026 · 1 fileMessage 73 · AdequateModerate 67Details
Commit message · Rusty Russell

common: follow BOLT 4 requirements to make decryption constant time.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Protocol: use BOLT4's paranoid advice about doing constant-time error decryption.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
constant-time or timing behavior
AI analysis · Moderate 67/100

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.

Security candidateBOLT quotes: split cross-section quotes; prepare for new `...` semantics.by Rusty Russell · 07d1db00 · Apr 30, 2026 · 11 filesMessage 83 · StrongInformational 15Details
Commit message · Rusty Russell

BOLT quotes: split cross-section quotes; prepare for new `...` semantics.

The new check_quotes.py tool will treat `...` at the start of a quote as
"immediately follows previous quote in BOLT text". To prepare for that,
we change existing quotes which used leading `...` to mean "skip some
text": split them into two consecutive BOLT comments (the second starting
with `...` to use the existing wildcard match), and add explicit `*...`
markers between consecutive BOLT test vector sections which cross `# From`
headers.

Also remove leading `...` from nonce quotes in cryptomsg.c/handshake.c
where the actual BOLT text starts a fresh sentence (no prior quote in file).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
sCo-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidencecryptography-sensitive path
AI analysis · Informational 15/100

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.

Security candidateUpdate outdated BOLT quotes in channel open/close handling.by Rusty Russell · 39ac3f14 · Apr 30, 2026 · 4 filesMessage 86 · StrongInformational 18Details
Commit message · Rusty Russell

Update outdated BOLT quotes in channel open/close handling.

Some of these are malformed (thus were unchecked!), some are from the
stricter interpretation of `...` which won't cross section boundaries.

Several BOLT quotes had drifted from the current spec text:
- connectd/queries.c: BOLT #7 uses 'full_information' not 'complete';
remove a second quote that referenced query_channel_range but was
actually wrong (that requirement is for query_short_channel_ids).
- lightningd/dual_open_control.c: channel reserve is 1% rounded down
(not just 1%); witness weight check now says SHOULD broadcast rather
than MUST fail; RBF quotes simplified to match actual BOLT wording.
- openingd/openingd.c: 'The sending node' became 'The sender';
invalid signature response now says MUST send warning/error not just
MUST fail the channel.
- openingd/dualopend.c: same invalid-signature quote as openingd.c.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

86/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 18/100

This commit updates code comments that quote the Lightning Network specification (BOLT) in four files. Most changes are cosmetic: fixing outdated wording, malformed quote markers, and removing one incorrect quote. One change in connectd/queries.c removes a stale BOLT requirement comment but does not alter the actual behavior, which already replies with sync_complete=false for an unknown chain. Another change in dual_open_control.c updates a comment about what to do when a transaction's effective feerate is too low, but the surrounding code still calls a failure path. Overall, the commit is primarily documentation cleanup and does not appear to introduce or fix a security vulnerability on its own.

Security candidatepytest: fix flake in test_closing_anchorspend_htlc_tx_rbfby Níckolas Goline · 26b162dc · Apr 27, 2026 · 1 fileMessage 96 · StrongInformational 15Details
Commit message · Níckolas Goline

pytest: fix flake in test_closing_anchorspend_htlc_tx_rbf

Fixes: #9088

```
FAILED tests/test_closing.py::test_closing_anchorspend_htlc_tx_rbf - assert (None or 3001.3083296990844 < (3000 + 1))
+ where None = did_short_sig(<fixtures.LightningNode object at 0x7f1a89bb9c90>)
```

The previous fix #9027 misdiagnosed the cause: the identical value
3001.3083296990844 appears with and without a short signature, so this
is not signature-length variation but deterministic floating-point
rounding in `fees / weight * 1000` for this specific transaction
structure. Replace the hand-rolled ±1 assertions with check_feerate(),
which already uses a ±2 window and has the did_short_sig escape hatch
built in.

Changelog-None

96/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit fixes a flaky automated test in Core Lightning. The test was occasionally failing because of tiny floating-point rounding differences when calculating transaction fees, not because of a real bug or security issue. The change replaces a strict hand-rolled tolerance check with a more forgiving helper function already designed for this purpose. There is no security impact.

Security candidateconnectd: rescue constant message size feature by exploiting OPT_ONION_MESSAGES (LND)by Rusty Russell · 52b70043 · Apr 10, 2026 · 1 fileMessage 65 · AdequateLow 34Details
Commit message · Rusty Russell

connectd: rescue constant message size feature by exploiting OPT_ONION_MESSAGES (LND)

I 🧡 Laolu!

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
explicit security language
AI analysis · Low 34/100

This change adjusts when Core Lightning pads its network messages to a constant size. Previously padding was controlled by a developer/testing flag. Now it is enabled only when the connected peer advertises support for 'onion messages' (a newer Lightning feature). The commit message says this works around a bug in LND (another Lightning implementation) where LND would disconnect if it received certain padded 'ping' messages. The fix uses onion-message support as a signal that the remote LND version is new enough to tolerate the padding. There is no direct evidence in the diff of a security vulnerability; it reads as a compatibility/interoperability fix that incidentally preserves a privacy feature (uniform packet sizes).

Security candidateconnectd: rescue constant message size feature by exploiting option 154 (Eclair).by Rusty Russell · a65c6975 · Apr 10, 2026 · 1 fileMessage 65 · AdequateLow 35Details
Commit message · Rusty Russell

connectd: rescue constant message size feature by exploiting option 154 (Eclair).

I 🧡 tbast!

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
explicit security language
AI analysis · Low 35/100

This commit adjusts when Core Lightning pads ping messages to keep packet sizes uniform. It now skips padding when talking to Eclair nodes that advertise feature bit 154, because Eclair had a similar bug where it did not reply to certain padded pings, which could cause connection problems. The change is a compatibility workaround, not a direct fix for a vulnerability in Core Lightning itself.

Security candidatesplice: Remove experiemental splicing featureby daywalker90 · 3a17da61 · Apr 9, 2026 · 29 filesMessage 45 · ThinInformational 15Details
Commit message · daywalker90

splice: Remove experiemental splicing feature

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathboot or update path
AI analysis · Informational 15/100

This commit removes the experimental flag that previously had to be enabled for splicing, making splicing a default feature. It is a feature-promotion and cleanup change, not a security fix. There are no code changes that patch a vulnerability, no mention of a CVE, and no security advisory.

Security candidatepytest: fix flake in test_easy_splice_out_into_channelby Rusty Russell · 3e878280 · Apr 2, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Rusty Russell

pytest: fix flake in test_easy_splice_out_into_channel

```
2026-04-01T07:56:01.0560642Z > assert 'inflight' not in p1
2026-04-01T07:56:01.0581633Z E AssertionError: assert 'inflight' not in {'peer_id': '033845802d25b4e074ccfd7cd8b339a41dc75bf9978a034800444b51d42b07799a', 'peer_connected': True, 'reestablished': True, 'channel_type': {'bits': [12, 22], 'names': ['static_remotekey/even', 'anchors/even']}, 'updates': {'local': {'htlc_minimum_msat': 0, 'htlc_maximum_msat': 990000000, 'cltv_expiry_delta': 6, 'fee_base_msat': 1, 'fee_proportional_millionths': 10}, 'remote': {'htlc_minimum_msat': 0, 'htlc_maximum_msat': 990000000, 'cltv_expiry_delta': 6, 'fee_base_msat': 1, 'fee_proportional_millionths': 10}}, 'state': 'CHANNELD_AWAITING_SPLICE', 'scratch_txid': 'bf969125a0929605ba1e007912173fbf55cc67e19963e6d87a66066b7d764d9d', 'last_tx_fee_msat': 4545000, 'lost_state': False, 'feerate': {'perkw': 3750, 'perkb': 15000}, 'owner': 'channeld', 'short_channel_id': '103x2x0', 'direction': 1, 'channel_id': '68c2b5982e67b7dbd42d310e2dd481831c5add0d6a541fec6e26d000fd0ea0f4', 'funding_txid': 'f4a00efd00d0266eec1f546a0ddd5a1c8381d42d0e312dd4dbb7672e98b5c268', 'funding_outnum': 0, 'initial_feerate': '939perkw', 'last_feerate': '939perkw', 'next_feerate': '978perkw', 'inflight': [{'funding_txid': '88f913adf41749a106c97cea7a6f6e448efa73fc6bc9325b78802188d8b0b67d', 'funding_outnum': 1, 'feerate': '939perkw', 'total_funding_msat': 1100000000, 'our_funding_msat': 1000000000, 'splice_amount': 0, 'scratch_txid': '1076f7048d0c1debb7bf2e1d448b3f1345a6973e24dc6a2fadade67ef75133aa'}], 'close_to_addr': 'bcrt1p9r2qj40kfad955p2arkd70lpyh0epugjljrm2djh6483kqffg04q9fufhw', 'close_to': '512028d40955f64f5a5a502ae8ecdf3fe125df90f112fc87b53657d54f1b012943ea', 'private': False, 'opener': 'local', 'alias': {'local': '7654047x8069664x16198', 'remote': '14528636x6434403x24187'}, 'features': ['option_static_remotekey', 'option_anchors'], 'funding': {'local_funds_msat': 1000000000, 'remote_funds_msat': 0, 'pushed_msat': 0, 'psbt': 'cHNidP8BAgQCAAAAAQMEZgAAAAEEAQEBBQECAQYBAwH7BAIAAAAAAQBxAgAAAAE/IGufqbpSEgvYbw685nDEyMxGKL9FlQilR593oz4l8wAAAAAA/f///wLzbOcpAQAAABYAFLikxoEHURUNIRqJZO+hZBpDIRdbgIQeAAAAAAAWABTiR1/vOKdPfmxe7PFjWeVXM/PEamUAAAABAR+AhB4AAAAAABYAFOJHX+84p09+bF7s8WNZ5Vcz88RqAQhrAkcwRAIgffBOLzpOGluuXVQL3+Nh57/v1KiZMmTQ8azbTp1uvq8CIEEJMg/FcFFBRhJEEj7+qSAWJ1zYMoTRkLXnz2kYn1t+ASECAuzPYkKg0uX0lzjSQPmcEN8Qg4GvjKKB1Kggpt1l4X8BDiBsxRVtCsARg7eO1wBCa1Q9QSO1uVsgKM0CdYaTNqNDaQEPBAEAAAABEAT9////DPwJbGlnaHRuaW5nAgIAAQz8CWxpZ2h0bmluZwEItnNGZ/Bz25IAAQMIQEIPAAAAAAABBCIAIAudZByKBPnrEYNlicb4obXo+9D41IAxB52EsOTPC6lrAAEDCAEvDwAAAAAAAQQiUSCfpNJOnaQ8W/j8DZc21ORFI4rNcU0GgRbfUWXQeR26HSEHoyOuZ721tL0aN6eJJY4wZEeSiAU21KuPQRiZUZCCbScJAIgBXIECAAAADPwJbGlnaHRuaW5nAQixrSLGhyK6fAA=', 'withheld': False}, 'to_us_msat': 1000000000, 'min_to_us_msat': 1000000000, 'max_to_us_msat': 1000000000, 'total_msat': 1000000000, 'fee_base_msat': 1, 'fee_proportional_millionths': 10, 'dust_limit_msat': 546000, 'their_max_htlc_value_in_flight_msat': 18446744073709551615, 'our_max_htlc_value_in_flight_msat': 18446744073709551615, 'their_reserve_msat': 10000000, 'our_reserve_msat': 10000000, 'spendable_msat': 978718000, 'receivable_msat': 0, 'minimum_htlc_in_msat': 0, 'minimum_htlc_out_msat': 0, 'maximum_htlc_out_msat': 990000000, 'their_to_self_delay': 5, 'our_to_self_delay': 5, 'max_accepted_htlcs': 483, 'state_changes': [{'timestamp': '2026-04-01T07:52:32.735Z', 'old_state': 'CHANNELD_AWAITING_LOCKIN', 'new_state': 'CHANNELD_NORMAL', 'cause': 'user', 'message': 'Lockin complete'}, {'timestamp': '2026-04-01T07:52:51.053Z', 'old_state': 'CHANNELD_NORMAL', 'new_state': 'CHANNELD_AWAITING_SPLICE', 'cause': 'remote', 'message': 'Splice signatures sent'}], 'status': ['CHANNELD_NORMAL:Channel ready for use.'], 'in_payments_offered': 0, 'in_offered_msat': 0, 'in_payments_fulfilled': 0, 'in_fulfilled_msat': 0, 'out_payments_offered': 0, 'out_offered_msat': 0, 'out_payments_fulfilled': 0, 'out_fulfilled_msat': 0, 'htlcs': []}
2026-04-01T07:56:01.0603053Z
2026-04-01T07:56:01.0607410Z tests/test_splice.py:713: AssertionError
```

We need to wait for this, as l1 and l3 may not have seen block yet.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit fixes a flaky test in Core Lightning's test suite. The test sometimes failed because it checked immediately whether an 'inflight' splice entry had disappeared from a channel, but the nodes l1 and l3 may not have processed the latest block yet. The fix simply waits for that condition instead of asserting it right away. There is no security issue in the production code.

Security candidatecommon: add tal_free_if_taken() helper for common case.by Rusty Russell · 9b85a247 · Mar 29, 2026 · 29 filesMessage 65 · AdequateInformational 15Details
Commit message · Rusty Russell

common: add tal_free_if_taken() helper for common case.

Uses found and changed by Claude.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 15/100

This commit is a straightforward code cleanup: it introduces a small helper function called tal_free_if_taken() and replaces many repeated two-line patterns across the codebase with calls to that helper. The behavior of the program is unchanged; no security vulnerability is introduced or fixed.

Security candidatebitcoin: hoist script_with_len out of wallet/ into here.by Rusty Russell · 8f8cab0e · Mar 22, 2026 · 56 filesMessage 95 · StrongInformational 15Details
Commit message · Rusty Russell

bitcoin: hoist script_with_len out of wallet/ into here.

Vital for hashing. But adding script_with_len_hash here breaks
fuzzing build, so that requires a little modification.

I also noticed that `#include <common/randbytes.h>` is redundant in
all the common/ unit tests, so removed it.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidencecryptography-sensitive pathsigning or wallet pathparser or protocol path
AI analysis · Informational 15/100

This commit is a routine code cleanup: it moves a small helper structure and its hash/equality functions from the wallet module to the more general Bitcoin module so other code can reuse them. It also updates many test files to provide a stub for a hash-seed function and removes an unused header include. There is no security fix or vulnerability here.