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
146commits · 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 52 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 candidatepytest: add failing downgrade test.by Rusty Russell · 4d8f1d33 · Nov 27, 2025 · 1 fileMessage 70 · AdequateInformational 12Details
Commit message · Rusty Russell

pytest: add failing downgrade test.

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

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
update trust
AI analysis · Informational 12/100

This commit only adds a new test to the project's test suite. It checks that the database downgrade tool correctly refuses to downgrade when a newer feature (a node bias in the 'askrene' routing layer) is present. There is no change to production code, no fix for a vulnerability, and no security-relevant behavior change in the software itself.

Security candidatelightningd-downgrade: downgrade askrene's layer info too.by Rusty Russell · a45c9072 · Nov 27, 2025 · 3 filesMessage 73 · AdequateLow 44Details
Commit message · Rusty Russell

lightningd-downgrade: downgrade askrene's layer info too.

If they had a channel bias, and ran xpay, it will update the bias
to a v2 bias (with a timestamp). We must downgrade that, or the
older version won't load!

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

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

This commit fixes a bug in Core Lightning's downgrade tool. If a user ran a newer version that stored an updated 'channel bias' record (used by the xpay payment plugin to influence routing), then tried to downgrade to v25.09, the older version would fail to load because it didn't understand the newer data format. The patch teaches the downgrade tool to convert those newer records back to the older format. It is a data-compatibility fix, not a remote exploit.

Security candidatehsmd: fix HSM sent an unknown message type errorby Sangbida Chaudhuri · 4c7e2d44 · Nov 27, 2025 · 2 filesMessage 80 · StrongLow 32Details
Commit message · Sangbida Chaudhuri

hsmd: fix HSM sent an unknown message type error

When we enter the wrong passphrase hsmd crashes like this with an unknown message type:

lightning_hsmd: Failed to load hsm_secret: Wrong passphrase (version v25.12rc1-7-g7713a42-modded)
0x102ba44bf ???
send_backtrace+0x4f:0
0x102b0900f status_failed
common/status.c:207
0x102af1a37 hsmd_send_init_reply_failure
hsmd/hsmd.c:301
0x102af1497 load_hsm
hsmd/hsmd.c:446
0x102af1497 init_hsm
hsmd/hsmd.c:548
0x102b29e63 next_plan
ccan/ccan/io/io.c:60
0x102b29e63 do_plan
ccan/ccan/io/io.c:422
0x102b29d8b io_ready
ccan/ccan/io/io.c:439
0x102b2b4bf io_loop
ccan/ccan/io/poll.c:470
0x102af0a83 main
hsmd/hsmd.c:886
lightningd: HSM sent unknown message type

This change swaps write_all() to wire_synce_write() because write_all() is missing the wire protocol length prefix. We also don't send a stack trace anymore if the user has entered the wrong passphrase and exit cleanly.

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
access controlsigning or wallet path
AI analysis · Low 32/100

This commit fixes a bug in Core Lightning's Hardware Security Module daemon (hsmd). When a user entered the wrong wallet passphrase, the daemon would crash with a confusing 'HSM sent unknown message type' error and print a stack trace. The fix ensures the error message is sent using the correct wire protocol format and that wrong-passphrase failures exit cleanly without a stack trace. It is primarily a reliability and user-experience fix, not a security vulnerability that allows remote exploitation.

Security candidatelightningd: another gossip transition corner case.by Rusty Russell · 215294bc · Nov 19, 2025 · 1 fileMessage 81 · StrongInformational 19Details
Commit message · Rusty Russell

lightningd: another gossip transition corner case.

If we see a close tx at the same time we see the channel reach announce depth (here, 104x1x0 confirms
and we process blocks 109 and 110), we see it go from:

CGOSSIP_WAITING_FOR_ANNOUNCE_DEPTH->CGOSSIP_CHANNEL_UNANNOUNCED_DYING (Channel closing before 6 confirms)

Then:
CGOSSIP_CHANNEL_UNANNOUNCED_DYING->CGOSSIP_CHANNEL_ANNOUNCED_DEAD

