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 1 hour, 2 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.
498e5086 · Sep 17, 2026 · 1 fileInformational 15wallet: fixed timestamps for invented bookkeeper deposits
migrate_setup_coinmoves() stamped wallet deposits with wall-clock time
via coinmvt_current_time(), so a slow migration could place the deposit
after the channel journal entry in bkpr-listaccountevents, flaking
test_migration_no_bkpr.
Use base_timestamp + 1, like the channel moves, so the order is stable.
Changelog-None
This 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 channel records instead of using the real-time clock. There is no security issue here.
273d7f02 · Aug 20, 2026 · 2 filesInformational 15common: minor typo fixes
Why it was queuedThis 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 security relevance.
c4fe4cba · Aug 19, 2026 · 2 filesInformational 20pyln-testing: truncate long testnames
Postgres truncates identifiers at 63 bytes. This can lead to
'DuplicateDatabase' errors for tests with long names, as the nonce and
the node_id may collapse. This commit truncates the testname in favor of
the node_id and the nonce, to avoid conflicting db names.
Changelog-None
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This 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 to accidentally share the same database name and fail with a 'DuplicateDatabase' error. The patch makes sure the unique parts of the name (node ID and random nonce) are kept while the long human-readable test name is shortened instead. It is a reliability fix for the test suite, not a security vulnerability in the live lightning node software.
4681177d · Aug 18, 2026 · 2 filesModerate 59askrene: fix crash loading node bias with description
load_node_bias() passed take(description) to two consecutive
set_node_bias() calls. The first call's tal_strdup() consumes the
take (tal_resize_ + tal_steal), so the second take() was on freed
memory and we aborted in to_tal_hdr() with "Not a valid header"
while loading the layer at startup. Since askrene is an important
plugin, lightningd shuts down and the node cannot restart at all.
The description is already a copy off tmpctx, so simply don't take()
it: set_node_bias() strdups it into the bias anyway.
With this, the test from the previous commit passes.
Fixes: #9433
Reported-by: endothermicdev
Changelog-Fixed: askrene: node failed to start (`exited before replying to init`) when a persistent layer contains a node bias with a description
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
This 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 it a second time, causing an immediate crash during startup. The fix removes the incorrect 'take ownership' call so the description remains valid for both uses. There is no evidence this crash can be triggered remotely or used as an attack; it appears to be a reliability bug that only affects nodes that already have such saved data.
0f3f67a0 · Aug 18, 2026 · 1 fileInformational 12tests: restart the node which owns the layer in node bias test
test_node_bias_persistence() restarted l2, but the layer and its
node bias records live in l1's datastore. The assert compared
l1's in-memory layer against itself, so load_node_bias() was never
actually exercised and this test could not have caught the startup
crash in #9433.
Restarting l1 instead makes the test reload the layer from the
datastore at startup. This is the reproducer for #9433; it fails
until the next commit.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
This 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 startup crash reported elsewhere, but the crash fix is in a separate commit.
c313eff5 · Aug 15, 2026 · 2 filesModerate 60askrene: exclude stubchannels from routing
My node has some recovered channels, which were causing a crash
in askrene, due to the fact that they have duplicate scids.
Easy fix is simply to skip recovered stubs when planning
routes.
Aug 15 16:34:14 citrine lightningd[1976574]: cln-askrene: ./plugins/askrene/child/additional_costs.h:26: additional_cost_htable_add: Assertion `!additional_c ost_htable_getmatch_(ht, k, h, v, &i)' failed.
Changelog-Fixed: Crash when trying to pay and you have recovered channel stubs in your peers list
This commit fixes a crash in Core Lightning's routing plugin (askrene) that occurred when a user had 'recovered channel stubs'—placeholder records left behind after restoring a node from a backup. These stubs all share the same placeholder channel ID (1x1x1), which caused an internal table that expects unique IDs to fail an assertion and crash the plugin. The fix makes askrene skip these stubs when planning routes. The crash is triggered by normal user actions (trying to pay with recovered stubs present), not by a remote attacker, and the plugin can be restarted.
f435096d · Aug 13, 2026 · 2 filesModerate 66lightningd: fix crash on invoice_payment_hook_done
```
Valgrind error file: valgrind-errors.3449770
==3449770== Invalid read of size 8
==3449770== at 0x1B4F4A: htlc_set_fail_ (htlc_set.c:77)
==3449770== by 0x1B59FB: invoice_payment_hooks_done (invoice.c:276)
==3449770== by 0x1EC5DF: hook_done (plugin_hook.c:243)
==3449770== by 0x1EC710: plugin_hook_call_next (plugin_hook.c:343)
==3449770== by 0x1EC90E: plugin_hook_callback (plugin_hook.c:299)
==3449770== by 0x1E6316: plugin_response_handle (plugin.c:692)
==3449770== by 0x1EB443: plugin_read_json (plugin.c:781)
==3449770== by 0x283D01: next_plan (io.c:60)
==3449770== by 0x28418C: do_plan (io.c:422)
==3449770== by 0x284245: io_ready (io.c:439)
==3449770== by 0x285BE3: io_loop (poll.c:471)
==3449770== by 0x1B9A99: io_loop_with_timers (io_loop_with_timers.c:22)
==3449770== Address 0x38 is not stack'd, malloc'd or (recently) free'd
==3449770==
{
<insert_a_suppression_name_here>
Memcheck:Addr8
fun:htlc_set_fail_
fun:invoice_payment_hooks_done
fun:hook_done
fun:plugin_hook_call_next
fun:plugin_hook_callback
fun:plugin_response_handle
fun:plugin_read_json
fun:next_plan
fun:do_plan
fun:io_ready
fun:io_loop
fun:io_loop_with_timers
}
```
Changelog-Fixed: lightningd: fix crash of lightningd on race condition between delinvoice and a returning invoice_payment hook for fallback onchain settlements
Reported-by: Vincenzo Palazzo (Bitcoin Security Council finding 2026-08-11)
Co-Authored-By: Grok 4.5
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit fixes a crash in the Core Lightning node software. The crash happens when an invoice is deleted while a plugin's 'invoice_payment' hook is still processing a payment that came in through an on-chain fallback address. By the time the hook finishes, the internal data structure it expected to use (the HTLC set) had already been cleared, causing the node to read invalid memory and crash. The fix simply checks whether that data still exists before using it.
7a05b8fa · Aug 13, 2026 · 2 filesModerate 64tests: huge log entries don't crash lightningd
Drive log_to_files() directly with an entry far larger than any stack buffer,
using a plugin which emits one on demand.
Nothing bounds a log entry, so testing this through clnrest is the wrong shape:
requests are now capped at 2MiB before any parameter is parsed, so an oversized
request is rejected long before it can reach the logger, and a test written that
way passes whether or not the daemon is fixed. A plugin can hand us an entry of
any size, which is what we actually want to exercise.
(cherry picked from commit 50910c956694006b516b8bca1dbc214f79842772)
This commit adds a test for a previously fixed crash in Core Lightning's logging code. The bug was that log entries could be arbitrarily large, and the daemon used to allocate a stack buffer based on the entry's length, which could exhaust the stack and crash the process. The test uses a plugin to feed the logger an 8 MB entry and checks the node stays alive. The commit itself only adds the test and plugin; it does not contain the actual fix.
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.
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.
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.
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.
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.
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.
a70ae963 · Aug 4, 2026 · 8 filesInformational 17lightningd: internal cleanups since all non-command JSON IDs are strings.
In particular, "struct jsonrpc_request"'s id is always a string.
cmd->id isn't, though.
We can also remove the now-unused json_get_id.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a routine internal cleanup commit in Core Lightning. It removes an unused helper function and simplifies how JSON-RPC request IDs are stored and formatted, since the project now always uses string IDs for non-command JSON traffic. The changes are refactor-style and do not appear to fix a security bug.
81425f17 · Aug 4, 2026 · 3 filesModerate 60lightningd: don't crash when truncating large log messages
It's not okay to call free() on the pointer to a truncated log message
that was allocated by tal_fmt() in cap_header(). Let's call tal_free()
instead, and rather than calling vasprintf() to malloc the log message in
the first place, let's call tal_vfmt().
Also, since we're now always using a tallocated string for the log message,
let's have cap_header() take ownership of it and either free it if it
truncated the message (and is returning a different pointer to the truncated
message) or else return the taken original pointer without freeing it.
Also, log_io()'s str and data parameters are marked TAKES, but the function
was not actually taking them, so fix that up too.
Also, don't call strlen() on a string returned by tal_fmt(). The returned
pointer is guaranteed to have tal_count() == strlen() + 1, so there's no
sense in scanning through the string to find its length.
Suggested-by: Lagrang3 <lagrang3@protonmail.com>
See: https://github.com/ElementsProject/lightning/pull/9331#discussion_r3628600315
Changelog-Fixed: log: don't crash when truncating large log messages
This commit fixes a crash bug in Core Lightning's logging code. When a log message was very long and got truncated, the program accidentally used the standard free() on memory that had been allocated by the project's own tal allocation system, causing a crash. The patch switches everything to use tal consistently, marks some function parameters as 'taken' so ownership is clear, and removes a failing-test marker because the bug is now fixed.
4b34ad33 · Jul 30, 2026 · 5 filesModerate 68openingd: bound funding_satoshis by total bitcoin supply
funding_satoshis values above the total bitcoin supply were not rejected
during open_channel/accept_channel negotiation and would later cause
libwally to fail and openingd to crash during commitment transaction
construction.
Reject such funding_satoshis values immediately so that the negotiation
terminates gracefully.
Fixes: #9225
Changelog-Fixed: `openingd` no longer crashes when a peer opens a channel with a `funding_satoshis` value greater than the total bitcoin supply.
This update fixes a bug in Core Lightning's channel-opening code. A malicious or misconfigured peer could send an impossibly large channel funding amount. Previously, the software accepted the value during negotiation and only crashed later when it tried to build a real Bitcoin transaction. Now, these oversized values are rejected immediately and the negotiation ends cleanly instead of crashing the opening daemon.
7f22da25 · Jul 30, 2026 · 1 fileInformational 15Dockerfile: add protobuf-compiler for vls signer step
After 608f6952ea2772a31f4699580bce75a8f82f7f1c the vls docker image build fails
because it is missing protoc.
```
> [vls-builder 9/10] RUN cargo build --release --target x86_64-unknown-linux-gnu:
177.2
177.2 Caused by:
177.2 process didn't exit successfully: `/opt/validating-lightning-signer/target/release/build/lightning-storage-server-85c73031cf3e0f51/build-script-build` (exit status: 1)
177.2 --- stdout
177.2 cargo:rerun-if-changed=proto/lss.proto
177.2 cargo:rerun-if-changed=proto
177.2
177.2 --- stderr
177.2 Error: Custom { kind: NotFound, error: "Could not find `protoc`. If `protoc` is installed, try setting the `PROTOC` environment variable to the path of the `protoc` binary. To install it on Debian, run `apt-get install protobuf-compiler`. It is also available at https://github.com/protocolbuffers/protobuf/releases For more information: https://docs.rs/prost-build/#sourcing-protoc" }
177.2 warning: build failed, waiting for other jobs to finish...
```
vls 0.14 also has an external dependency that requires protoc, so vls vendoring it would not be enough.
This commit fixes a Docker image build failure by adding the missing protobuf-compiler package. It is a build tooling fix with no security relevance.
4ba051ca · Jul 27, 2026 · 3 filesInformational 24wallet: handle bwatch wallet/utxo spend notifications
When bwatch_got_utxo() records a wallet output, it arms an outpoint
watch owned by wallet/utxo/<txid>:<outnum>. This adds the receiving
end of that watch: the dispatch entry plus the found/revert handlers.
On watch_found (a tx consumed the outpoint): mark the output spent in
our_outputs, store the spending tx in our_txs, and emit a withdrawal
coin movement. On watch_revert (a reorg removed that tx): clear
spendheight so the UTXO is spendable again.
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit adds the missing bookkeeping that runs when Core Lightning's own on-chain wallet spends a UTXO. It makes the node mark the UTXO as spent, record the spending transaction, and log a withdrawal coin movement. It also handles blockchain reorgs by unmarking the UTXO so it can be spent again. There is no direct evidence this fixes an exploitable vulnerability; it appears to be a correctness/ledger-integrity improvement.
0a10e74e · Jul 27, 2026 · 2 filesLow 34wallet: read UTXO state from our_outputs
With every writer dual-writing since the previous two commits, flip
the readers: all UTXO queries (listfunds, coin selection, reservations,
onchaind close info) now come from our_outputs, and the legacy-only
read helpers (wallet_stmt2output, gather_utxos, db_get_unspent_utxos)
are deleted.
our_output_row_to_utxo replaces wallet_stmt2output, using channel_dbid
to discriminate HD outputs from channel-close outputs, and
wallet_get_spendable_utxos centralizes the unspent+unreserved query
that wallet_find_utxo and wallet_has_funds previously duplicated.
migrate_setup_coinmoves keeps reading the legacy table directly: that
migration runs at v25.09, before our_outputs exists.
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit switches Core Lightning's wallet code to read UTXO (unspent transaction output) data from a new database table called our_outputs instead of the older outputs table. It also deletes several old helper functions and updates tests to use the new data model. The change is part of an internal database migration and includes dual-writing safeguards so older versions of the software can still read the legacy table. There is no direct evidence in the commit of a security vulnerability being fixed.
d14ee378 · Jul 27, 2026 · 1 fileInformational 15tests: update test_wallet.py raw-SQL queries for our_outputs
The wallet no longer writes UTXO state to the legacy outputs table's
status/spend_height columns, so tests that peek at the database
directly must read our_outputs instead.
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit only updates internal test code to query a new database table (our_outputs) instead of an old one (outputs). It does not change the actual wallet or node software that users run, so it cannot directly affect security.