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 48 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.
804b9df8 · Aug 12, 2026 · 4 filesHigh 74clnrest: restrict maximum size of request bodies to 2MiB
Changelog-Fixed: clnrest: an unauthenticated user could crash the node with a large request body; bodies are now capped at 2MiB.
(cherry picked from commit d5c2f6dbf1b7a54679b97d2a71015ad45443baf8)
This update fixes a bug in Core Lightning's built-in REST plugin (clnrest). Before the fix, anyone on the network could send a very large request to the REST API without logging in, causing the node to crash. The patch now refuses bodies larger than 2 MB and returns an error instead of trying to read unlimited data.
6556f16d · Aug 12, 2026 · 1 fileHigh 76lightningd: don't allocate huge log entries on the stack
log_to_files() sized a stack VLA by the log string's length. Callers
can log attacker-controlled strings of arbitrary size - e.g. clnrest
logging unauthenticated request parameters on rune failure - so a
single ~10MB HTTP request overflowed the stack and crashed lightningd
(SIGSEGV).
Use a fixed 1kB stack buffer for normal entries and a heap allocation
for oversized ones.
Changelog-Fixed: lightningd: logging a very large message no longer crashes the node (stack overflow).
Reported-by: Vincenzo Palazzo (Bitcoin Security Council finding 2026-08-10)
(cherry picked from commit cc90f6b63da7a1ea9ea0b8276a96980dd2ed7496)
This fix prevents a crash in Core Lightning's logging code. Previously, when the program wrote a log message, it reserved space on the stack based on the message's length. Because some logged text comes from outside sources (for example, unauthenticated web requests to the clnrest plugin), an attacker could send a very large request and cause the program to overflow its stack, crashing the node. The patch now uses a small fixed stack buffer for ordinary messages and switches to a heap allocation only when a message is unusually large.
10b7961b · Aug 11, 2026 · 2 filesHigh 73connectd: bound the SOCKS5 request hostname to the request buffer
The SOCKS5 CONNECT request is built into a fixed 255-byte buffer, but a
domain-name request needs 7 + strlen(host) bytes and the host length was
never checked. A host longer than 248 bytes overran the buffer while the
request was assembled, corrupting the adjacent length field, which was then
used as the io_write() length and produced a large out-of-bounds read: the
proxy socket received connectd's heap instead of the request, and connectd
died. The host reaches this both from a proxied connect and from a gossiped
DNS address.
Size the buffer to hold the largest legal request (header plus a
maximum-length domain name), and refuse a hostname which still does not fit
rather than building a request we cannot represent. Truncating the host is
not an option: that is a connection to the wrong destination.
Changelog-Fixed: connectd: a proxied connection to a very long hostname (including a gossiped DNS address) could crash the node.
(cherry picked from commit 04ca809936794de47943951b9d116d9fd1ea1844)
This update fixes a bug in Core Lightning's Tor/proxy connection code. When the node tried to connect through a SOCKS5 proxy to a hostname longer than 248 characters, it wrote past the end of a small fixed buffer. That corrupted the recorded message length, causing the proxy to be sent random data from the program's memory and crashing the node. The fix enlarges the buffer to the legal maximum and rejects hostnames that are still too long instead of overflowing.
9d0c1d49 · Aug 11, 2026 · 2 filesModerate 60common: treat a reorged close output as csv-locked
If, during a run of CLN, a close gets confirmed, its outputs are added
to the wallet. If then the close is reorged out, i.e., it loses its
confirmation, using it in this inconsistent state, can cause a crash,
due to a derefence on the confirmation height which is unset.
Changelog-Fixed: wallet: Addressed a crash when attempting to spend a previously confirmed but reorged out close transaction output.
(cherry picked from commit 4c078a0e61c8eea7ec3549c71688808dcfe479f0)
This update fixes a crash in Core Lightning's wallet. If a channel-closing transaction had been confirmed and then a blockchain reorganization removed that confirmation, the wallet could try to spend the output while its confirmation height was missing. That led to a null-pointer crash. The fix treats such outputs as still time-locked so they are not spent until re-confirmed.
f818385d · Aug 11, 2026 · 2 filesModerate 69lightningd: handle amountless invoices in the onchain payment check
invoice_check_onchain_payment() compared the received amount against
*details->msat, which is NULL when the invoice was created with
amount_msat="any":
FATAL SIGNAL 11
backtrace: lightningd/invoice.c:971 (invoice_check_onchain_payment)
backtrace: lightningd/chaintopology.c:84 (filter_block_txs)
backtrace: lightningd/chaintopology.c:1020 (add_tip)
backtrace: lightningd/chaintopology.c:1117 (get_new_block)
The HTLC path already checks this; do the same onchain, where an
amountless invoice likewise accepts any amount.
Changelog-Fixed: lightningd: crash when an onchain payment arrived for the fallback address of an invoice created with amount_msat="any".
(cherry picked from commit 6d025a3dab76ec5380474b2a8065c48aec309f33)
This fix repairs a crash in Core Lightning's invoice handling. When someone paid the on-chain fallback address of an invoice that accepted 'any' amount, the software dereferenced a NULL pointer and died with a fatal signal (segmentation fault). The patch simply skips the amount comparison when no specific amount was set, matching the behavior already used for regular Lightning payments.
10088288 · Aug 7, 2026 · 2 filesLow 42wallet: persist the inflight i_sent_sigs flag across restarts
This flag was previously memory only, lets upgrade it to be used across restarts.
Changelog-None
(cherry picked from commit 5293e073560291ada3811cbbfe4240080df2ebab)
This change fixes a bug where a flag tracking whether a node had already sent transaction signatures during a 'splice' (a way to resize a Lightning channel) was stored only in memory. If the node restarted mid-process, it could forget that it had already sent signatures and either resend them or get confused about the splice state. Persisting the flag to the database makes splicing more robust across restarts.
f8ca3f4c · Aug 7, 2026 · 1 fileLow 32db: tidy db_col_psbt NULL handling
Return early for a NULL column like the sibling db_col_* helpers, and
only parse and set the version when there is actual data to work with.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Changelog-None
(cherry picked from commit d6f8cc32eddb5f9aaba4c0561f94944b550cb61f)
This commit fixes a helper function that reads PSBT data from the database. Previously, when the database column was NULL, the code would still try to parse it and unconditionally set the PSBT version, which could lead to a crash or undefined behavior. Now it returns NULL early for NULL columns, matching the behavior of similar helper functions, and only sets the version when parsing actually succeeded.
28c7ab93 · Aug 7, 2026 · 1 fileModerate 57wallet: bound-check shachain_known pos on load
Keep the loaded pos within the known[] array like the other defensive
checks in the channel loader, so a malformed row fails loudly instead of
indexing out of range.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Changelog-Fixed: wallet: an out-of-range shachain index in the database is now rejected at load instead of read out of bounds.
(cherry picked from commit fdd7b11e9f38eb2d3fa5515c00e64f0ad17d63fc)
This update fixes a bug in Core Lightning's wallet code where it reads a 'position' value from its database and uses it directly as an array index without first checking whether it is valid. If the database contained an out-of-range value, the program could read or write memory outside the intended array, which can cause crashes or unpredictable behavior. The fix adds a simple bounds check and makes the program stop with a clear error if the value is invalid.
aa395617 · Aug 6, 2026 · 4 filesLow 46ci: bind version/ref inputs via env before shell in release workflows
Follow-up to the docker/pypi env-binding pass: check-release-tag.yml,
release-build.yml, release-publish.yml and pypi-build.yml still
interpolated inputs.version / github.ref_name directly into run:
blocks (script-injection class per GitHub's hardening guidance).
Bind through env: and reference quoted shell variables instead. Also
drops a dead duplicate CHANGELOG_VERSION assignment in
release-publish.yml that ran before VERSION was set.
Made-with: Cursor
Changelog-None
This commit hardens four GitHub release workflows by moving user-controlled values (version strings and branch/tag names) out of shell command text and into environment variables. This closes a class of attack where a maliciously crafted version string or tag name could be interpreted as shell commands, potentially altering release artifacts or stealing repository secrets. The change is defensive and does not claim to fix an active vulnerability.
4e7fa317 · Aug 6, 2026 · 17 filesHigh 72channeld: split the feerate we'll pay from the one we'll accept
The previous commit clamped our own fee source on the way in. This is
the counterpart for the other side of the channel: our peer's estimator
can be just as broken as ours, and we are the only one in a position to
notice before their money is gone.
`splice_accepter` only rejected a remote `funding_feerate_perkw` below
feerate_min; there was no upper bound at all. The downstream safeguard
in check_balances only inspects the accepter's own fee contribution, and
since accepter_relative is 0 our weight is nil, so that check never
fires. A peer whose estimator has gone haywire can therefore drive a
splice at an arbitrary feerate and we will cheerfully sign it, even
though the fee comes out of their channel balance. Refusing costs us
nothing and saves them from committing their funds to a transaction they
did not mean to pay for.
Reject anything above feerate_max, and apply the same bound in
handle_splice_init so that we extend the same courtesy in reverse: if
our own estimator is the broken one, we catch it before we ask a peer to
sign for it. handle_splice_init honours `splice_force_feerate` there,
as check_balances already does: that flag is the user saying they meant
it, and a policy limit should not override it.
feerate_max also needs a bound of its own, since it was derived purely
from the estimates times config.max_fee_multiplier. But a single bound
cannot serve both directions, because feerate_max gates what we accept
in `update_fee` *and* what we propose ourselves. Set for the accept
side it would have us paying absurd fees; set for the propose side it
would pin our commitment feerate below what a congested chain demands,
which is precisely when it has to confirm. So there are now two:
- FEERATE_CEILING (1000000 perkw, 4000 sat/vB) is the most we let a
peer drive us to. Their estimator being broken is not by itself
worth dropping a channel over, so this only has to exclude the
absurd.
- MAX_OUR_FEERATE_PER_KW (100000 perkw, 400 sat/vB) is the most we will
pay: roughly 0.011 BTC for a bare anchor commitment. Declining to
propose a feerate costs us nothing, so we can afford to be strict.
our_feerate_max() applies it wherever the money is ours:
default_feerate, splice_feerate, opening_feerate and dual-fund RBF.
Note this leaves the paths where we cannot decline -- mutual close,
penalty and onchain resolution -- bounded only by the ceiling, which is
the right answer for a feerate that has a deadline attached.
channeld needs both, so channeld_init and channeld_feerates carry
our_feerate_max alongside feerate_max, and check_balances holds whichever
side is ours to the stricter one. The multiplier is settable via
--dev-max-fee-multiplier, so widen to u64 before multiplying.
Finally, remove the UINT_MAX sentinels. feerate_max returned UINT_MAX
when there were no estimates at all, and lightningd overwrote the bound
with 0xFFFFFFFF when fee limits were ignored. Both are the bound a
peer's proposal is measured against, and we store what we accept -- a
u32 that large overflows the 25/24 RBF calculation downstream. The
unknown path now falls back to FEERATE_CEILING, exactly as feerate_min
falls back to FEERATE_FLOOR, and ignore_fee_limits travels to channeld
and openingd as an explicit flag which relaxes the policy bounds but
never the ceiling. That last part makes a documented promise false, so
the three places which say ignore-fee-limits means "any fee they want"
now say what it actually means.
Changelog-Fixed: channeld: a peer can no longer initiate a splice at an arbitrarily high feerate; it is now bounded like other remote-proposed feerates.
Changelog-Changed: lightningd: we no longer propose a feerate above 100000perkw (400 sat/vB) of our own accord, for channel opens, splices, commitment updates and dual-fund RBFs.
Changelog-Changed: lightningd: `--ignore-fee-limits` and `setchannel`'s `ignorefeelimits` still drop our policy bounds, but no longer accept a feerate above 1000000perkw (4000 sat/vB).
Changelog-Changed: JSON-RPC: `feerates` reports `max_acceptable` as the feerate ceiling rather than 4294967295 when no fee estimates are available.
(cherry picked from commit 4a10d71822c277e381bf289202f494e64110b522)
This commit fixes a bug in Core Lightning where a channel peer could trick or accidentally push the node into signing a Bitcoin transaction with an absurdly high transaction fee during a 'splice' operation. Before the fix, there was no upper limit on the fee rate a peer could propose for a splice, and an internal balance check did not catch it because the accepting side contributed no funds. The patch adds two separate fee ceilings: a sanity ceiling on what any peer can propose, and a stricter self-imposed limit on fees the node itself will pay for its own transactions. It also removes unsafe 'no limit' sentinel values that could overflow later calculations.
a0598a2d · Aug 5, 2026 · 3 filesModerate 59ci: bind docker/pypi workflow inputs via env before shell
Pass platforms-to-build, docker hub owner/version/push-latest, and
dist-location through env: before run: scripts (script-injection class).
Co-authored-by: Cursor <cursoragent@cursor.com>
Changelog-None
This commit hardens three GitHub Actions workflow files by moving user-controlled inputs into environment variables before they are used in shell scripts. Previously, values like platform lists, Docker Hub owner names, and PyPI distribution locations were inserted directly into shell commands. If someone with workflow trigger access supplied specially crafted input, they could potentially inject shell commands. The change follows GitHub's recommended practice of binding inputs to environment variables first, which reduces that risk.
dc814eba · Aug 5, 2026 · 2 filesLow 42configvar: don't crash on stale configvars in finalize_overrides
Changelog-Fixed: plugins: fix crash when starting a plugin with start parameters after a previously-configured plugin option disabled itself
This commit fixes a crash in Core Lightning that could occur when starting a plugin with startup parameters after a previously-configured plugin option had disabled itself. The crash happened because the code tried to use a plugin option that no longer existed (a 'stale configvar'). The fix skips these stale entries instead of crashing. It is a denial-of-service-style bug triggered by plugin configuration changes, not a remote exploit for stealing funds.
116fd7cd · Aug 5, 2026 · 1 fileInformational 15Revert "tests: drop obsolete x-prefix in compacter-slow.sh"
This reverts commit 474c272a4699e9e98de2eef5f27355e8ed7a250b.
This commit re-adds an old-style 'x' prefix to a string comparison in a test helper script. It is a test-only change with no effect on the actual Core Lightning node software, user funds, network behavior, or security. The change simply restores a defensive shell-coding idiom to avoid a rare edge case in ancient shells.
0cfa949f · Aug 5, 2026 · 1 fileInformational 15Revert "doc: require Homebrew GNU make and gpatch on macOS"
This reverts commit d3ff147454ea693b3b599d74ce6f3750003cbd0c.
This commit is a simple documentation revert. It undoes a previous change that told macOS users to install GNU make and GNU patch from Homebrew and to put those tools first in their command path. The reverted instructions now omit gpatch and point PATH to a non-existent-looking '/opt/homebrew/opt/' directory, which is likely a mistake or incomplete edit. There is no code change and no direct security issue in the diff itself.
d3ff1474 · Aug 5, 2026 · 1 fileInformational 15doc: require Homebrew GNU make and gpatch on macOS
Apple's make/patch are too old for the build and check-source;
install gpatch and put both Homebrew gnubin dirs on PATH.
This commit only updates macOS installation instructions in the documentation. It tells macOS users to install newer GNU versions of 'make' and 'patch' from Homebrew because Apple's built-in tools are too old for building and running source checks. No code, no security fix, no vulnerability.
474c272a · Aug 5, 2026 · 1 fileInformational 15tests: drop obsolete x-prefix in compacter-slow.sh
Shellcheck 0.11 (SC2268) rejects the old x"$1" comparison idiom.
Prevents: "tests/plugins/compacter-slow.sh:5:6: note: Avoid x-prefix in comparisons as it no longer serves a purpose. [SC2268]"
This commit is a trivial shell script cleanup. It removes an old-fashioned 'x' prefix from a string comparison in a test helper script so that a newer version of the Shellcheck linter stops warning about it. The change does not alter program behavior and has no security relevance.
518620ae · Aug 4, 2026 · 1 fileInformational 15pytest: add tests for what we want askrene to do.
It diagnoses if the *total capacity* of the source/dest are
insufficient, but not if the *known capacity* is.
So we get:
The shortest path is 103x1x0->105x1x0, but 103x1x0/1 layer auto.localchans says max is 77704899msat
Whereas it would be better to do:
We know from auto.localchans that source has maximum capacity xxx msat (in 1 channels)
Similarly for the destination, we get:
The shortest path is 103x1x0->105x1x0, but 103x1x0/1 layer auto.localchans says max is 77704899msat
This commit only adds a new pytest test file. It does not change any production code. The test describes desired future behavior for the askrene routing module's error messages when a payment source or destination lacks enough channel capacity. Because no actual code behavior is modified, this commit cannot introduce or fix a security vulnerability on its own.
581bbb1f · Aug 4, 2026 · 6 filesInformational 15common: hoist hash_str helper into its own header.
We have three uses already, about to add a fourth.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a routine code cleanup: it moves a small string-hashing helper function into a shared header file so it can be reused without being copied and pasted. There is no change to behavior, no bug fix, and no security relevance.
a66fabd4 · Aug 4, 2026 · 2 filesInformational 24xpay: actually tell askrene when a payment succeeded.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a bookkeeping bug in Core Lightning's xpay plugin. Previously, when a payment succeeded, xpay did not tell the askrene routing-helper that the route worked. As a result, askrene kept stale or overly pessimistic ideas about which channels could carry payments, which could make future payments fail unnecessarily or take worse routes. The patch adds the missing 'payment succeeded' notification for every non-local hop. It is a reliability/performance fix, not a direct theft-of-funds vulnerability.
4b6fe4a1 · Aug 4, 2026 · 2 filesLow 49askrene: correctly order constraints.
Pure "constraints" don't care about order (they simply clamp max and
min), but "impressions" are relative, so they do. Change the
hashtable to keep them timestamp sorted.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a bug in Core Lightning's routing helper (askrene) where two kinds of channel information—hard limits called 'constraints' and usage estimates called 'impressions'—were being applied in the wrong order. Because impressions are time-relative, applying them out of order could make the router think a channel has more or less available capacity than it really does. The patch merges the two data structures and keeps them sorted by timestamp so they are applied in the correct sequence. The included test demonstrates that the wrong ordering could cause a payment route to be accepted when it should be rejected, or vice versa.
8891f414 · Aug 4, 2026 · 1 fileLow 35askrene: don't leak channel intel entries
On deletion of individual channel intel entries we need to free the
pointer inside the structure.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit fixes a memory leak in the askrene plugin of Core Lightning. When individual channel intelligence entries were deleted, the code removed the entry from its array but forgot to free two internal pointers (impression and constraint). Over time, this could cause the node process to consume more memory than necessary. The fix explicitly hands those pointers to a temporary context so they are cleaned up when the operation finishes.
446312cf · Aug 4, 2026 · 8 filesLow 43offers: limit invoices to 10 minutes for recurring offers in other currencies.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change tightens the lifetime of recurring invoices priced in foreign currencies (like USD) to 10 minutes by default, and refreshes them with current exchange rates when they expire. Previously, such invoices could remain valid for the full recurrence period, meaning a merchant or payer could be locked into an outdated exchange rate for a long time. The patch also improves error messages so users can tell the difference between a cancelled invoice and one that simply expired.
a6cf4915 · Aug 4, 2026 · 2 filesLow 45offers: limit expiry to offer limit, or 10 minutes with currency conversion.
This mirrors the previous commit, where we did it for recurring offers.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Offers: we set a 10 minute expiry when we create invoices for offers in other currencies.
This commit tightens the expiration time on invoices created from BOLT12 offers. Previously, all such invoices defaulted to a 2-hour payment window. Now, if the offer has an absolute expiry, the invoice expires when the offer expires; and if the offer uses a foreign currency, the invoice expires in 10 minutes (or a developer-tunable value). This reduces the window in which an attacker can exploit stale exchange rates or expired offers.
3e49d908 · Aug 4, 2026 · 2 filesLow 29fetchinvoice: don't bother with checking recurrence timing.
We don't actually need to enforce this check here: we can make that
the users' responsibility. This simplifies our work quite a lot,
since createinvoicerequest won't have to do a lookup any more.
This can be done by the repeatpay plugin itself.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit removes local timing checks in Core Lightning's fetchinvoice plugin for recurring payments. Instead of the plugin refusing too-early or too-late invoice requests, it now lets the remote node decide and report back. The change is described by the author as a simplification, moving responsibility to a separate plugin and the user. It is not presented as a security fix, and the tests are updated to expect remote error messages rather than local ones.
4348d8ac · Aug 4, 2026 · 4 filesLow 32lightningd: don't do previous invoice checking in createinvoicerequest.
This is an undocumented interface, so we can just change it.
Rename "recurrence_label" to the more general "label", now we don't
require it to find previous payments.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit removes a local sanity check in Core Lightning's experimental 'createinvoicerequest' command. Previously, when creating a recurring invoice request, the code looked up past payments by label to verify the previous recurrence was paid and to copy timing data. Now it skips that lookup and lets the remote node decide. The change also renames the 'recurrence_label' parameter to the simpler 'label'. It is described by the author as a cleanup of an undocumented interface, not as a security fix.