Core Lightning

wallet: make datastore helpers self-wrap a wallet transaction

The four wallet_datastore_{get,create,update,remove} helpers used to
require the caller to be inside a wallet transaction; otherwise the
underlying db_prepare_v2 fatals at db/utils.c:103 with "Attempting to
prepare a db_stmt outside of a transaction".

watchman persists its pending bwatch ops through these helpers from
plugin callbacks that run outside any transaction, so wrap one on
demand.

Co-authored-by: Cursor <cursoragent@cursor.com>

lightningd: dispatch bwatch wallet scriptpubkey watches

Register the wallet/spk owner prefix with watchman so scriptpubkey
matches and reverts reach the wallet handlers introduced in the previous
commit. Document the owner suffix format alongside the dispatch entry.

Co-authored-by: Cursor <cursoragent@cursor.com>

wallet: handle reorgs for our_outputs/our_txs by hand

The legacy tables rely on their blocks(height) ON DELETE SET NULL
foreign keys to mark rows unconfirmed/unspent when a block is reorged
out. our_outputs/our_txs deliberately carry no blocks FK (bwatch does
not maintain a blocks table), so block disconnect and rollback must
demote their blockheight/spendheight fields explicitly.

Demote, never delete: a row also carries state the chain cannot
re-deliver (reserved_til, onchaind close metadata), and this path runs
not just on real reorgs but on every startup, when chaintopology
invalidates its rescan window. Rediscovery re-promotes the row via
wallet_add_our_output / wallet_transaction_add; a tx that never
re-confirms just stays unconfirmed and unspendable.

Co-authored-by: Cursor <cursoragent@cursor.com>

wallet: record bwatch-discovered wallet outputs

Add the wallet helpers and watch handlers that turn a bwatch
scriptpubkey match into our_txs and our_outputs rows. They validate
the matching output, notify invoice accounting, record confirmed
deposits, and install watches for later spends.

The watch_revert handler demotes the rows back to unconfirmed (the 0
sentinel) rather than deleting them: a row also carries state a
rediscovery cannot restore (reserved_til, onchaind close metadata),
and the still-armed watches re-promote it if the tx confirms again.
This matches the legacy tables, whose blocks(height) foreign keys
demote rows to NULL when the block row is removed.

Unlike got_utxo(), this path does not write transaction_annotations:
nothing reads per-transaction annotations anymore, so only the legacy
scanner keeps populating them (for downgrade, like the other legacy
tables).

The watchman dispatch entry is wired in the following commit. Keep this
path alongside got_utxo() and wallet_transaction_add(): the legacy
scanner must continue populating outputs and transactions for one release
so downgrades do not require a rescan.

Co-authored-by: Cursor <cursoragent@cursor.com>

wallet: add our_outputs + our_txs schema migrations

The next commits move wallet UTXO and tx tracking off chaintopology and
onto bwatch. bwatch doesn't maintain a blocks table, but the legacy
utxoset, transactions and channeltxs tables all have FOREIGN KEY
references into blocks(height) (CASCADE / SET NULL), so we can't just
retarget the existing tables.

Instead, introduce parallel tables (our_outputs, our_txs) without the
blocks(height) FK. The new bwatch-driven code writes only to these,
the legacy tables stay populated by the existing code path during this
release so downgrade still works, and a future release can drop them
once we're past the downgrade window.

Losing the FK also changes what NULL means. In the legacy tables a
NULL blockheight was never written by hand: the ON DELETE SET NULL
trigger produced it when a reorg deleted the block row. These tables
have no such trigger, so unconfirmed is stored as blockheight 0
(NOT NULL) instead, for three reasons:

- everything feeding these tables already speaks u32-with-0: watchman
notifications carry blockheight as a required JSON number, and
wallet_transaction_height() has always returned 0 for unconfirmed,
so values bind straight through without a NULL/non-NULL branch at
every read and write site;

- integer comparisons keep working: the unconfirmed->confirmed
promotion is a single "WHERE blockheight < ?" (0 sorts below any
real height) and reorg rollback is "SET blockheight = 0 WHERE
blockheight >= ?", where a NULL row would match neither;