```
INFO 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: State changed from CHANNELD_NORMAL to CHANNELD_SHUTTING_DOWN
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: gossip state: CGOSSIP_WAITING_FOR_ANNOUNCE_DEPTH->CGOSSIP_CHANNEL_UNANNOUNCED_DYING (Channel closing before 6 confirms)
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#2: billboard: Channel ready for use. They've sent shutdown, waiting for ours
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#2: Trying commit
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#2: Can't send commit: nothing to send, feechange not wanted ({ RCVD_ADD_ACK_REVOCATION:3755 }) blockheight not wanted ({ RCVD_ADD_ACK_REVOCATION:109 })
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#2: peer_out WIRE_SHUTDOWN
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#2: billboard: Channel ready for use. Shutdown messages exchanged.
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: pid 35692, msgfd 86
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#2: Status closed, but not exited. Killing
INFO 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: State changed from CHANNELD_SHUTTING_DOWN to CLOSINGD_SIGEXCHANGE
DEBUG hsmd: new_client: 2
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: Expected closing weight = 772, fee 2895sat (min 1447sat, max 1006268sat)
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: out = 506268sat/500000sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: dustlimit = 546sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: fee = 2895sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: fee negotiation step = 50%
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: billboard perm: Negotiating closing fee between 1447sat and 1006268sat satoshi (ideal 2895sat) using step 50%
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: billboard: Waiting for their initial closing fee offer
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: peer_in WIRE_CLOSING_SIGNED
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: Making close tx at = 506268sat/500000sat fee 2895sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: Received fee offer 2895sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: ...offer is reasonable
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: Their actual closing tx fee is 2895sat vs previous 4220sat: weight is 772
INFO 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: performing quickclose in range 1447sat-8492sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: Making close tx at = 506268sat/500000sat fee 2895sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-hsmd: Got WIRE_HSMD_SIGN_MUTUAL_CLOSE_TX
DEBUG hsmd: Client: Received message 21 from client
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: sending fee offer 2895sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: peer_out WIRE_CLOSING_SIGNED
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: billboard perm: We agreed on a closing fee of 2895 satoshi for tx:7685256e6e4632bd601f42bb85b6f22b7a0db8d55c468dfbb1703c3ab2e4d9ce
INFO 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: State changed from CLOSINGD_SIGEXCHANGE to CLOSINGD_COMPLETE
DEBUG wallet: Owning output 1 506268sat (p2tr) txid 7685256e6e4632bd601f42bb85b6f22b7a0db8d55c468dfbb1703c3ab2e4d9ce
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: We have 1 anchor points to use
DEBUG lightningd: Broadcasting txid 7685256e6e4632bd601f42bb85b6f22b7a0db8d55c468dfbb1703c3ab2e4d9ce
DEBUG lightningd: sendrawtransaction: 020000000001016f50e5481abf2482ed719dde6014cf9da9b3076fe12af7c8bbccfb705150ffbe0000000000ffffffff02d195070000000000225120eed745804da9784cc203f563efa99ffa54fdf01b137bc964e63c3124070ffbe69cb90700000000002251208a73bb281433f2b5db5461c6778aa2afd28e011de6bd04799a5991662c61d7a80400473044022015af4ffc277e44ab701507e017194b1e3ab8598397efab02c59dbe72340790b50220762065e91ce0a2c73f36fdf3a4d54732ef91d075c0887cfb28580220e081e81a01473044022050730b9d051a3fdecb368750ecbd558d625a1acaa42e59586c7187407319dda402202f2f6e099b2e092698fe528260e2b56be8de325bc985a17945c724514fb65b9c014752210259b3cb48220dc2016f4d320bb8105cc2c92bd8c79fc25c2ad96f37b496e491c62103bbee60c395056b8a1201e06ed79e2914c11a61d7b1aa781846468d02489dba6952ae00000000
DEBUG lightningd: Adding block 108: 4e6ba3059c6890797a29acd306e82d6f4e85ad62a6aa6d0ee5bc6ead3e6329cd
DEBUG hsmd: Client: Received message 5 from client
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: peer_downgrade
DEBUG plugin-bcli: sendrawtx exit 0 (bitcoin-cli -regtest -datadir=/tmp/ltests-laf51vlg/test_buy_liquidity_ad_check_bookkeeping_1/lightning-2/ -rpcclienttimeout=60 -rpcport=41847 -rpcuser=... -stdinrpcpass sendrawtransaction 020000000001016f50e5481abf2482ed719dde6014cf9da9b3076fe12af7c8bbccfb705150ffbe0000000000ffffffff02d195070000000000225120eed745804da9784cc203f563efa99ffa54fdf01b137bc964e63c3124070ffbe69cb90700000000002251208a73bb281433f2b5db5461c6778aa2afd28e011de6bd04799a5991662c61d7a80400473044022015af4ffc277e44ab701507e017194b1e3ab8598397efab02c59dbe72340790b50220762065e91ce0a2c73f36fdf3a4d54732ef91d075c0887cfb28580220e081e81a01473044022050730b9d051a3fdecb368750ecbd558d625a1acaa42e59586c7187407319dda402202f2f6e099b2e092698fe528260e2b56be8de325bc985a17945c724514fb65b9c014752210259b3cb48220dc2016f4d320bb8105cc2c92bd8c79fc25c2ad96f37b496e491c62103bbee60c395056b8a1201e06ed79e2914c11a61d7b1aa781846468d02489dba6952ae00000000)
DEBUG lightningd: Adding block 109: 540a47d6b316aec8d1b56efca22ffb384403659e3b29cddd3d68f87df72065a6
DEBUG lightningd: Adding block 110: 1931e9ea62324d0fb50188df525e84ee7021e1910cf3534b343db05cc4639851
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: Got UTXO spend for beff505170fbccbbc8f72ae16f07b3a99dcf1460de9d71ed8224bf1a48e5506f:0: 7685256e6e4632bd601f42bb85b6f22b7a0db8d55c468dfbb1703c3ab2e4d9ce
UNUSUAL 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: Peer permanent failure in CLOSINGD_COMPLETE: Funding transaction spent: onchain txid 7685256e6e4632bd601f42bb85b6f22b7a0db8d55c468dfbb1703c3ab2e4d9ce (reason=unknown)
UNUSUAL 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: Not dropping our unilateral close onchain since we already saw 7685256e6e4632bd601f42bb85b6f22b7a0db8d55c468dfbb1703c3ab2e4d9ce confirm.
INFO 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: State changed from CLOSINGD_COMPLETE to FUNDING_SPEND_SEEN
**BROKEN** 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: Illegal gossip state transition: CGOSSIP_CHANNEL_UNANNOUNCED_DYING->CGOSSIP_CHANNEL_ANNOUNCED_DEAD
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-onchaind-chan#2: pid 35721, msgfd 86
```

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

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
update trust
AI analysis · Informational 19/100

