Core Lightning

fetchinvoice: handle weird labels in recurrence_label parameter.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

libplugins: JSON ids are always strings.

We used to handle it being a literal, but this was removed in
73fc9b0c2a162c98703baf618abf944c791bb879 (v25.05) so we don't need to handle that at all.

Not using the raw JSON means we handle weird methodnames by replacement: otherwise we would
not match the responses. Only an issue for commando, where the command would time out
rather than report "Unknown method".

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Add unit tests for str_to_u64

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

multiwithdraw: use unique ids on requests.

Shades of `efacada7ddf` which did the same thing in multifundchannel:
(ab)used the id, which being a string, gave and id of 34 (").

Also clean up the leftover assert in multifundchannel.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

askrene: add APIs for "impressions" which are *relative* constraints.

Normal constraints are clamps on min/max caused by failed payments:
min for the channels that succeeded, max for the channel which failed.

Impressions are the results of successful payments, which alter both
min and max (negatively in the forward direction, positively in the
reverse).

impression: n
1. An effect, feeling, or image retained as a consequence of experience.
2. A vague notion, remembrance, or belief.
3. A mark produced on a surface by pressure.

Unlike constraints, this is the result of our own effect on the network: they're related
but different enough to get their own API and terminology.

The name conveys both we made an impression on the channel, and that
the results are a bit vague (due to other changes since then, which we
won't know about).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: JSON-RPC: `askrene` layers now contain "impressions" representing the effects of successful payments we made through channels.

pytest: add tests for what we want askrene to do.

It diagnoses if the *total capacity* of the source/dest are
insufficient, but not if the *known capacity* is.

So we get:

The shortest path is 103x1x0->105x1x0, but 103x1x0/1 layer auto.localchans says max is 77704899msat

Whereas it would be better to do:

We know from auto.localchans that source has maximum capacity xxx msat (in 1 channels)

Similarly for the destination, we get:

The shortest path is 103x1x0->105x1x0, but 103x1x0/1 layer auto.localchans says max is 77704899msat

askrene: test explain: fix flake

Fix test_explain_source_dest_failure by increasing the amounts by a
factor of ten, which reduces the relative significance of on-chain fees
on the commitment transaction.

This used to fail on liquid-regtest due to insufficient liquidity on
l2->l4 to prevent channel starvation.
At line
```
l1.rpc.xpay(l4.rpc.invoice('30000sat', 'test_explain_simple_failures2', 'test_explain_simple_failures2')['bolt11'])
```
we would get
```
lightningd-2 2026-07-06T11:29:09.973Z DEBUG 02287bfac8b99b35477ebe9334eede1e32b189e24644eb701c079614712331cec0-channeld-chan#3: Adding HTLC would leave us only 19454000msat: we need 25281sat for another HTLC if fees increase from 7500perkw to 13906perkw
lightningd-2 2026-07-06T11:29:09.973Z DEBUG 02287bfac8b99b35477ebe9334eede1e32b189e24644eb701c079614712331cec0-channeld-chan#3: Adding HTLC 0 amount=30000000msat cltv=130 gave CHANNEL_ERR_CHANNEL_CAPACITY_EXCEEDED
```

Changelog-None

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

add a test for downgrading askrene datastore

Also trigger a db upgrade in the v26.09 so that impressions can be
removed by the downgrade tool.

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

lightningd: 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

lightningd: test for very long log entries

We were using vasprintf to generate the log line and then using free to
deallocate the string. However, in the case of a very long log line
a new pointer was created with tal_fmt and then tried to use free on it.

This was introduced in commit: 4d8f923a9a1468b8987dbb48e8fc988747f8c62f

```
free(): invalid pointer
lightningd: FATAL SIGNAL 6 (version v26.06-21-gebc5dc2)
0x563dab20be43 send_backtrace
common/daemon.c:38
0x563dab20becd crashdump
common/daemon.c:83
0x7f0cf0c96def ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7f0cf0ceb95c __pthread_kill_implementation
./nptl/pthread_kill.c:44
0x7f0cf0c96cc1 __GI_raise
../sysdeps/posix/raise.c:26
0x7f0cf0c7f4ab __GI_abort
./stdlib/abort.c:77
0x7f0cf0c80290 __libc_message_impl
../sysdeps/posix/libc_fatal.c:134
0x7f0cf0cf5464 malloc_printerr
./malloc/malloc.c:5832
0x7f0cf0cfa41b _int_free_check
./malloc/malloc.c:4560
0x7f0cf0cfa41b _int_free
./malloc/malloc.c:4692
0x7f0cf0cfa41b __GI___libc_free
./malloc/malloc.c:3476
0x563dab19be60 logv
lightningd/log.c:688
0x563dab19c0bc log_
lightningd/log.c:728
0x563dab1c1047 plugin_log_handle
lightningd/plugin.c:530
0x563dab1c5801 plugin_notification_handle
lightningd/plugin.c:609
0x563dab1c5a9a plugin_read_json
lightningd/plugin.c:753
0x563dab2388a5 next_plan
ccan/ccan/io/io.c:60
0x563dab238c83 do_plan
ccan/ccan/io/io.c:422
0x563dab238d3c io_ready
ccan/ccan/io/io.c:439
0x563dab239e5b io_loop
ccan/ccan/io/poll.c:470
0x563dab194399 io_loop_with_timers
lightningd/io_loop_with_timers.c:22
0x563dab199c29 main
lightningd/lightningd.c:1480
0x7f0cf0c80ca7 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f0cf0c80d64 __libc_start_main_impl
../csu/libc-start.c:360
0x563dab169020 ???
_start+0x20:0
0xffffffffffffffff ???
???:0
```

Changelog-None

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

lightning-hsmtool: Fix getsecret does not show mnemonic after typing passphrase

Changelog-Fixed: `lightning-hsmtool`: `getsecret` does not show mnemonic after typing passphrase

tests: add regression test for hsmtool commands with passphrase

lightningd: update graceful notifications when HTLC states change

The graceful command notifies watchers about the closest-expiry HTLC,
including its state, whenever that message changes. But nothing
re-evaluated the message when an HTLC changed state: only HTLC
removal, peer disconnect and another graceful invocation re-ran the
check. If graceful was invoked while a commitment dance was in
flight, the initial notification named a transient state (e.g.
RCVD_ADD_REVOCATION) and no follow-up ever announced the settled
state.

test_graceful_htlc waits for exactly that follow-up (since 6994681ae
"flake: Fix test_graceful_htlc to be flexible for notifs"), so it
times out whenever graceful catches the dance mid-flight, which
valgrind CI runs make likely. In one CI failure graceful caught the
outgoing HTLC in RCVD_ADD_REVOCATION, the dance completed 600ms
later, and no notification followed for the remaining 180 seconds.

Re-check graceful progress in the handlers that advance HTLC states
(peer_sending_commitsig, peer_got_commitsig, peer_got_revoke). The
check is a no-op unless a graceful command is outstanding, and
identical messages are already deduplicated.

The dance now generates transient-state notifications, so rewrite the
test to match expected notifications as an ordered subsequence
instead of by exact index. That also removes two accidents the old
indexing depended on: the RCVD_ADD_REVOCATION special case (the
settled state now always notifies), and the wait for a notification
after l1's disconnect, which was really satisfied by the graceful(1)
call's own initial notification arriving on the shared rpc socket --
the disconnect itself never notifies, since the message text
describes the still-connected peer l3 and does not change.

Fixes: https://github.com/ElementsProject/lightning/issues/9219
Changelog-Fixed: JSON-RPC: `graceful` notifications now update when a pending HTLC changes state.

xpay: add traces for payments

Produce traces (see common/trace.h) for every payment in order to gather
statistics about the duration of a full payment execution.

Changelog-None

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

xpay: added subtrace to measure getroutes

Changelog-None

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

xpay: add sub-trace to measure injectpaymentonion

Changelog-None

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

wally: 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.

tests: 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

Dockerfile: 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.

CI: 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

pyln-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

tests: 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

lightningd: 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.

flake: fix in-flight statuses causing flakyness by waiting for all xpay-n layers to be removed from askrene before checking settlement outcome

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>