rust-lightning

Reduce LSPS5 reset cooldown

Allow LSPS5 peer lifecycle events to clear webhook notification
cooldowns again after 100ms. This keeps rapid reconnect churn
throttled while avoiding multi-second delays between legitimate
wake-up opportunities.

Preserve subsecond precision in LSPSDateTime elapsed-time calculation
so the new interval is enforced as configured.

Co-Authored-By: HAL 9000

fuzz: add explicit local force-close ops

Add a small HTLC-free force-close slice to the chanmon consistency
harness. The new opcodes close one known channel on each peer link and
track which channels are expected to close.

Use the close tracker to reject untracked channel loss while accepting
stale post-close errors and cleanup generated by explicitly closed
channels. Later harness API calls skip tracked-closed channels so normal
channel APIs are not called after modeling a local close.

fuzz: inline chanmon finish invariants

Move the final chanmon consistency invariant checks into
Harness::finish so the checks can read harness state directly.

fuzz: factor chanmon finish cleanup helper

Move the finish-time relay and mining loop into a helper so the
harness has a single cleanup path for relayed transactions.

fuzz: add chanmon holder signer fuzz ops

Allow chanmon consistency fuzz inputs to block holder-side signer
operations and retry monitor-driven claim signing. The new commands
extend the existing signer-op blocking machinery to the holder
commitment and holder HTLC transaction paths.

Explicitly state rust toolchain in forgejo actions

Forgejo doesn't expand env/matrix arguments in the names it prints
for steps in actions, so we have to be explicit. We also have a lot
of jobs where we really don't need an env indirection for two
lines that reference it.

Tweak default merge message somewhat

I hate how long the title ends up being when you include the full
branch name in it, so move it to the next line.

Fix lightning-invoice bitcoin dependency version

`lightning-invoice` since 743f43fcfd5acba55242792ed1e9337f2ab52858 will
not build against `rust-bitcoin` older than v0.32.7.

For now disable all windows + macos CI runs until we have runners

Pin actions/checkout + actions/cache to a full URL and commit hash

Reference the checkout action by its explicit data.forgejo.org URL
pinned to a commit hash (v6) rather than the bare `actions/checkout@v4`
short form.

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

Use preinstalled rustup instead of curling the installer

rustup is already present in the runner image, so replace every
`curl https://sh.rustup.rs | sh ...` toolchain install with a plain
`rustup default <toolchain>`, which installs the toolchain if needed.

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

Pass commit context to codecov explicitly in coverage job

Codecov auto-detects only a fixed set of CI providers and cannot detect
the Forgejo Actions environment, so it fails to determine the pull
request (and commit/branch) for uploads. Pass --slug, --sha, --branch,
and --pr to the codecov CLI explicitly, derived from the workflow
context, with --pr omitted on non-pull_request events.

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

Comment the codecov report link on PRs

Codecov's own PR comment depends on CI environment detection, which does
not work under Forgejo, so post a link to the commit's coverage report
from the coverage job instead. A hidden marker keeps the comment sticky
(updated in place rather than re-posted on every push), and the step
only runs for pull requests.

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

Add Forgejo Actions workflows mirroring GitHub CI

Port the GitHub Actions workflows under .github/workflows/ to Forgejo
Actions under .forgejo/workflows/, targeting the instance at
git.rust-bitcoin.org and the lightningdevkit/rust-lightning repo. All
jobs run on the debian-trixie worker label; the build matrix restores
windows/macos legs (no runners provisioned for those yet).

Forgejo-specific adaptations:
- Fold the fuzz corpus push into the fuzz job, since Forgejo supports
neither the workflow_run trigger nor cross-run artifact access. The
push still targets the GitHub corpus repo and is best-effort so a
push hiccup cannot cascade to dependent jobs.
- Report build failures and stale-unicode notices via the fj CLI
against Forgejo instead of the gh CLI against GitHub.
- Run cargo audit directly in place of the rustsec/audit-check action,
which is not on Forgejo's default action registry.

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

Run tor in the background for the tor-connect job

The runner image ships the tor package but has no sudo to start the
system service, so the previous `sudo apt install -y tor` step cannot
work. Instead, start tor in the background within the test step, wait
for it to fully bootstrap (the test routes real traffic, including to a
.onion address, through the proxy), run the test, and kill tor on exit.

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

Add workflow to assign a random reviewer on new PRs

Forgejo has no built-in random/round-robin reviewer assignment, so add a
small Forgejo Actions workflow that, on pull request open, picks a random
developer from the maintainer pool (excluding the author) and requests
their review via the API.

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

Set max fee in route params for probes

May as well, and allows removing a comment that explains why we were previously
leaving it as None.

Fuzz: remove unnecessary route_params clones

Lower strictness of pending monitor update while awaiting tx_signatures

We previously assumed that no monitor update should ever be pending when
receiving `tx_signatures` while quiescent, with the exception of the
`RenegotiatedFunding` variant. This was a bit too strict, as we did not
consider that if an HTLC was sent via the same channel, its preimage
could be received from upstream leading to a monitor update to durably
persist it.

This commit ensures that if the recipient of a `tx_signatures` has not
yet echoed theirs back, and it is awaiting a monitor update completion,
then the pending monitor update must be of the `RenegotiatedFunding`
variant. If the pending monitor update is of another variant, then we
must remain quiescent with no pending updates available to send until
after the `tx_signatures` exchange.

Remove expectance of interactive-tx commitment_signed during reestablish

The use of `expecting_peer_commitment_signed` was being used as a way to
signal that we must disconnect if the message is not sent in a timely
manner. This isn't necessary, as we're already quiescent within this
flow, and can disconnect via that signal instead.

Ignore stale splice initial commitment_signed

After we complete a splice negotiation and see a
`FundingTransactionReadyForSigning` event, the counterparty may already
have sent its initial `commitment_signed` for the splice funding
transaction. If we then cancel the funding contribution, our local
channel state no longer tracks the pending splice attempt and queues
`tx_abort`, but the in-flight `commitment_signed` can still arrive
first. Handling that message against the post-abort channel state
attempts to validate a signature for the now-stale splice funding
transaction and can force-close the still-live channel.

We fix this by checking the optional `funding_txid` (which we expect all
implementations to always include by default) included in
`commitment_signed` before validating the commitment signature. If it
does not match the channel's locked funding txid, we can safely ignore
the stale message.

Avoid heap-allocating background processor futures

Replace Box::pin with core::pin::pin! in process_events_async now that
MSRV is 1.75. This eliminates a heap allocation per task on every
loop iteration by pinning the futures directly to the stack.

To satisfy lifetime and Joiner bounds, the loop logic was refactored
to run synchronous timer checks first, using flags to conditionally
execute the stack-pinned futures. Existing eager polling and early-break
semantics are preserved.

Pin zeroize for old Rust CI

zeroize 1.9.0 uses Rust 2024 metadata, which Cargo 1.75 cannot
parse. Pin it to 1.8.2 for older toolchains so the transaction sync
HTTPS feature check keeps passing on the MSRV job.

Drop the BufReader wrapper

Post `0.32.4` deserialization of consensus objects now use `Read`
as the trait bounds, making the BufReader no longer needed for
deserialization.

Deserialize consensus objects using Read type

The BufReader wrapping is no longer needed after the rust-bitcoin
`0.32.4` release which contains the standardisation of the trait
bounds for deserialization to `Read` instead of `BufReader`.