This commit fixes a rare internal state-machine error in Core Lightning that could occur when a channel was closing at exactly the same moment it would normally be announced to the network. Previously, the code did not allow the transition from 'unannounced and dying' directly to 'announced and dead,' causing a 'BROKEN' log error. The patch simply adds that missing allowed transition. It is a bug fix for a corner case, not a security vulnerability that an attacker can exploit.

Security candidatesendpsbt: update channel psbts if this is a channel PSBT.by Rusty Russell · ae9ecba3 · Nov 18, 2025 · 4 filesMessage 65 · AdequateLow 32Details
Commit message · Rusty Russell

sendpsbt: update channel psbts if this is a channel PSBT.

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 boundarysigning or wallet path
AI analysis · Low 32/100

This change makes the sendpsbt RPC command smarter: if the transaction being sent matches a PSBT that was promised for a new or spliced Lightning channel, the node now saves the final signed version with that channel so it can re-send it after a restart. It also updates the saved channel PSBT during splice signing. This is a reliability improvement for channel funding and splicing, not a fix for an obvious exploit.

Security candidatelightningd: don't rebroadcast withheld channels' funding_psbt on restart.by Rusty Russell · 33e5876d · Nov 18, 2025 · 1 fileMessage 65 · AdequateLow 46Details
Commit message · Rusty Russell

lightningd: don't rebroadcast withheld channels' funding_psbt on restart.

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 · Low 46/100