- it removes the footgun the legacy code warned about ("Note:
blockheight=NULL is not the same as is NULL!"), where lookups had
to branch between "= ?" and "IS NULL".

The same logic gives txindex 0 = unconfirmed/unknown (a *confirmed*
txindex of 0 means coinbase, which blockheight disambiguates) and
reserved_til 0 = not reserved. NULL survives only where 0 is a real
value or genuinely ambiguous: spendheight (NULL = unspent),
channel_dbid, commitment_point.

Schema only here — wallet handlers that write into these tables and the
backfill from outputs/transactions land in subsequent commits.

Co-authored-by: Cursor <cursoragent@cursor.com>

wallet: mirror bwatch writes into legacy outputs table

The bwatch path writes wallet UTXOs to our_outputs while the legacy
`outputs` table is what a downgraded binary reads. Mirror every
our_outputs write (insert, spend, unspend-on-spend-revert, reservation)
into `outputs` so a downgrade for one release needs no copy-back or
rescan. Reorg demotion needs no mirror: the legacy rows are demoted by
their blocks(height) foreign keys when chaintopology removes the block.
The mirroring stops in the release that removes chaintopology, freezing
all the legacy tables at the same height.

The spend mirror guards its spend_height the same way the insert guards
confirmation_height: outputs.spend_height has a foreign key on
blocks(height), which only chaintopology populates, and bwatch can
deliver the spend before chaintopology has processed that block.
Record NULL in that case (status already marks the row spent) and let
chaintopology's own spend pass fill in the height.

The wallet still reads from `outputs`; switching reads over to
our_outputs comes next.

Co-authored-by: Cursor <cursoragent@cursor.com>

pyln-testing: wait for listen port release before starting a node

A node's connectd is a separate process holding the listen socket,
and on shutdown it exits on its own schedule after lightningd itself
is gone -- under valgrind, its teardown can lag by tens of seconds.
If a test restarts the node in that window, the new connectd fails
with 'Address already in use', lightningd exits, and the test times
out waiting for 'Server started with public key'. Seen in CI in
test_emergencyrecoverpenaltytxn, where the port was still held 37
seconds after the old connectd began shutting down.

The filesystem port locks don't cover this: they keep other workers
from reserving the port, but the restarting node owns its reservation
both times; nothing waits for the old connectd to actually release
the socket.

Before launching lightningd, bind-probe the node's port (with
SO_REUSEADDR, matching connectd, so TIME_WAIT sockets don't count as
in use) and only proceed once the bind succeeds.

Fixes: #9354
Changelog-None

plugins: recover awaiting channels after init

plugins: defer spenderp awaiting-channel recovery

wallet: Read the max_index for addresses from the in-memory cache

wallet: Update the max_index cache when issuing new addresses

The write-through cache added for the address max_index was only kept in
sync in wallet_can_spend(). wallet_get_newindex() still read and wrote
the bip32_max_index/bip86_max_index db vars directly, leaving the
in-memory cache stale after every newaddr. Since listaddresses and the
rescan window now read from that cache, freshly issued addresses were
invisible until the next restart (and wallet_can_spend could even write a
stale, lower value back to the db).

Route all reads and writes through wallet_max_addr_index() and
wallet_set_max_addr_index() so the cache and the db never diverge.

Changelog-None
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

wallet: Cache the max_index for bip32 and bip86 address indices

We were looking up the index for the addresses to scan, twice, for
every single output, for every single TX for every block. No wonder
that was being slow.

Changelog-Fixed: wallet: Addressed a performance regression during blockchain scans

docs: Fixing Ubuntu installation docs
- updated release tag references
- removed protobuf-compiler dependency
- removed rustup default installation, changed it to only for Ubuntu <25.10 (rust <1.85)
- added note about tzdata config halting execution

CI: set readme branch name to stable

Changelog-None

lightningd: store raw failure message so waitsendpay always has raw_message

If a payment's HTLC failure completes before waitsendpay is called,
wait_payment() rebuilds the error from the database, which did not
persist the raw BOLT4 failure message: a 2019 FIXME in that path set
fail->msg = NULL, silently dropping raw_message from the error data.
This is the cause of the test_error_returns_blockheight CI flake -
the test loses the race occasionally, calls waitsendpay after the
failure has landed, and KeyErrors on the missing raw_message.

Add a failmsg column to the payments table (with a downgrade drop),
persist fail->msg when recording the failure, and read it back in
wait_payment. Local and self-payment failures store NULL as before,
since no onion failure message exists for them; failed payments
recorded before this migration also return NULL, matching the old
behavior.

The flaky test now also calls waitsendpay a second time, which
deterministically takes the database-replay path, so the regression
is covered without any timing dependence.

Changelog-Fixed: JSON-RPC: `waitsendpay` error data now includes `raw_message` even when the payment already failed before the command was called.
Fixes: #9341

nix: fix `nix build` and simplify NixOS install docs

CLN's ./configure detects Python through `uv` (see default_python in
configure), which the cln derivation does not provide, so PYTHON ends up
empty and the build fails when a Makefile step runs
`$(PYTHON) devtools/blockreplace.py`. Set PYTHON=python3 in preConfigure
(the derivation already ships a python3 with mako/grpcio-tools) and add
blockreplace.py to patchShebangs.

With `nix build` working again, replace the stale poetry-based NixOS section
of the install guide with the flake commands (nix build / nix run /
nix profile install / nix develop). Verified in a nixos/nix container:
nix build ".?submodules=1" produces lightningd/lightning-cli v26.06.1.

Changelog-Fixed: nix: the flake build (`nix build`) no longer fails because ./configure cannot detect Python.

tests: fix broken race handler in test_funding_external_wallet_corners

