Core Lightning

connectd: 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)

pytest: check the SOCKS5 request for a maximum-length hostname

connectd assembles the SOCKS5 CONNECT request in a fixed buffer, but never
checks that the hostname fits it. Add a test that a maximum-length proxied
hostname produces exactly the request it should, with connectd still alive
afterwards.

Changelog-None

(cherry picked from commit 6ecead49248408172489e3b77c34b44994b25414)

lightningd: restart onchaind when a watched tx is reorged out

onchain_tx_watched() kills the owner on a zero-depth callback, which frees
onchaind and every watch parented to it, assuming something will restart it.
Nothing does: onchaind_funding_spent() is the only launch site, and the funding
outpoint watch doesn't fire again when the reorg removed a descendant of the
commitment rather than the commitment itself. So the channel is unwatched
until the next restart: no new claim is proposed, no spend of a remaining
output is seen, and it's never resolved.

Reuse the startup replay path, deferred out of the watch callback since we
can't add watches while the txwatch table is being iterated.

Changelog-Fixed: lightningd: restart `onchaind` after a reorg of a transaction it was watching, instead of leaving the channel unmonitored until restart.
(cherry picked from commit 18de31a0d7cd2dd4880c206da9af36ae97ec2567)

pytest: onchaind must come back after a reorg of a tx it was watching

A zero-depth callback frees onchaind and every watch parented to it, and
nothing restarts it unless lightningd itself restarts. Also test the
commitment tx reorg, which is handled correctly today and must stay that way.

Changelog-None

(cherry picked from commit 2c019958f3e84a805b65711f24c40a61ea8ba8b0)

common: 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)

lightningd: let an onchain preimage beat an unfinished outgoing failure

onchain_fulfilled_htlc() skipped any outgoing HTLC with failmsg or
failonion set. Those get set at RCVD_REMOVE_COMMIT, but remove_htlc_out()
doesn't free the htlc_out until RCVD_REMOVE_ACK_REVOCATION: until then the
removal isn't final and the HTLC can still be in a commitment, so BOLT #2
says the preimage wins.

Only skip if we already failed the incoming HTLC, which is the case this
check was written for, and clear the failure before recording the preimage,
since htlc_out_check() doesn't allow both.

Changelog-Fixed: lightningd: fulfill the incoming HTLC when we learn the preimage onchain, even if the outgoing HTLC had an unfinished failure.
(cherry picked from commit ce9b9c6b77bda95832bae0e283adcde79c8744e8)

hsmd: return io_close when the handler reports an error

When libhsmd rejects a request it returns NULL; close the client then,
instead of from hsmd_status_bad_request. Share the report path in
report_bad_req so it cannot drift from bad_req_fmt.

Changelog-Fixed: print the commitment index in "bad commit secret" instead of a stack address
(cherry picked from commit 869bd4da44df842d5f54e0370e95bffa7cf5a8b4)

tests: fixe test_multichan_stress flake

```
def send_many_payments():
passes = 0
fails = 0
# Make sure we try many times, and get at least one pass and fail.
while passes == 0 or fails == 0 or passes + fails < 30:
inv = l3.rpc.invoice(100, "label-" + str(passes + fails), "desc")
l1.rpc.sendpay(route, inv['payment_hash'], payment_secret=inv['payment_secret'])
time.sleep(0.05)
try:
l1.rpc.waitsendpay(inv['payment_hash'])
passes += 1
except RpcError:
fails += 1
pass

# Send a heap of payments, while reconnecting...
fut = executor.submit(send_many_payments)

for _ in range(30):
l3.rpc.disconnect(l2.info['id'], force=True)
time.sleep(0.1)
l3.rpc.connect(l2.info['id'], 'localhost', l2.port)
> fut.result(TIMEOUT)
```

The while loop would somtimes go infinitely long if no payments fail.

Changelog-None

tests: fix test_bwatch_spk_watch_reorg_demotes_outputs flake

We need to wait for bwatch to see the deposit block or it won't see a
reorg.

```
assert l1.db_query('SELECT COUNT(*) AS c FROM outputs')[0]['c'] == 1

# Reorg the deposit block away. Deprioritize the returned mempool tx
# (same trick as simple_reorg) so the replacement blocks don't just
# re-confirm it.
bitcoind.rpc.invalidateblock(bitcoind.rpc.getblockhash(deposit_height))
memp = bitcoind.rpc.getrawmempool()
assert txid in memp
for t in memp:
bitcoind.rpc.prioritisetransaction(t, None, -1000000)
bitcoind.generate_block(2)

> l1.daemon.wait_for_log(r'Reorg detected', timeout=60)
```

Changelog-None

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

pytest: onchain payment to an amountless invoice's fallback address

invoice() attaches a fallback address whatever the amount, so "any"
invoices get one too. details->msat is NULL for those, and we never
covered that case.

Changelog-None

(cherry picked from commit c5e8064ca3eb5000d9030dd96391fa20c9763c8b)

