Core Lightning

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`

pyln-proto: temporarily switch to coincurve-cp314-fix

Using `uv.sources` / `uv.index` does not work when publishing to pypi.

Instead i forked coincurve master, published all the wheels as coincurve-cp314-fix
v22 with fixes to make it work on python 3.14

Changelog-None

renepay: fix CLTV value for the first hop

Changelog-Fixed: renepay: fix the computation of the CLTV for the first hop, it was double counting the current blockheight leading to too 900k blocks into the future.

Signed-off-by: Lagrang3 <lagrang3@protonmail.com>

renepay: add test to check for wrong CLTV computation

Changelog-None

Signed-off-by: Lagrang3 <lagrang3@protonmail.com>

tests: fix flaky reckless tests by waiting for the canned github server

The canned_github_server fixture Popens a Flask server and never
waits for it to start listening; the git repository setup between the
Popen and the yield usually gives it enough time. Under CI load it
can lose that race: a valgrind-shard failure shows test_search's
first reckless invocation getting connection refused within a second
of the test starting, while Flask's "Running on http://127.0.0.1:..."
banner only appears in the log after the test had already failed.

Wait for the port to accept connections before yielding, and fail
loudly if the server process dies instead of coming up.

Changelog-None

msggen: new rust types for `sat` and `sat_or_all`

Also stop serializing amounts as string with msat suffix in cln-rpc
and serialize them as a raw number instead, like CLN does it

Changelog-None

lightningd: reject a channel that reuses an existing funding outpoint

A v1 channel_id is derived solely from the funding outpoint, so two
channels funded by the same outpoint would share a channel_id. When a
peer completes a second funding using an outpoint we already have a
channel for, refuse it and drop the connection instead of committing a
second channel with a colliding channel_id.

Add find_channel_by_funding_outpoint() to look up an existing channel by
its funding outpoint.

connectd: handle an already-connected subd gracefully

peer_connect_subd asserted that the subd had no connection yet. Replace
that assertion with defensive handling: if a connection is already
attached for this channel_id, keep it and close the incoming fd. This
avoids aborting connectd in the unexpected case where a second fd
arrives for a subd that already has one.

tests: test RBF stops after closed tx is confirmed

chaintopology: fix RBF loop that never stops after replacement tx confirms

After consider_onchain_rebroadcast() creates a higher-fee replacement,
rebroadcast_txs() calls refresh() which updates otx->tx in-place, but
the confirmation guard still queries the original otx->txid (the map key):

if (wallet_transaction_height(topo->ld->wallet, &otx->txid))
continue;

Because the original tx was never mined (only the replacement was),
wallet_transaction_height always returns 0 and the RBF loop fires on
every subsequent block forever, even after the channel is fully resolved.

Fix: compute cur_txid from the current otx->tx before the guard. This
naturally reflects any replacement made by a prior refresh() call, so
wallet_transaction_height finds the confirmed txid and skips the entry.

otx->txid (the hash-map key) is intentionally left unchanged: mutating
the key in-place while the entry lives in the map would corrupt the table.

Changelog-Fixed: chaintopology: stop the on-chain RBF rebroadcast loop once a fee-bumped replacement transaction confirms; previously the loop kept firing on every new block forever.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

tests: test bookkeeper correctly accounts for splice in/out

tests: fixing flake8 + fixed fees in spliceout

docs: updated Arch linux source installation instructions

Also removed python plugin instructions, they can not be generalized and this repo no
longer has any python plugins that need extra dependencies in production.
Python plugins from the plugins repo have their own documentation.

Changelog-None

build-release: fix VERSION build-arg and add --no-push for the docker target

Pass the computed VERSION as a build-arg, mirroring the docker-release workflow. Without it the container's VERSION is set-but-empty, `VERSION ?=` in the Makefile won't overwrite it, the git-describe fallback never runs, and `make install-program` fails with "git is required for generating version information".

Also add --no-push, so a release captain can do a full test build without publishing elementsproject/lightningd:$VERSION and :latest (the target always runs `docker buildx build --push`, since multi-arch images cannot be --load'ed into the classic docker store). The build only populates the builder's cache; a subsequent run without the flag pushes from cache quickly.

Co-Authored-By: Claude <claude@users.noreply.github.com>

pyln-proto: use coincurve 21 for python <=3.13 and add self-compiled wheels for python 3.14

coincurve 20 is broken for all python versions since it now pulls in a transient dependency that turned
a warning into an error:

```
× Failed to build `coincurve==20.0.0`
├─▶ The build backend returned an error
╰─▶ Call to `hatchling.build.build_wheel` failed (exit status: 7)

[stderr]
ERROR: Use build.verbose instead of cmake.verbose for scikit-build-core >= 0.10

hint: This usually indicates a problem with the package or the build environment.
help: `coincurve` (v20.0.0) was included because `cln-meta-project` (v0.1.0) depends on `pyln-proto` (v26.6.2) which depends on `coincurve`
```

coincurve 21 does not have this issue but it does have another issue with python 3.14:

```
Resolved 1 package in 289ms
× Failed to build `coincurve==21.0.0`
├─▶ The build backend returned an error
╰─▶ Call to `hatchling.build.build_wheel` failed (exit status: 1)

[stderr]
Traceback (most recent call last):
File "<string>", line 11, in <module>
wheel_filename = backend.build_wheel("/home/user/.cache/uv/builds-v0/.tmpfcwWrQ", {}, None)
File "/home/user/.cache/uv/builds-v0/.tmpNmyA8G/lib/python3.14/site-packages/hatchling/build.py", line 58, in build_wheel
return os.path.basename(next(builder.build(directory=wheel_directory, versions=["standard"])))
~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/.cache/uv/builds-v0/.tmpNmyA8G/lib/python3.14/site-packages/hatchling/builders/plugin/interface.py", line 149, in build
build_hook.initialize(version, build_data)
~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
File "/home/user/.cache/uv/sdists-v9/pypi/coincurve/21.0.0/sA4L50tQMHeL37XJdHnME/src/hatch_build.py", line 34, in initialize
raise RuntimeError(message)
RuntimeError: Expected exactly one LICENSE file in cffi distribution, got 0

hint: This usually indicates a problem with the package or the build environment.
```

coincurve for python 3.14 is fixed upstream but there is no release yet, so we use self-compiled wheels just for python 3.14

Changelog-None

Improve reliability of wait_and_check_bitcoind

Changelog-Fixed: Fixed spurious bitcoind startup failures by retrying bitcoin-cli -rpcwait checks when RPC briefly fails.