This change stops Core Lightning from re-announcing the funding transaction for channels that are marked as 'withheld' when the node restarts. A withheld channel is one whose funding transaction should not be broadcast yet (for example, because it is waiting for a peer or some other condition). Re-broadcasting it could leak the channel's existence or funding details prematurely, or cause the transaction to be mined before the protocol is ready. The fix is a one-line guard that skips these channels during restart rebroadcast.

Security candidatelightningd: save funding_psbt in channel, database.by Rusty Russell · 5cbab33d · Nov 18, 2025 · 11 filesMessage 73 · AdequateInformational 20Details
Commit message · Rusty Russell

lightningd: save funding_psbt in channel, database.

Interestingly, @niftynei added a funding_psbt column to the db in 2020,
but we don't use it (it was removed early 2021 with the "inflight"
architecture). So we don't need to add a new column, just plumb it
back in.

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

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 20/100

This commit restores the use of an existing database column called funding_psbt in Core Lightning. It stores the unsigned Bitcoin transaction (PSBT) used to fund a Lightning channel in the channel record and database. The change itself is a data plumbing fix, not an obvious security patch. There is no direct evidence in the commit that it fixes an active vulnerability, but storing sensitive transaction data securely matters because the PSBT contains details about the funds being committed.

Security candidatelightningd: expose funding PSBT (if we have it) in JSON API.by Rusty Russell · 606aad07 · Nov 18, 2025 · 6 filesMessage 73 · AdequateInformational 19Details
Commit message · Rusty Russell

lightningd: expose funding PSBT (if we have it) in JSON API.

Changelog-Added: JSON-RPC: `psbt` field in `funding` in listpeerchannels, and `funding_psbt` in listclosedchannels.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

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 · Informational 19/100

This commit adds a new read-only field to two JSON-RPC API responses that exposes the funding PSBT (a Bitcoin transaction planning document) for a channel, if one is stored. It is an informational API enhancement and does not change how transactions are signed, validated, or broadcast. There is no indication in the commit that this fixes a security bug.

Security candidatespender: look for unsigned PSBT on awaiting channels on startup, and re-send.by Rusty Russell · df5f38db · Nov 18, 2025 · 4 filesMessage 85 · StrongLow 30Details
Commit message · Rusty Russell

spender: look for unsigned PSBT on awaiting channels on startup, and re-send.

This covers the other corner case, where we crash before actually
signing and sending the PSBT. We can spot this because the channel is
in AWAITING_LOCKIN and we have a PSBT, but it's not signed yet.

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

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing boundary
AI analysis · Low 30/100

This commit fixes a crash-recovery bug in Core Lightning's channel-opening plugin. If the node crashed after receiving a funding PSBT but before signing and broadcasting it, the channel could get stuck in an 'awaiting lock-in' state. On startup, the plugin now scans for such stuck channels, signs the PSBT, and re-sends it so the opening process can continue. The change is defensive and improves reliability rather than introducing a security vulnerability.

Security candidatelightningd: save funding PSBT to database if we're to withhold it.by Rusty Russell · ff433a17 · Nov 18, 2025 · 11 filesMessage 73 · AdequateInformational 21Details
Commit message · Rusty Russell

lightningd: save funding PSBT to database if we're to withhold it.

Normally we don't care, but if we're withholding it, keep it around
so we can sign & broadcast later.

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

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 21/100

This commit adds plumbing to remember whether a new Lightning channel's funding transaction is being deliberately withheld from broadcast, and to store the unsigned funding PSBT in the database so it can be signed and broadcast later. The actual feature is not yet enabled for users (a comment says 'FIXME: Set by option' and the flag is hard-coded to false). It is a preparatory/refactoring change, not a fix for an active security bug.

Security candidatepytest: test failure if we crash after fundchannel_complete but before sendpsbt.by Rusty Russell · 409beb69 · Nov 18, 2025 · 2 filesMessage 75 · AdequateInformational 12Details
Commit message · Rusty Russell

pytest: test failure if we crash after fundchannel_complete but before sendpsbt.

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

75/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 12/100

