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 45 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.
5870ffb8 · Aug 3, 2026 · 1 fileInformational 13xpay: added subtrace to measure getroutes
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This change adds a small tracing wrapper around an internal function call so developers can measure how long route-finding takes. It does not change payment logic, amounts, routing decisions, or network behavior. There is no indication it fixes a security issue or introduces a vulnerability.
c48afd97 · Aug 3, 2026 · 1 fileInformational 15xpay: add sub-trace to measure injectpaymentonion
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit only adds tracing instrumentation to measure how long the injectpaymentonion operation takes in the xpay plugin. It does not change payment logic, cryptographic handling, network behavior, or access controls. There is no security issue here.
37526ca4 · Aug 3, 2026 · 2 filesLow 33wally: update libwally to v1.5.6
This got fixed in libwally v1.5.2: https://github.com/ElementsProject/libwally-core/commit/7e483c049b0a4405801f010e60c9f0335d2a617f
```
def test_sign_signed_psbt(node_factory, bitcoind, chainparams):
l1 = node_factory.get_node()
l1.fundwallet(10**6)
psbt = l1.rpc.txprepare([{l1.rpc.newaddr('bech32')['bech32']: 10000}])['psbt']
signed_psbt = l1.rpc.signpsbt(psbt)['signed_psbt']
if TEST_NETWORK != 'liquid-regtest':
# FIXME: ideally this would succeed, as a noop. But it shouldn't crash
> with pytest.raises(RpcError):
^^^^^^^^^^^^^^^^^^^^^^^
E Failed: DID NOT RAISE <class 'pyln.client.lightning.RpcError'>
```
Changelog-Changed: Update libwally to v1.5.6
Changelog-Fixed: JSON-RPC: `signpsbt` on an already-signed PSBT with taproot paths now succeeds as a no-op instead of failing.
This commit updates the bundled libwally library to version 1.5.6. The practical effect is that calling the JSON-RPC `signpsbt` command on a PSBT that is already signed now succeeds as a harmless no-op, instead of returning an error on Bitcoin networks. The underlying bug was in libwally's handling of duplicate Taproot keypath entries and was fixed in libwally v1.5.2.
ae53e877 · Jul 31, 2026 · 2 filesInformational 15tests: fix test_low_fd_limit failing on RLIM_INFINITY platforms
When RLIMIT_NOFILE hard limit is RLIM_INFINITY (macOS default) or
larger than UINT32_MAX, passing limits[1] and limits[1]+1 directly as
--dev-fd-limit-multiplier (a u32 option) causes lightningd to reject
the argument as out-of-range and exit(1), making both nodes fail to
start with "Unable to find Server started with public key" timeout.
Cap to TEST_CEILING=65536 when the hard limit is RLIM_INFINITY or
exceeds the ceiling, keeping the existing soft==hard halving path for
normal bounded limits.
Also add the test to the macOS CI list, so the platform it was broken
on now covers it.
Changelog-None
This commit fixes a test that was failing on macOS and other systems where the operating system reports no practical upper bound on the number of open files (called RLIM_INFINITY). The test was passing values larger than a 32-bit unsigned integer to a command-line option that only accepts 32-bit values, causing the tested program to reject the argument and the test to time out. The fix caps the test's file-descriptor limit to 65,536 and adds the test to the macOS CI list so it stays working. There is no security issue here—only a test reliability fix.
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.
39b7f6df · Jul 30, 2026 · 10 filesInformational 15CI: restructure release workflows
Binaries, docker images, and python packages are now separated into
build and publish flows. First everything gets built and if every build
step succeeds the publish step can continue.
Also fan out the docker build into a matrix to speed up the workflow.
Changelog-None
This commit is a housekeeping change to the project's automated release pipelines on GitHub. It splits the existing release workflow into separate 'build' and 'publish' steps, adds a version/tag consistency check, and fans out Docker builds across multiple platforms. There is no change to the Core Lightning software itself, its network behavior, wallet handling, or cryptographic code.
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.
ae8dee8a · Jul 30, 2026 · 3 filesInformational 21pyln-testing: don't let wait_for_log match its own forwarded announcement
An inline plugin's Plugin() object lives in the test process, and
Plugin() installs a PluginLogHandler on the root logger so that a
plugin author's logging calls reach lightningd. In the test process
that handler also forwards pyln's own machinery logs into the node's
log whenever the test-side logger emits at DEBUG. In particular
wait_for_logs() announces 'Waiting for [pattern]' with the pattern
embedded verbatim, so the announcement lands in the very log being
scanned and matches itself, silently reducing the wait to a no-op.
That let test_sendpay_notifications_nowaiter race its channel close
against the first payment (both payments then fail and the success
assertion sees an empty list); any literal-pattern wait_for_log on an
inline-plugin node is similarly voided under DEBUG logging.
Attach a filter to the inline plugin's log handler that only forwards
records originating outside the pyln packages, so author logging still
reaches the node log but pyln internals never do.
The new test covers both directions: an author log line is found by
wait_for_log, and a never-logged sentinel genuinely times out (it
matched instantly via the forwarded announcement before this fix).
The node directory embeds the test name, and this test's long name
pushes inline-plugin.sock past the AF_UNIX bind cap on some runs:
Linux's 108 bytes under liquid-regtest's longer network dir, and
Darwin's 104 with even the default path. Teach _inline_plugin() to
fall back to binding through a short symlink alias to the socket's
directory -- the same technique UnixSocket.connect already uses on
Darwin, aliasing the directory rather than the socket since bind
can't traverse a dangling final-component symlink. The socket file
still lands where the shim's cwd-relative connect expects it. The
test runs in the macOS smoke set too, so CI exercises the fallback on
the platform with the tighter cap.
Fixes: #9343
Changelog-None
This commit fixes a bug in Core Lightning's Python testing toolkit. When tests used an 'inline plugin' and ran with detailed (DEBUG) logging, the test helper wait_for_log() would accidentally see its own 'Waiting for...' message in the node's log and instantly match it, making the wait useless. This caused a real test failure (test_sendpay_notifications_nowaiter) because a payment raced ahead of channel setup. The patch filters out internal pyln log messages from being forwarded into the node log, so only the plugin author's own log lines go through. It also adds a workaround for long Unix socket paths on macOS/Linux so the new test can run. There is no direct security vulnerability here; it is a test-framework correctness fix that closes a small reliability hole in automated tests.
f2a0fb2c · Jul 29, 2026 · 2 filesModerate 62common: saturate marginal_feerate() instead of overflowing
marginal_feerate() computed current_feerate * 1.1 as a double and
converted the result back to u32. Since current_feerate is chosen by
the peer in open_channel or update_fee, they could choose an absurdly
high value that overflows u32 after the computation. UBSan reports:
common/fee_states.c:179:10: runtime error: 4.72446e+09 is outside the range of representable values of type 'unsigned int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior common/fee_states.c:179:10
Do the arithmetic with u64 and saturate at UINT32_MAX to avoid the
undefined behavior.
Found by fuzzing with smite.
Changelog-Fixed: JSON-RPC: `listpeerchannels` no longer derives `receivable_msat` from an overflowed fee estimate when the peer sets an absurd `feerate_per_kw`.
This commit fixes a numeric overflow bug in Core Lightning's fee calculation. A peer could supply an extremely high transaction fee rate that, when increased by 10%, produced a value too large for the program's internal storage. That triggered undefined behavior (a C programming error) and could cause incorrect values, such as a distorted 'receivable_msat' shown by listpeerchannels. The fix performs the math in a larger integer type and caps the result at the maximum allowed value.
46702dad · Jul 29, 2026 · 1 fileInformational 15tests: fix flaky test_bwatch_listwatch
The wallet registers its own scriptpubkey watches at node startup
since the bwatch series landed. The test anticipates them by
recording a total-count baseline first, but on a slow machine the
registration can land after the baseline is taken: an ASan CI run
caught a baseline of 0 and a final count of 105. A total-count
assertion races background registration no matter when the baseline
is read.
Count only the watches this test adds (their identifiers are
distinctive), which no background registration can perturb. The
test's per-watch assertions already work that way.
Fixes: #9360
Changelog-None
This commit fixes a flaky automated test. It does not change production code or fix a security bug. The test was sometimes failing because it counted all 'watches' in a list, but the wallet also registers its own watches in the background, causing the total count to vary on slow machines. The fix makes the test count only the specific watches it creates, so it no longer races with background activity.
90c60d01 · Jul 29, 2026 · 2 filesModerate 66lightningd: fail sendpay cleanly when the route does not fit the onion
create_onionpacket returns NULL when the route's per-hop payloads
exceed the 1300-byte onion; send_payment passed the packet to
send_onion unchecked, and serialize_onionpacket dereferenced it,
killing lightningd with SIGSEGV. Observed in production on a
25-hop route submitted by a rebalancing plugin.
The sendonion path already checks this call and fails the command;
mirror it, and add a test.
Changelog-Fixed: JSON-RPC: `sendpay` with a route too long to fit the onion packet now fails cleanly instead of crashing lightningd.
This commit fixes a crash bug in Core Lightning's payment command. When a user or plugin submitted a payment route with too many hops to fit inside the cryptographic 'onion' envelope, the software failed to check whether the onion was actually created and then tried to use a non-existent object, causing the entire lightningd process to crash with a segmentation fault (SIGSEGV). The patch adds a simple missing check so the command now returns a clean error message instead of crashing the node.
5a56a976 · Jul 28, 2026 · 1 fileTriage 0lightningd: parent watchman's formatted blockhash strings to tmpctx
json_add_string copies its value, so the strings fmt_bitcoin_blkid
allocates in json_block_processed and json_getwatchmanheight are
referenced by nothing once the call returns. They are parented to
the response stream and freed with it, but the memleak scanner works
by searching memory for pointers to each allocation: when a dev
memleak check races an in-flight response, the unreferenced string is
reported as a leak and fails the test run (seen in a liquid CI run of
test_bwatch_add_watch_creates_datastore_entry). Parent them to
tmpctx, the idiom used elsewhere.
Fixes: #9362
Changelog-None
dafba953 · Jul 28, 2026 · 1 fileInformational 14flake: fix in-flight statuses causing flakyness by waiting for all xpay-n layers to be removed from askrene before checking settlement outcome
This commit fixes a flaky automated test, not a security bug. It adds a wait so the test only checks payment statuses after internal cleanup layers called 'xpay-<n>' have been removed. There is no change to production code or user-facing behavior.
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.
1cc6ae6e · Jul 27, 2026 · 1 fileInformational 15tests: query our_outputs in test_connection.py
The wallet's live UTXO state now lives in our_outputs; point the raw-SQL
assertions at it (spent means spendheight IS NOT NULL, reserved means
reserved_til > 0).
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit only updates test code to query a renamed database table (`our_outputs` instead of `outputs`) and adjusts column names/conditions. It does not change production wallet logic or fix a security bug. There is no security relevance.
2eccf473 · Jul 27, 2026 · 2 filesInformational 15tests: query our_outputs in test_misc.py
Same raw-SQL switch as test_connection.py: read the wallet's UTXO state
from our_outputs.
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit only changes test code. It updates existing wallet tests to query a newer database table called our_outputs instead of the older outputs table, and adds one new test that checks a reorg correctly demotes a confirmed deposit back to unconfirmed without losing state. There is no change to production code, so it cannot directly affect live users or introduce a runtime security flaw.
b8a60579 · Jul 27, 2026 · 1 fileInformational 15wallet: rename b32script to scriptpubkey in PSBT change paths
Change addresses are no longer bech32-only (p2tr is the default form),
so the old name was misleading. Pure rename, no functional change;
also drop the unused txfilter.h include.
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is a simple variable rename inside a Bitcoin/Lightning wallet file. The old name 'b32script' suggested all change addresses were bech32 format, but the project now uses a newer address type (p2tr) by default. The developer renamed the variable to 'scriptpubkey' to avoid confusion and removed an unused header file. No behavior of the program changes.
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.
92402cf6 · Jul 27, 2026 · 2 filesLow 33lightningd: only run watchman under --experimental-bwatch
The flag is registered by the bwatch plugin, not lightningd, so peek
at the parsed configvars. Without it ld->watchman stays NULL and the
watchman_* entry points are no-ops, leaving chain_topology as the only
chain watcher: bwatch and the legacy path must not race each other.
The bwatch pytests opt in explicitly (with rescan=0) instead of
enabling bwatch globally.
Changelog-Experimental: wallet: Add bwatch-driven wallet transaction and UTXO tracking behind --experimental-bwatch.
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit gates a new experimental chain-watching subsystem called 'bwatch' behind an explicit --experimental-bwatch flag. Previously, the watchman helper was always created, which could have caused both the old chain watcher and the new bwatch watcher to run at the same time and race against each other. The change makes the watchman a no-op unless the user explicitly opts in, so ordinary users continue using the legacy path only.
4a951d65 · Jul 27, 2026 · 4 filesLow 44wallet: register scriptpubkey watches at startup
init_wallet_scriptpubkey_watches walks every HD key (BIP32 + BIP86) up
to {bip32,bip86}_max_index + keyscan_gap and arms a watch for each
form, so bwatch can report deposits from the very first block it
scans. wallet_get_newindex does the same for fresh keys, keeping
coverage as the wallet grows.
The per-UTXO watch on unconfirmed change is now redundant (the
perennial per-key watch already covers that scriptpubkey), so drop it.
Co-authored-by: Cursor <cursoragent@cursor.com>
This change makes Core Lightning register long-lasting 'watches' for all wallet deposit addresses when the node starts up, so the new bwatch plugin can spot incoming payments from the first block it scans. It also removes a now-redundant per-transaction watch on unconfirmed change outputs. The patch is a functional improvement for the experimental bwatch feature, not a clear-cut security fix, but a missing or incomplete watch could in principle cause deposits to be overlooked.
2c1ab4d0 · Jul 27, 2026 · 2 filesLow 32wallet: route transaction reads/writes through our_txs
Now that the bwatch wallet path records every relevant transaction in
our_txs, point the wallet's transaction readers at that table.
Since our_txs.blockheight is NOT NULL with 0 = unconfirmed, the legacy
NULL handling disappears: wallet_transactions_by_height no longer needs
its "IS NULL vs = ?" query split, and wallet_transaction_height reads
the column unconditionally.
wallet_transaction_add keeps dual-writing the legacy transactions
table: the close path still inserts into channeltxs, whose
transaction_id foreign key points at transactions(id), and
wallet_get_funding_spend joins it. That legacy write can only go away
with channeltxs itself.
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit changes how Core Lightning stores and reads wallet-related transactions. It moves most reads to a new table called our_txs while still keeping the old transactions table updated for compatibility. The main concern is that the code now prevents a confirmed transaction from being downgraded back to unconfirmed, which is good, but the change is part of a larger migration and could introduce subtle bugs if the two tables get out of sync. There is no direct evidence this fixes or introduces a security vulnerability.
2e23893b · Jul 27, 2026 · 4 filesLow 28wallet: add migrate_backfill_bwatch_tables
Populate our_outputs/our_txs from the legacy outputs/transactions
tables so the bwatch wallet path starts with the same state as the
existing wallet.
Use outputs rather than utxoset because it already contains only
wallet-owned rows and carries wallet metadata like reservations and
channel-close info.
Downgrade only drops the new tables: later commits keep mirroring
writes into the legacy tables, so no copy-back migration is needed.
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit adds a database migration that copies existing wallet data into new tables used by an upcoming 'bwatch' wallet component. It is a data backfill, not a code fix for an active vulnerability. The main risk is that if the migration copies data incorrectly, a future version of Core Lightning could misread the wallet state—potentially showing wrong balances, missing transactions, or in rare cases making unsafe spending decisions. The commit includes tests that check the copy logic for several common cases.
824e8195 · Jul 27, 2026 · 2 filesLow 29wallet: dual-write chaintopology UTXO changes into our_outputs
Before this commit:
chaintopology ──────────────> outputs
bwatch ─────────────────────> our_outputs
└────────────────────> outputs (downgrade mirror)
wallet reads ───────────────> outputs
After this commit:
chaintopology ──────────────> our_outputs
└─────────────> outputs (downgrade mirror)
bwatch ─────────────────────> our_outputs
└────────────────────> outputs (downgrade mirror)
wallet still reads ─────────> outputs
Make each existing chaintopology writer update both representations of
its UTXO state:
- wallet_add_utxo and wallet_add_onchaind_utxo insert into both tables;
- db_set_utxo updates reservations in both tables;
- wallet_confirm_tx updates confirmation heights in both tables; and
- wallet_outpoint_spend marks outputs spent in both tables.
Keeping each pair of writes in the existing helper makes the downgrade
mirror explicit without duplicating SQL at its callers. Reads remain on
legacy `outputs` until the following commit switches them to our_outputs.
Co-authored-by: Cursor <cursoragent@cursor.com>
This is a database refactoring commit in Core Lightning. It makes the wallet write UTXO (unspent transaction output) state to a new table called our_outputs in addition to the legacy outputs table, while reads still use the old table. The goal is to prepare for a future migration, not to fix an active security bug. There is no direct evidence in the commit that this change itself creates or fixes a vulnerability.
b3717085 · Jul 27, 2026 · 1 fileInformational 15tests: add our_tables backfill upgrade test
Upgrade a pre-bwatch snapshot db and check the migration mirrored
outputs/transactions into our_outputs/our_txs, listfunds still reports
the old UTXOs, and the wallet can receive and withdraw new funds.
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit only adds a new automated test. It checks that an older Core Lightning database snapshot upgrades correctly: legacy wallet tables are copied into newer tables, existing funds remain visible, and the wallet can still receive and send money after the upgrade. There is no code change to the actual wallet or database migration logic.