d09d0112f ("pytest: handle v fast disconnect during
test_funding_external_wallet_corners()") wrapped the reconnect in
try/except to tolerate the "disconnected during connection" race, but
the assert checks the substring against err.error, which is the whole
error dict ({'code': 402, 'message': ...}). `in` on a dict tests its
keys, so the assert fails exactly when the race it is meant to
tolerate occurs.

Seen in CI, where connect raised code 402 and the handler itself then
asserted:

E assert 'disconnected during connection' in {'code': 402,
'message': 'disconnected during connection'}

Match against err.error['message'] instead, as the equivalent handlers
in test_plugin.py and test_misc.py already do.

Changelog-None

release: CHANGELOG and version bumps for v26.06.6

tests: fix flaky test_simple_close_dust_output_omitted mempool race

The test snapshots getrawmempool() and then calls getrawtransaction()
on each txid. In simple close both peers broadcast conflicting closer
txs: here l2's tx pays only 400sat fee (its entire 400sat balance goes
to fees since its own output is dust) while l1's pays 3375sat, so l1's
tx can RBF-replace l2's between the snapshot and the fetch. The
getrawtransaction() call on the replaced txid then fails with error -5
(No such mempool or blockchain transaction). A CI failure showed
exactly this ordering: l2 broadcast its closer tx, l1's higher-fee tx
replaced it 14ms later, and the test's per-txid fetch raced the
replacement.

Retry the whole snapshot-and-check loop when a txid vanishes
mid-iteration, keeping the single-output assertion hard. This is the
same class of mempool race fixed for test_simple_close_delay_broadcast
in 5ae0705f2 ("tests: fix flaky test_simple_close_delay_broadcast
mempool race").

Changelog-None

tests: compare medians in test_no_delay instead of means

test_no_delay compares mean round-trip times with a 3-standard-error
margin. On loaded CI runners the trip-time distribution is heavy-tailed
enough that the margin can exceed the entire effect being measured: in
the #9329 failure the margin came to 45.3ms while the true Linux effect
is one delayed-ACK quantum (40ms - the docstring's ~200ms figure is
other platforms), so the assertion failed with the effect cleanly
present (saving 44.6ms).

The stall shifts the whole distribution by the quantum, so the median
difference detects it regardless of the noise tail. Compare medians,
requiring half the quantum on Linux; on platforms without a measurable
stall keep the not-slower sanity check with the same slack.

Fixes: #9329
Changelog-None

doc: Fix spliceout description

Changelog-None.

Fix: SIGINT was ignored by the cln docker container

Changelog-Fixed: Fix: SIGINT was ignored by the cln docker container

tests: fix flaky test_sql blockheight race

The test mines ~106 blocks (channel close, replacement channel
funding, then generate_block(99)) immediately before making three
payments, without waiting for the nodes to process those blocks.
Under valgrind the paying node can lag far behind bitcoind when the
payments start, so it builds onions whose cltv expiries the caught-up
peers reject. Two CI failures showed both shapes of the race:

In one run l1 was ~40 blocks behind (l2/l3 at block 210, l1 still
catching up), so l2 failed the forward: "Expiry cltv 181 too close to
current 210" (expiry_too_soon). Since the error came from the
invoice's route-hint channel, xpay disabled it and the payment failed
hard: "All 1 channels to the destination are disabled."

In the other run l1 was only a few blocks behind, so l3 failed the
final hop: "Expiry cltv too soon 211 < 210 + 5". xpay's
waitblockheight retry then succeeded, but the failed first attempt
left status 'failed' in the forwards row the test later asserts is
'settled'.

The test paid with pay until 7f6a33394 ("pytest: use xpay, not pay in
misc tests."); pay took its start height from bitcoind's headercount
and tracked the node's chainlag, so a lagging node still built onions
valid at the true chain tip. xpay uses its own notification-fed
blockheight plus one block of slack, which is why this only started
flaking recently.

Sync the nodes' blockheights before paying, as other tests do after
mining bursts.

Changelog-None

tests: fix flaky listchannels doc example by waiting for l3 to disable its l4 channel

The Update examples in doc schemas CI job intermittently fails with the
l3->l4 direction of their channel flipping between disabled and enabled
in the regenerated listchannels example (channel_flags 3 vs 1, active
false vs true).

l4's database is deleted to generate the recoverchannel example, after
which l3 disables its side of the l3-l4 channel. That disabling
channel_update is emitted lazily (via an error reply or the gossip
refresh timer), so whether it lands in l3's gossip store before the
listchannels snapshot is a race; the committed example captured the
post-disable state. Wait for the disable explicitly, as the script
already does for the post-close listchannels races.

Fixes: #9327
Changelog-None

docs: fixing Fedora installation

- `dnf`: switched from `groupinstall` to `group install` which is supported both by `dnf4`and `dnf5` which is used starting from fedora41
- added `openssl` and `openssl-devel` dependency
- `uv` install added, which the build now requires
- bumped latest version
- use `uv` to tun the `make`