This commit only adds a new automated test and a small test helper plugin. The test deliberately crashes a node between two internal steps of opening a payment channel, then checks whether the channel eventually opens after the node restarts. It is marked as expected to fail (xfail), meaning the test documents a known bug rather than fixing it. There is no production code change here.

Security candidatecommon: don't abort() if wally_psbt_output_taproot_keypath_add() fails.by Rusty Russell · f284489c · Nov 18, 2025 · 7 filesMessage 81 · StrongModerate 60Details
Commit message · Rusty Russell

common: don't abort() if wally_psbt_output_taproot_keypath_add() fails.

It fails on duplicates. It would ideally succeed, but bug reported:

https://github.com/ElementsProject/libwally-core/issues/509

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSON-RPC: `signpsbt` no longer crashes if asked to sign an already-signed PSBT with taproot paths.

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 boundarysigning or wallet path
AI analysis · Moderate 60/100

This update fixes a crash in Core Lightning's wallet command `signpsbt`. When asked to sign a PSBT (a Bitcoin transaction format) that already contains taproot signatures, the underlying library would fail and the program would call `abort()`, killing the node. The patch turns that fatal crash into a normal error message. It also removes a test marker that expected the crash, confirming the bug is now fixed.

Security candidatepytest: test for signing a signed PSBT.by Rusty Russell · eaf7ac19 · Nov 18, 2025 · 1 fileMessage 70 · AdequateLow 43Details
Commit message · Rusty Russell

pytest: test for signing a signed PSBT.

Spoiler: we crash!

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

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 43/100

This commit adds a test showing that Core Lightning crashes when asked to sign a PSBT (a Bitcoin transaction format) that has already been signed. The test is marked as expected to fail for now. It is a test-only change, not a fix, so the crash itself remains in the codebase. The crash appears to be triggered through a normal RPC call by an authenticated user.

Security candidatelightningd: remove withheld flag when we see sendpsbt.by Rusty Russell · ead680eb · Nov 18, 2025 · 1 fileMessage 65 · AdequateLow 41Details
Commit message · Rusty Russell

lightningd: remove withheld flag when we see sendpsbt.

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 boundarysigning or wallet path
AI analysis · Low 41/100

This change fixes a bookkeeping bug in Core Lightning's wallet code. When a user calls the `sendpsbt` RPC to broadcast a funding transaction, the code now clears an internal 'withheld' flag on the relevant channel. Previously, this flag could remain stuck, which might prevent the channel from advancing normally after the PSBT (partially-signed Bitcoin transaction) was sent. The patch is small and only adjusts internal state tracking; it does not appear to introduce a direct remote exploit.

Security candidateaskrene: fix use-after-free if remove_htlc_min_violations fails.by Rusty Russell · e1202021 · Nov 17, 2025 · 1 fileMessage 78 · AdequateLow 41Details
Commit message · Rusty Russell

askrene: fix use-after-free if remove_htlc_min_violations fails.

It can only fail on overflow, but if it did, the fail path frees working_ctx
and returns "error_message".

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

78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
memory safety
AI analysis · Low 41/100

This commit fixes a rare programming bug in Core Lightning's 'askrene' routing plugin. If a specific internal function failed due to an overflow, the code would free a memory context and then try to use it again on the error-handling path, which is a use-after-free. The patch changes the function to use a longer-lived memory context so the error path is safe. The failure condition is described as only possible on overflow, making real-world exploitation unlikely.

Security candidateglobal: replace randombytes_buf() with randbytes() wrapper.by Rusty Russell · f8fd97fb · Nov 13, 2025 · 69 filesMessage 65 · AdequateInformational 19Details
Commit message · Rusty Russell

global: replace randombytes_buf() with randbytes() wrapper.

This allows us to override it for deterministic results.

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 pathparser or protocol path
AI analysis · Informational 19/100

This change is a straightforward internal cleanup: it replaces direct calls to the cryptographic library's random-byte function (randombytes_buf from libsodium) with a project-specific wrapper called randbytes(). The wrapper currently does the same thing, but having it in one place makes it easier to swap in a deterministic (predictable) random source for testing in the future. There is no direct security bug introduced by this commit itself, and no evidence it weakens real-world randomness.

