Modular C implementation of the Lightning Network protocol and node stack.
Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Aug 5 → Feb 61049 seen37 candidatesCompleteFeb 6 → Jun 6579 seen10 candidatesCompleteJun 6 → Jul 678 seen1 candidatesCompleteJul 6 → Aug 5147 seen16 candidatesCompleteMessage quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
Public Git author strings; identities are not independently verified.
Last scanned 51 minutes ago
This commit simply adds a new person's PGP public-key fingerprint to the list of trusted release signers in two documentation files. It does not change any code, fix any bug, or alter any security behavior of the software itself.
41278b4eby jaonoctus+2−02 filesThis is a tiny internal fix to make a bookkeeping migration produce stable event ordering. It changes the timestamp used when creating historical 'deposit' records during a one-time database migration, so the records sort consistently with…
498e5086by daywalker90+2−01 fileThis commit is a documentation-only cleanup of the JSON-RPC command help files. It corrects which numeric error codes are listed for each command so the published schemas match what the software actually returns. No program logic, validati…
d1b6963bby daywalker90+204−1224 filesThis commit fixes a bug where a setting that controls whether unexpected transaction signatures are allowed was not initialized when the channel daemon starts. If a peer sent such signatures before the channel was fully ready, the program …
c09c4520by Erick Cestari+1−01 fileThis commit fixes the project's internal nightly code-coverage CI workflow. It changes how test coverage files are collected, ensures the same LLVM compiler version is used to generate and merge coverage data, and uploads a Codecov-compati…
5685c9a3by cdecker+12−211 fileThis commit is a large cleanup of Core Lightning's API schemas, generated RPC bindings, and related plugin code. The stated goal is to make the documented 'required' fields match what the C code actually always produces or expects. In prac…
ddbd2963by daywalker90+1786−173950 filesThis commit only updates documentation. It adds error code 313 to the documented error lists for several Core Lightning commands (fundpsbt, utxopsbt, txprepare, multiwithdraw, and upgradewallet). The error code already existed in the code …
a34b9758by Peter Neuroth+30−86 filesThis commit fixes a release-script check that verifies the cryptographic signature on a file of checksums. Previously, the script only told GPG to verify the signature file itself. If someone replaced that signature file with an inline-sig…
8e495707by Peter Neuroth+5−21 fileThis commit updates Core Lightning's release documentation to tell users and release managers to run gpg --verify with both the signature file and the manifest file named explicitly. The old one-argument form can silently succeed even if t…
2dee8699by Peter Neuroth+9−62 filesThis commit is a routine update to the Rust dependency lock file (Cargo.lock), bumping many third-party libraries to newer patch or minor versions. The commit message gives no security reason for the update, and no verified references link…
c1551c55by daywalker90+298−2761 fileThis commit fixes a stack-overflow risk in Core Lightning's JSON parser. Before the fix, an attacker could send a valid JSON-RPC message containing thousands of nested brackets or braces. The parser's own helper functions used recursion fo…
83f92e4bby Níckolas Goline+90−22 filesThis commit only fixes typos and comment style. It changes two C-style comments from // to /* */ and corrects a grammar error in a documentation comment ('element' to 'elements'). There are no code behavior changes, no bug fixes, and no se…
273d7f02by w3lld1+3−32 filesThis change fixes a test-infrastructure bug in Core Lightning's Python testing helpers. When running tests against a PostgreSQL database, very long test names could be silently shortened by PostgreSQL, causing different test runs or nodes …
c4fe4cbaby Peter Neuroth+59−12 filesThis fix prevents Core Lightning from trying to use freshly created bitcoins (immature coinbase rewards) as emergency funds for fee-bump transactions. Such a transaction would be invalid under Bitcoin's rules and would be rejected by the n…
34883ff7by cdecker+5−12 filesThis commit fixes a bug in Core Lightning's askrene plugin that could prevent a node from restarting. When a saved routing layer contained a node bias with a description, the plugin accidentally freed the description's memory while using i…
4681177dby Vincenzo Palazzo+2−32 filesThis commit only fixes a test case so it actually exercises the intended code path. It does not change any production code, so it cannot introduce or fix a real-world security vulnerability by itself. The test change is a reproducer for a …
0f3f67a0by Vincenzo Palazzo+3−21 fileThis commit fixes a bug in Core Lightning's experimental dual-funded channel feature. When another node tried to open a channel, Core Lightning was not checking whether the proposed transaction fees were reasonable. A peer could request a …
ba08356fby cdecker+140−04 filesThis commit adds regression tests for three related bugs where wildly wrong Bitcoin transaction feerates could enter Core Lightning. In the worst case, a malicious or broken fee source could make the node think a feerate was zero (due to a…
65bdbc47by cdecker+137−02 filesThis update fixes a crash bug in Core Lightning. When the software tried to list details of a channel opening in progress, it could crash if a stored fee rate was extremely large or zero. The crash happened because the code used an interna…
d67c4936by cdecker+72−227 filesThis commit fixes a bug where Core Lightning nodes could get stuck in a crash loop. If a node had previously stored an extremely high or zero fee rate for an in-progress channel funding operation (a 'splice' or dual-funded channel RBF), a …
f057c692by cdecker+34−01 fileExpand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
8a60a276 · Jan 8, 2026 · 1 fileInformational 17pytest: fix feerate check in test_peer_anchor_push
We didn't log when anchor transactions had short signatures,
which causes this test to not assert (did_short_sig):
```
total_feerate_perkw = total_fees / total_weight * 1000
> check_feerate([l3, l2], total_feerate_perkw, feerate)
tests/test_closing.py:4063:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
nodes = [<fixtures.LightningNode object at 0x7f0fb322bb20>, <fixtures.LightningNode object at 0x7f0fb1b5ead0>]
actual_feerate = 14006.105538595726, expected_feerate = 14000
def check_feerate(nodes, actual_feerate, expected_feerate):
# Feerate can't be lower.
assert actual_feerate > expected_feerate - 2
if actual_feerate >= expected_feerate + 2:
if any([did_short_sig(n) for n in nodes]):
return
# Use assert as it shows the actual values on failure
> assert actual_feerate < expected_feerate + 2
E AssertionError
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a test-only logging issue. A developer warning flag (dev_warn_on_overgrind) was not logging when an anchor transaction signature was shorter than expected, causing a pytest test to fail its feerate assertion. The fix adds a log message so the test can detect the short signature and skip the strict feerate check. There is no production security vulnerability here.
7971e6aa · Jan 8, 2026 · 1 fileInformational 15pytest: don't get upset at slow multi-input signing under valgrind.
```
2026-01-06T07:46:35.5710043Z lightningd-1 2026-01-06T07:45:11.040Z UNUSUAL jsonrpc#68: That's weird: Request signpsbt took 5099 milliseconds
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a test-only change. A developer made a test more tolerant of slow performance when the code is run under a debugging/performance-analysis tool called valgrind. It does not change the actual wallet or signing code, so it has no security impact on users.
767ece8f · Dec 22, 2025 · 2 filesInformational 15contrib: add Sangbida's signing key
Why it was queuedThis commit simply adds a new team member's PGP public key to the project so they can sign future releases. There is no code change, no bug fix, and no security vulnerability present in the diff.
3e841b35 · Dec 17, 2025 · 151 filesInformational 15docs: Updated schema for mdx compatibility
Changelog-Fixed: Ensure documentation renders correctly when adding/updating new RPCs by detecting non-MDX-compatible pages.
This commit is a documentation-only change. It updates the project's documentation files and JSON schemas so that author email addresses, web links, and tables are written in a format compatible with MDX (a modern documentation rendering format). There are no changes to the actual Core Lightning software code, so it cannot affect node security, funds, or network behavior.
16735c95 · Dec 8, 2025 · 1 fileInformational 15chore: Downgrade tool diff
Why it was queuedThis commit simply deletes a helper script named 'tools/lightning-downgrade'. No code changes to the actual Lightning node software are present, and no security issue is described or visible in the diff.
8db09f6d · Dec 8, 2025 · 4 filesInformational 15Add GitHub Pages documentation site with orchestrated workflows
This commit creates a comprehensive documentation publishing system that
combines coverage reports, Python API docs, and project documentation into
a unified GitHub Pages site.
Changes:
- Update coverage-nightly.yaml to support workflow_call trigger
- Update python-docs-nightly.yaml to support workflow_call trigger
- Add docs-nightly.yaml workflow for project documentation
- Add publish-site.yaml orchestrator workflow
The publish-site workflow:
- Triggers all three documentation workflows in parallel
- Collects artifacts from each workflow
- Organizes them into a unified site structure:
- / (root) - Beautiful landing page with navigation
- /docs/ - Project documentation
- /python/ - Python API reference (pdoc3)
- /coverage/ - Code coverage reports
- Deploys to GitHub Pages with proper permissions
- Runs nightly at 5 AM UTC, after all other workflows complete
Each workflow can be:
- Triggered manually via workflow_dispatch
- Called from other workflows via workflow_call
- Run on schedule (coverage: 2 AM, python-docs: 3 AM, docs: 4 AM)
The site includes:
- Modern, responsive landing page with gradient design
- Navigation cards for each documentation section
- 404 error page
- .nojekyll file to prevent Jekyll processing
- Automatic timestamp updates
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Changelog-None
This commit adds GitHub Actions workflows to automatically build and publish a documentation website to GitHub Pages. It only touches CI/CD configuration and static HTML pages; it does not change any Core Lightning node code, wallet logic, or network handling. There is no apparent security vulnerability in the diff itself.
af5d02a9 · Dec 3, 2025 · 2 filesInformational 15gitignore: Ignore lightning-downgrade and check-bolt tools
Changelog-None.
This commit simply adds two generated tool names to .gitignore files so that Git does not accidentally track compiled binaries. It does not change any executable code, configuration defaults, or security behavior.
4d8f1d33 · Nov 27, 2025 · 1 fileInformational 12pytest: add failing downgrade test.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.
6dcf4e7b · Nov 27, 2025 · 13 filesInformational 15wallet: separate migration table into its own source file.
This will make it easier to share with the downgrade tool.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a pure code refactoring: it moves the large database migration table and related functions from wallet/db.c into a new pair of files, wallet/migrations.c and wallet/migrations.h. The goal stated in the commit message is to make the migration list easier to share with a future downgrade tool. No behavior of the migrations themselves is changed, no SQL statements are modified, and no security fixes or vulnerabilities are introduced.
a45c9072 · Nov 27, 2025 · 3 filesLow 44lightningd-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>
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.
2a066b92 · Nov 27, 2025 · 8 filesInformational 15wallet: separate datastore access functions for the lightning-downgrade tool to access.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a straightforward code reorganization: it moves existing datastore (key-value storage) database access functions out of wallet.c into a new pair of files, datastore.c and datastore.h, so a separate downgrade tool can reuse them. No behavior changes, no new features, and no security fixes are visible in the diff.
640888aa · Nov 27, 2025 · 1 fileInformational 15CI: add test that we can downgrade the node and run it under v25.09.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only adds a new automated CI test job that checks whether Core Lightning can be downgraded to the previous release (v25.09). It does not change any production code, wallet logic, network handling, or cryptographic operations. There is no security-relevant change visible in the diff.
39a92116 · Nov 27, 2025 · 3 filesInformational 15doc: add a manual page.
In particular, document when downgrades are not possible.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only adds a new manual page for an existing tool called lightning-downgrade. It does not change any code, commands, or behavior. It simply documents how to use the tool and warns users that downgrades may fail if newer features have been used. There is no security issue in this documentation change itself.
eb83a205 · Nov 27, 2025 · 4 filesInformational 15askrene: move datastore wire functions into separate file for lightning-downgrade to use.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a straightforward code reorganization: it moves existing data-serialization helper functions for the askrene plugin into a new shared file (datastore_wire.c/h) so another tool (lightning-downgrade) can reuse them. No security bug is introduced or fixed; the logic is essentially unchanged.
378293d2 · Nov 27, 2025 · 1 fileInformational 18wallet: add optional sql and functions to downgrade db.
This will allow a downgrade tool to attempt to downgrade a node to the
previous version.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit adds infrastructure to Core Lightning's database code so that future versions can, in some cases, roll back (downgrade) a database to the previous software version. It is a feature addition, not a fix for an active security bug. The new code includes safety checks to refuse downgrade when data would be lost, such as when a newly added 'withheld' column has actually been used. There is no direct evidence in the commit that this resolves a known vulnerability or that an attacker can exploit it.
9981e238 · Nov 27, 2025 · 5 filesInformational 24tools/lightning-downgrade: tool to downgrade (offline) v25.12 to v25.09.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: tools: `lightningd-downgrade` can downgrade your database from v25.12 to v25.09 if something goes wrong.
This commit adds a new offline command-line tool, lightning-downgrade, that lets a user roll back a Core Lightning node's database from the upcoming v25.12 release to the previous v25.09 release. It is meant as a recovery aid if an upgrade goes wrong. The tool only works when the lightning node is stopped, checks for a running process, and reverses database migrations one by one using built-in revert SQL and functions. It also deletes an incompatible gossip store file after downgrading. There is no direct evidence in the commit that this fixes an active security bug; it is a new operational utility.
4c7e2d44 · Nov 27, 2025 · 2 filesLow 32hsmd: 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.
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.
215294bc · Nov 19, 2025 · 1 fileInformational 19lightningd: 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>
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.
5cbab33d · Nov 18, 2025 · 11 filesInformational 20lightningd: 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>
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.
33e5876d · Nov 18, 2025 · 1 fileLow 46lightningd: don't rebroadcast withheld channels' funding_psbt on restart.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.
409beb69 · Nov 18, 2025 · 2 filesInformational 12pytest: test failure if we crash after fundchannel_complete but before sendpsbt.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.
f284489c · Nov 18, 2025 · 7 filesModerate 60common: 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.
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.
eaf7ac19 · Nov 18, 2025 · 1 fileLow 43pytest: test for signing a signed PSBT.
Spoiler: we crash!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.
ead680eb · Nov 18, 2025 · 1 fileLow 41lightningd: remove withheld flag when we see sendpsbt.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.
ff433a17 · Nov 18, 2025 · 11 filesInformational 21lightningd: 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>
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.