pyln-testing: give btcproxy a port and choose better ports

btcproxy was using port 0 by default without going through our port
reservation logic, so it may have caused "Address already in use"
issues. It was also binding to 0.0.0.0, so on all addresses. For the
port reservations to work we use 127.0.0.1 here too.

We choose from outside the source-port range of ports in hopes of
avoiding more port bind race conditions.

Changelog-None

tests: fix flake in test_important_plugin from sync read EBADF

When an important plugin dies, lightningd shuts down while other plugins
may still be mid-sync-RPC during init. If rpc_open() fails because the
RPC socket is already gone (logging "Could not connect ... Connection
refused"), sync_req() proceeds with sync_fd == -1, and the subsequent
read(-1) fails with EBADF, producing the BROKEN message:

Reading sync lightningd: Bad file descriptor

This is the same intentional shutdown that already produces the
whitelisted "Reading sync lightningd: Connection reset by peer" (or a
clean EOF exit); the errno merely differs by the connection race. Add
"Bad file descriptor" to the broken_log whitelist so the test no longer
fails at teardown on this race.

Changelog-None

lightningd: Target a lower closing fee

This saves sats in certain scenarios by preferring a lower closing fee.

Changelog-Changed: lightningd: the maximum fee accepted for a mutual close is now bounded by the unilateral-close feerate.
(cherry picked from commit fc646eabaae4d01d299cd765f51d6a10811257db)

channeld: Add helpful warning message during reestablish

Adding a warning message makes it clear why the reestablish process would fail.

Changelog-None

(cherry picked from commit 47c7280914abe863efdd2d031cafb36bbfd411ef)

wallet: 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)

closing: sanity-check close transactions

By policy we don't trust our subdaemons (much). Before storing and
broadcasting a close tx from a (simple)closing subdaemon, confirm it's a
well-formed close of this channel: one input spending our funding outpoint,
closing-shaped locktime/sequence, and outputs to known shutdown scripts (or a
zero-value OP_RETURN with option_simple_close).

Share it between the simple and legacy close paths, and apply the same shape
rule in onchaind.

(cherry picked from commit 220f0b919a157f8ba164cdc374a18fa9d5ec32ae)

channeld: Add clearer warning messages for `start_batch`

Add an explicit message for `start_batch` when the batch size is below the minimum.

Changelog-None

(cherry picked from commit e09ba5afbf13b31be16b16668cbce781e7ce62bd)

db: tidy db_col_psbt NULL handling

Return early for a NULL column like the sibling db_col_* helpers, and
only parse and set the version when there is actual data to work with.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Changelog-None

(cherry picked from commit d6f8cc32eddb5f9aaba4c0561f94944b550cb61f)

wallet: bound-check shachain_known pos on load

Keep the loaded pos within the known[] array like the other defensive
checks in the channel loader, so a malformed row fails loudly instead of
indexing out of range.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Changelog-Fixed: wallet: an out-of-range shachain index in the database is now rejected at load instead of read out of bounds.
(cherry picked from commit fdd7b11e9f38eb2d3fa5515c00e64f0ad17d63fc)

make: skip extract-bolt-csv if bolts are absent

`check-source` -> `check-wire-format` unconditionally ran
`extract-bolt-csv`, which failed when `../bolts` was not checked out:

```
/bin/sh: 1: .tmp.lightningrfc/tools/extract-formats.py: not found
make: *** [wire/Makefile:54: wire/peer_wire.csv.raw] Error 127
```

Skip it via `bolt-precheck` when `.tmp.lightningrfc` is missing,
matching the `bolt-check` pattern.

Changelog-None

ci: bind GPG keyid via env before shell in release-publish

Per review: keyid comes from crazy-max/ghaction-import-gpg parsing a
repo-owned secret, so practical risk is low; bind it anyway so every
run: block in the release path follows the same env-first pattern and
the invariant does not depend on that action's output staying trusted.

Made-with: Cursor
Signed-off-by: SashaMIT <sash.t.mitchell@gmail.com>

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

channeld: split the feerate we'll pay from the one we'll accept

The previous commit clamped our own fee source on the way in. This is
the counterpart for the other side of the channel: our peer's estimator
can be just as broken as ours, and we are the only one in a position to
notice before their money is gone.

`splice_accepter` only rejected a remote `funding_feerate_perkw` below
feerate_min; there was no upper bound at all. The downstream safeguard
in check_balances only inspects the accepter's own fee contribution, and
since accepter_relative is 0 our weight is nil, so that check never
fires. A peer whose estimator has gone haywire can therefore drive a
splice at an arbitrary feerate and we will cheerfully sign it, even
though the fee comes out of their channel balance. Refusing costs us
nothing and saves them from committing their funds to a transaction they
did not mean to pay for.

Reject anything above feerate_max, and apply the same bound in
handle_splice_init so that we extend the same courtesy in reverse: if
our own estimator is the broken one, we catch it before we ask a peer to
sign for it. handle_splice_init honours `splice_force_feerate` there,
as check_balances already does: that flag is the user saying they meant
it, and a policy limit should not override it.