Security candidatewallet: make utxo order deterministic if CLN_DEV_ENTROPY_SEED set.by Rusty Russell · 8c2116a1 · Nov 13, 2025 · 2 filesMessage 65 · AdequateInformational 18Details
Commit message · Rusty Russell

wallet: make utxo order deterministic if CLN_DEV_ENTROPY_SEED set.

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
entropy or randomnesssigning or wallet path
AI analysis · Informational 18/100

This change only affects Core Lightning when a special developer-only environment variable (CLN_DEV_ENTROPY_SEED) is set. It makes the order in which the wallet picks coins deterministic instead of random, which helps developers reproduce tests. In normal operation the wallet still picks coins randomly, so this commit does not introduce a security vulnerability for regular users.

Security candidatecommon: add randbytes() wrapper to override cryptographic entropy: $CLN_DEV_ENTROPY_SEEDby Rusty Russell · 2086699b · Nov 13, 2025 · 19 filesMessage 90 · StrongInformational 21Details
Commit message · Rusty Russell

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

Only in developer mode, ofc.

Notes:
1. We have to move the initialization before the lightningd main trace_start,
since that uses pseudorand().
2. To make the results stable, we need to use per-caller values to randbytes().
Otherwise external timing changes the call order.

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

90/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
entropy or randomnessboot or update path
AI analysis · Informational 21/100

This commit adds a developer-only feature that lets Core Lightning use predictable fake random numbers instead of real cryptographic randomness when a special environment variable is set. It is intended only for testing and reproducible debugging, not for production use. The code is gated behind developer mode and is not itself a vulnerability, but any accidental use in production would severely weaken security that depends on randomness.

Security candidatelightningd: introduce some changes for dual open id randomness even with CLN_DEV_ENTROPY_SEED.by Rusty Russell · 633fd21e · Nov 13, 2025 · 1 fileMessage 70 · AdequateInformational 23Details
Commit message · Rusty Russell

lightningd: introduce some changes for dual open id randomness even with CLN_DEV_ENTROPY_SEED.

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

70/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Names security-relevant behavior explicitly
Why it was queued
entropy or randomness
AI analysis · Informational 23/100

This commit fixes a developer-only edge case. When running Core Lightning with a special developer mode flag (CLN_DEV_ENTROPY_SEED) that forces the same randomness seed for testing, multiple channel-opening sub-processes could accidentally pick the same internal IDs. That could cause a PSBT (transaction-building data structure) collision when combining contributions. The fix tweaks the seed slightly for each new sub-process so IDs differ, then restores the original seed afterward. It is not a normal user security bug and does not expose funds or keys.

Security candidatefuzz-tests: get rid of magic numbers in `fuzz-hsm_encryption.c`by Chandra Pratap · 9be3eeea · Nov 10, 2025 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Chandra Pratap

fuzz-tests: get rid of magic numbers in `fuzz-hsm_encryption.c`

Changelog-None: `fuzz-hsm_encryption.c` hard codes the lengths
sizeof(struct secret) as 32 and crypto_pwhash_argon2id_PASSWD_MAX
as 4294967295. Replace the latter with the former to improve
readability and maintainability.

While at it, replace the `tal_free()` call on our secret key with
`discard_key()`. This has the benefit of testing `discard_key()`.

[ Changed from fuzz-hsm_encryption to fuzz-hsm_secret --RR ]

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
secret or key materialfuzzing or regression evidence
AI analysis · Informational 15/100

This is a minor cleanup change to a fuzz test file. It replaces hard-coded numbers with named constants and swaps a generic memory-free call for a dedicated key-discard function. There is no security vulnerability here.

Security candidatepytest: test for bcli crash with huge PSBTs.by Rusty Russell · 5d64eb9a · Nov 3, 2025 · 1 fileMessage 70 · AdequateLow 34Details
Commit message · Rusty Russell

pytest: test for bcli crash with huge PSBTs.

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

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
signing boundary
AI analysis · Low 34/100

