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 57 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.
b13f5db0 · Apr 10, 2026 · 1 fileInformational 15doc: update release-checklist to make CHANGELOG.md more coherent.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only updates the project's internal release checklist documentation. It reorders the steps for preparing a release changelog so that maintainers first import changes from point releases, then merge new entries, then remove duplicates, and then format the result. There is no change to any software code, configuration, or security-sensitive process.
1e19ebfc · Apr 10, 2026 · 1 fileInformational 15CHANGELOG.md: import v25.12.1 CHANGELOG.md, remove duplicate entries.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only edits the project's CHANGELOG.md file. It imports the changelog for an already-released version (v25.12.1) and removes duplicate entries that were previously listed under the unreleased section. No program code, configuration, or build files were changed, so this cannot introduce or fix any security vulnerability by itself.
96b4da92 · Apr 9, 2026 · 1 fileLow 40sql: add test that triggers bug on channelmoves
Updating channelmoves table makes sql to crash if there are more
elements in listchannelmoves than limit_per_list.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit only adds a new test case that demonstrates a bug. The test is marked as expected to fail (xfail). It shows that running a SQL query on the 'channelmoves' table can crash a node if the number of channel movements exceeds an internal list limit. The actual crash-causing code is not fixed here, so this commit by itself does not resolve the issue.
bb0553c8 · Apr 9, 2026 · 1 fileLow 25sql: make LIMIT_PER_LIST into a dev option ...
for regression tests.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This change turns a hard-coded internal batch size (10,000 items) for the SQL plugin into a developer-only command-line option. It is intended to let regression tests use a smaller value. The option is marked 'dev-' and is not meant for production use. There is no direct security bug in the patch, but making the limit configurable could, in theory, allow a tester or misconfigured node to request very large batches and change resource usage or timing behavior.
2ba55cc6 · Apr 9, 2026 · 2 filesModerate 50sql: fix crash for large channelmoves tables.
I've reworked this: in general we should clear the refresh bit before
calling the jsonrpc to do the update. This allows the wait callback to
set the bit again if there's more to do, so we won't lose entries.
Now it's clear that we can remove the overzealous assert.
sql: plugins/sql.c:1749: refresh_by_created_index: Assertion `td->refresh_needs != REFRESH_UNNECESSARY' failed.
sql: FATAL SIGNAL 6 (version v26.04rc2)
0x5618e147892e send_backtrace
common/daemon.c:38
0x5618e14789bb crashdump
common/daemon.c:83
0x7f54d10ea04f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7f54d1138eec __pthread_kill_implementation
./nptl/pthread_kill.c:44
0x7f54d10e9fb1 __GI_raise
../sysdeps/posix/raise.c:26
0x7f54d10d4471 __GI_abort
./stdlib/abort.c:79
0x7f54d10d4394 __assert_fail_base
./assert/assert.c:94
0x7f54d10e2ec1 __GI___assert_fail
./assert/assert.c:103
0x5618e1472725 refresh_by_created_index
plugins/sql.c:1749
0x5618e14736af one_refresh_done
plugins/sql.c:579
0x5618e1473932 limited_list_done
plugins/sql.c:1738
0x5618e1477418 handle_rpc_reply
plugins/libplugin.c:1093
0x5618e1477548 rpc_conn_read_response
plugins/libplugin.c:1398
0x5618e147ec71 next_plan
ccan/ccan/io/io.c:60
0x5618e147ef90 do_plan
ccan/ccan/io/io.c:422
0x5618e147f049 io_ready
ccan/ccan/io/io.c:439
0x5618e147ffae io_loop
ccan/ccan/io/poll.c:470
0x5618e14786af plugin_main
plugins/libplugin.c:2461
0x5618e1474b12 main
plugins/sql.c:2219
0x7f54d10d5249 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f54d10d5304 __libc_start_main_impl
../csu/libc-start.c:360
0x5618e1470710 ???
_start+0x20:0
0xffffffffffffffff ???
???:0
Diagnosed-by: Lagrang3 <lagrang3@protonmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-None: Introduced this release.
This commit fixes a crash in Core Lightning's SQL plugin. The bug was a too-strict internal check (an assertion) that could fail when the plugin had a large number of channel moves to refresh. The fix changes how the plugin tracks which refresh work is still needed, so it no longer trips over itself when new work arrives while a refresh is already running. It is a stability fix for a plugin, not a remote exploit.
48952927 · Apr 9, 2026 · 1 fileInformational 15CI: Turn on diff outputs on failed doc gen
When the doc generator fails, make the CI output the diff of how it failed.
This is a tiny change to the project's build/CI Makefile. It adds the `--text` flag to a `git diff` command that runs during automated checks. This only affects how test failures are displayed when generated documentation files don't match expectations. There is no security relevance.
9b51d661 · Apr 9, 2026 · 2 filesInformational 18splice: Enable the splice in default settings
Turn splicing on by default for channel feature sets!
Changelog-Deprecated Splicing is now enabled by default!
This commit turns on a new Lightning protocol feature called 'splicing' by default. Splicing lets users add or remove funds from an existing Lightning channel without closing and reopening it. The change itself is a simple configuration default update and does not fix any bug or vulnerability. It only affects which features a node advertises to peers and which tests expect to see in that advertisement list.
3a17da61 · Apr 9, 2026 · 29 filesInformational 15splice: Remove experiemental splicing feature
Why it was queuedThis 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.
72092258 · Apr 9, 2026 · 1 fileInformational 17splice script: Fix rare memleak in plugin
Fix leaking of the `abort_pkg` if our peer does not support splicing.
This is a one-line memory leak fix in a rarely-used error path of the splicing plugin. When a splice attempt fails because the peer does not support splicing, a small helper object was allocated against the plugin's long-lived context instead of the short-lived command context. That means the memory is not freed until the plugin restarts, rather than when the command finishes. It is a resource-cleanup bug, not a code-execution or funds-loss vulnerability.
39c243ce · Apr 2, 2026 · 10 filesInformational 15v2604.rc2
Changelog-None
This commit is a routine version bump from v26.04rc1 to v26.04rc2 for Core Lightning. It only updates version strings in packaging files and refreshes the changelog. No code behavior changes are included in the diff itself, so this single commit does not introduce or fix any security issue.
f067b738 · Apr 2, 2026 · 2 filesInformational 15doc: provide realistic example for bkpr-report.
This should make the accountants happy!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only adds example request/response documentation for the bkpr-report RPC command. It changes two JSON schema files to show accountants how the report output looks, with no code logic changes.
bc931451 · Apr 2, 2026 · 4 filesInformational 17bkpr-report: make ? work as expected on amount fields.
They should test if it's zero, not if it's present.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a small behavior bug in the bookkeeper plugin's report formatting. Previously, the '?' fallback feature in report templates checked whether an amount field was present, not whether it was zero. Now, for amount fields like credit, debit, fees, and creditdebit, '?' treats a zero value as if the field were missing, so fallback text is used as users would expect. This is a correctness/usability fix, not a security vulnerability.
90b86107 · Apr 2, 2026 · 6 filesInformational 21bkpr-report: enhance tag syntax from {tag:replacement} to {tag?if-set:if-not-set}
This is more powerful, but we need to do this before release. It lets
us do things like: {credit?+{credit}:0} to only put a `+` in front of
no-zero credit, and {txid?TXID {txid}:Outpoint {outpoint}} to print
either `TXID xxx` or `Outpoint xxx`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is a routine feature enhancement for the bookkeeper plugin's report formatting syntax. It expands template tag syntax so users can specify both 'if present' and 'if absent' text around a tag. There is no indication of a security bug being fixed; it is a pre-release user-facing improvement with added tests and documentation updates.
8b6374e1 · Apr 2, 2026 · 22 filesInformational 19msggen: generate native notification bindings from schemas
Expand the native notification list consumed by msggen and regenerate the Rust and gRPC outputs for the documented notification schemas.
This wires the new schema-backed native notifications through cln-rpc, cln-grpc, and the bundled msggen schema metadata. Keep the temporary xpay-prefixed plugin notifications out of generation for now.
coin_movement.extra_tags remains a repeated string in the generated gRPC surface for now because msggen does not currently emit enums nested under repeated array items correctly.
Changelog-Changed: cln-rpc and cln-grpc now expose notification bindings for balance_snapshot, coin_movement, deprecated_oneshot, disconnect, forward_event, invoice_creation, invoice_payment, log, onionmessage_forward_fail, openchannel_peer_sigs, plugin_started, plugin_stopped, sendpay_failure, sendpay_success, shutdown, and warning.
msggen: generate xpay notification bindings
Treat xpay as a built-in plugin for notification generation and include its documented notification schemas in the msggen output.
This extends the generated cln-rpc and cln-grpc notification surfaces with the flat xpay schema files, while exposing the actual notification names `pay_part_start` and `pay_part_end` in generated APIs.
Changelog-Changed: cln-rpc and cln-grpc now expose xpay notification bindings for `pay_part_start` and `pay_part_end`.
This commit is a large, routine code-generation update for Core Lightning's Rust and gRPC client libraries. It adds native bindings for many existing node notifications (such as payment events, log messages, and coin movements) so that external applications can subscribe to them through the gRPC and Rust RPC interfaces. The change is mostly mechanical: it exposes notifications that already existed internally, but does not by itself add new node functionality or change security-critical logic. There is no indication in the commit that this fixes a security bug or introduces a vulnerability.
9336e360 · Apr 2, 2026 · 1 fileInformational 15cln-grpc: add round-trip tests for notification bindings
cln-grpc: clean up notification tests
This commit only adds new automated tests for notification message bindings in the cln-grpc Rust component. It does not change any production code, network behavior, or security logic. There is no security issue here.
95b13b9c · Apr 2, 2026 · 18 filesInformational 15doc: add notification schemas for native topics
Add schema definitions for the documented native notifications which were
still only described in prose.
This makes the notification payloads available in doc/schemas so msggen can
consume them in later commits, while keeping this commit schema-only.
The balance_snapshot schema follows the current implementation shape:
the notification wrapper contains a single balance_snapshot object whose
accounts field is an array of account snapshots.
doc: add flat xpay notification schemas
Add schema files for the documented xpay notifications using the temporary
flat naming convention.
These topics are plugin-emitted rather than native lightningd notifications,
so keep them separate from msggen generation for now while still recording
their subscriber-visible payload shape in doc/schemas.
This commit only adds new JSON schema documentation files describing notification messages that Core Lightning already sends. It does not change any executable code, network behavior, or security logic. There is no security fix or vulnerability introduced here.
48271d53 · Apr 2, 2026 · 1 fileInformational 15doc: update pay_part_start and pay_part_end
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This commit only updates developer documentation. It changes example JSON snippets for two plugin event notifications so that the fields appear directly under 'params' instead of being nested inside a 'payload' object. There is no code change and no security relevance.
3e878280 · Apr 2, 2026 · 1 fileInformational 15pytest: 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>
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.
03f85c7f · Apr 2, 2026 · 1 fileLow 32connectd: remove DNS seeds entirely.
For 25.05 (0a94f3b5706cd06e69ca120f1b77da8562cd2453) we removed DNS lookups,
but we left them for the corner case where a proxy is used. darosior points
out that his is no longer functional, which brought my attention to this
vestigial corner case.
Changelog-None: we said we'd removed them earlier!
Reported-by: darosior
Closes: https://github.com/ElementsProject/lightning/pull/8968
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit removes leftover code that let Core Lightning nodes look up peer addresses through two public DNS seed services when using a proxy. The project had already announced it was removing DNS seeds in an earlier version, but a small corner case was missed. This change finishes that removal. It is a cleanup/privacy-hardening change rather than a fix for an active security bug.
2cc1abcf · Apr 2, 2026 · 1 fileInformational 15pytest: removed old test
Why it was queuedThis commit simply deletes an old test from the test suite. It removes a pytest function that checked how the software handles opening a dual-funded channel when Bitcoin fee estimates are unavailable. There is no change to the actual software code that users run, and nothing in the commit message or diff suggests a security fix or vulnerability.
49779a99 · Apr 2, 2026 · 6 filesLow 45lightningd: refuse to let a peer open a channel if we have no fee estimates.
This seems a sensible precaution anyway.
Changelog-Changed: lightningd: we don't allow new incoming channels if we cannot estimate fees (rather than assuming minfee).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change stops Core Lightning from accepting new incoming payment channels when the node cannot estimate current Bitcoin transaction fees. Previously, the node might accept a channel while assuming a very low fallback fee. That could lead to problems later if the real network fees were much higher, because the channel's agreed fee range might be too low to get transactions confirmed promptly. The patch adds a safety check that rejects incoming channel offers with a clear 'feerates unknown' message until fee estimates become available.
7f949c61 · Apr 2, 2026 · 1 fileInformational 12tests: test reproduce #8863
[ Neated and added xfail -- RR ]
This commit only adds a new test case to the project's test suite. It does not change any production code. The test is marked as expected to fail (xfail) and is intended to reproduce a previously reported issue (#8863) about opening dual-funded channels when fee estimates are unavailable. There is no security fix or vulnerability being introduced in this diff.
5dec676c · Apr 2, 2026 · 1 fileLow 44lightningd: don't hand 0 to dualopend as anchor feerate if we cannot estimate fees.
Fixes: https://github.com/ElementsProject/lightning/issues/8847
Reported-by: https://github.com/mdance
Changelog-EXPERIMENTAL: fixed crash with dual funding if we cannot estimate fees.
This patch fixes a crash in Core Lightning's experimental dual-funding feature. When the node couldn't estimate current Bitcoin transaction fees, it was passing a value of 0 to a sub-component (dualopend) as the 'anchor feerate.' That zero value caused the process to crash. The fix detects the zero, substitutes a minimum fallback feerate, and adds a safety check to ensure it is never zero.
a9a00c41 · Apr 2, 2026 · 1 fileInformational 21common: allow current_feerate under 253 in marginal_feerate().
We don't allow this for now (by spec!), but in case we ever did we
should not try to enforce it here!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This small code change removes a hard crash (assertion) that would occur if a future version of the software allowed Bitcoin feerates below 253 satoshis per kiloweight. Instead of crashing, the function now quietly raises such low feerates up to the minimum. The change is framed by the author as a future-proofing measure, not a fix for an active security bug.
6c6f6576 · Apr 2, 2026 · 1 fileInformational 11pytest: test that we refuse incoming open requests if we have no feerates.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only adds a new automated test to Core Lightning. The test checks that the node refuses incoming channel-opening requests when it cannot estimate Bitcoin transaction fees. It does not change any production code, so by itself it cannot introduce or fix a security issue. It may be a regression test for behavior fixed in an earlier commit.