feerate_max also needs a bound of its own, since it was derived purely
from the estimates times config.max_fee_multiplier. But a single bound
cannot serve both directions, because feerate_max gates what we accept
in `update_fee` *and* what we propose ourselves. Set for the accept
side it would have us paying absurd fees; set for the propose side it
would pin our commitment feerate below what a congested chain demands,
which is precisely when it has to confirm. So there are now two:

- FEERATE_CEILING (1000000 perkw, 4000 sat/vB) is the most we let a
peer drive us to. Their estimator being broken is not by itself
worth dropping a channel over, so this only has to exclude the
absurd.
- MAX_OUR_FEERATE_PER_KW (100000 perkw, 400 sat/vB) is the most we will
pay: roughly 0.011 BTC for a bare anchor commitment. Declining to
propose a feerate costs us nothing, so we can afford to be strict.
our_feerate_max() applies it wherever the money is ours:
default_feerate, splice_feerate, opening_feerate and dual-fund RBF.

Note this leaves the paths where we cannot decline -- mutual close,
penalty and onchain resolution -- bounded only by the ceiling, which is
the right answer for a feerate that has a deadline attached.

channeld needs both, so channeld_init and channeld_feerates carry
our_feerate_max alongside feerate_max, and check_balances holds whichever
side is ours to the stricter one. The multiplier is settable via
--dev-max-fee-multiplier, so widen to u64 before multiplying.

Finally, remove the UINT_MAX sentinels. feerate_max returned UINT_MAX
when there were no estimates at all, and lightningd overwrote the bound
with 0xFFFFFFFF when fee limits were ignored. Both are the bound a
peer's proposal is measured against, and we store what we accept -- a
u32 that large overflows the 25/24 RBF calculation downstream. The
unknown path now falls back to FEERATE_CEILING, exactly as feerate_min
falls back to FEERATE_FLOOR, and ignore_fee_limits travels to channeld
and openingd as an explicit flag which relaxes the policy bounds but
never the ceiling. That last part makes a documented promise false, so
the three places which say ignore-fee-limits means "any fee they want"
now say what it actually means.

Changelog-Fixed: channeld: a peer can no longer initiate a splice at an arbitrarily high feerate; it is now bounded like other remote-proposed feerates.
Changelog-Changed: lightningd: we no longer propose a feerate above 100000perkw (400 sat/vB) of our own accord, for channel opens, splices, commitment updates and dual-fund RBFs.
Changelog-Changed: lightningd: `--ignore-fee-limits` and `setchannel`'s `ignorefeelimits` still drop our policy bounds, but no longer accept a feerate above 1000000perkw (4000 sat/vB).
Changelog-Changed: JSON-RPC: `feerates` reports `max_acceptable` as the feerate ceiling rather than 4294967295 when no fee estimates are available.
(cherry picked from commit 4a10d71822c277e381bf289202f494e64110b522)

lightningd: clamp estimatefees results to a sanity ceiling

Nothing bounded the feerates we accept from the `estimatefees` plugin:
`parse_feerate_ranges` only checks that block counts ascend and that
rates do not increase with block count, and the conversion loop only
applies a floor. A broken or misbehaving fee source could therefore
push an arbitrary u32 into every downstream feerate calculation.

Clamp both the reported floor and each individual rate to
FEERATE_CEILING once they have been converted to perkw, and log loudly
when we do. We clamp rather than reject because `bitcoin_plugin_error`
is fatal(), and because discarding the estimate entirely is worse than
capping it: with no rates at all `feerate_max` falls into its "unknown"
path and returns UINT_MAX.

The ceiling is deliberately not a policy limit. It sits at 4000 sat/vB,
several times the highest the chain has ever seen, so that it only ever
fires on a broken fee source. Picking a tighter bound would mean
underestimating during genuine congestion, which is exactly when our
unilateral close and HTLC timeout transactions need to confirm.

The conversion has to be widened for the ceiling to see anything at all.
feerate_from_style() computed (feerate + 3) / 4 on a u32, so the top
three perkb values wrapped to 0 or 1 perkw, slipped under the ceiling,
and were then raised to the floor, hiding the whole thing. That is also
the more dangerous direction, since it underpays our own unilateral
close, and it applies equally to operator input like
`feerate="4294967295perkb"`. feerate_to_style() right below already
widened for the same reason; the asymmetry was an oversight.

Changelog-Fixed: lightningd: feerate estimates from the Bitcoin backend are now clamped to a sanity ceiling, so a misbehaving `estimatefees` plugin cannot feed absurd feerates into the rest of the daemon.
Changelog-Fixed: lightningd: a feerate given in perkb near the top of the 32-bit range no longer wraps to a near-zero perkw feerate.
(cherry picked from commit 2d80c3bfbf94cb54925f8178884e0e3089e4e06d)