This commit adds a test that checks whether Core Lightning's bitcoin backend plugin (bcli) crashes when handling very large transactions. The test is marked as expected to fail for now, meaning the underlying crash bug is known but not yet fixed. It does not itself change production code.

Security candidatecommon: remove tal_check() call on libwally allocations.by Rusty Russell · 48c3df91 · Nov 3, 2025 · 1 fileMessage 83 · StrongInformational 19Details
Commit message · Rusty Russell

common: remove tal_check() call on libwally allocations.

We call it once at the end, but calling on each allocation is
excessive, and it shows when dealing with large PSBTS. Testing a
700-input PSBT was unusably slow without this: after this the entire
test ran in 9 seconds.

Changelog-Fixed: JSON-RPC: Dealing with giant PSBTs (700 inputs!) is now much faster.
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 19/100

This change removes a repeated internal sanity check that was making very large Bitcoin transaction templates (PSBTs with hundreds of inputs) extremely slow to process. It is a performance fix, not a security fix. The remaining single check at the end still catches the same class of problems, just less frequently.

Security candidateexposesecret: Add support for mnemonic-based HSM secretsby Sangbida Chaudhuri · de9c6305 · Oct 26, 2025 · 13 filesMessage 73 · AdequateInformational 15Details
Commit message · Sangbida Chaudhuri

exposesecret: Add support for mnemonic-based HSM secrets

Update the exposesecret plugin to work with the new unified HSM secret
format that supports BIP39 mnemonics.

Changelog-Added - exposesecret now has a mnemonic field

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key material
AI analysis · Informational 15/100

This commit adds a new feature to the Core Lightning 'exposesecret' plugin. It allows users who have set up their node with a BIP39 mnemonic (a human-readable seed phrase) to retrieve that mnemonic through the plugin's API. The change also includes some internal cleanup for how mnemonic secrets are handled and converted into cryptographic seeds. There is no indication in the commit that this fixes a security vulnerability; it is a feature addition.

Security candidatehsmd: use the new mnemonic-compatible hsm_secret routines.by Sangbida Chaudhuri · 218dc2fe · Oct 26, 2025 · 11 filesMessage 73 · AdequateLow 33Details
Commit message · Sangbida Chaudhuri

hsmd: use the new mnemonic-compatible hsm_secret routines.

Changelog-Changed: hsmd: New nodes will now be created with a BIP-39 12-word phrase as their root secret.
Changelog-Deprecated: config: `encrypted-hsm` to require a passphrase (use `hsm-passphrase`).
Changelog-Added: config: `hsm-passphrase` indicates we should use a manual passphrase with the hsm secret.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
access controlsigning or wallet path
AI analysis · Low 33/100

This commit changes how Core Lightning's Hardware Security Module daemon (hsmd) creates and stores the master secret for new nodes. Instead of a raw 32-byte random secret (optionally encrypted with a password-derived key), new nodes now get a 12-word BIP-39 mnemonic phrase as their root secret, with an optional passphrase. The old --encrypted-hsm option is deprecated in favor of --hsm-passphrase. The change is a feature redesign of key storage, not a fix for a known exploitable bug, but it touches critical cryptographic material and removes legacy encrypted-secret handling.

Security candidatewallet: update wallet address generation logic to use unified BIP86/BIP32 approachby Sangbida Chaudhuri · 620eb080 · Oct 26, 2025 · 6 filesMessage 73 · AdequateLow 33Details
Commit message · Sangbida Chaudhuri

wallet: update wallet address generation logic to use unified BIP86/BIP32 approach

Simplify wallet address generation by using a unified approach where
the derivation method (BIP86 vs BIP32) is determined by the wallet's
HSM secret type rather than having separate address types.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key materialsigning or wallet path
AI analysis · Low 33/100

This commit refactors how Core Lightning generates wallet addresses. Instead of keeping two separate address types (legacy BIP32 and mnemonic-based BIP86), it now picks the derivation method based on the wallet's HSM secret type. The change removes the special 'bip86' address type from RPCs and unifies address generation. It also fixes a memory leak by freeing a temporary TLV structure. There is no direct evidence in the commit of a security vulnerability being patched, but the change touches key-derivation logic and could affect fund recoverability if implemented incorrectly.