Skip to content

smite: add shutdown oracle - #266

Draft
ekzyis wants to merge 2 commits into
lnfuzz:masterfrom
ekzyis:shutdown-oracle
Draft

ekzyis wants to merge 2 commits into
lnfuzz:masterfrom
ekzyis:shutdown-oracle

Conversation

@ekzyis

@ekzyis ekzyis commented Sep 22, 2026 •

Copy link
Copy Markdown
Contributor

based on #163, related to #98

A received `shutdown` was recorded against its channel without being
judged, so a target naming a channel we never funded, replying on a
channel it should have failed, or using a `scriptpubkey` it was not
allowed to, went unreported.

Add a `ShutdownOracle` beside the other message oracles, evaluated by
`handle_implicit` before the `shutdown` is recorded, and report its
findings as `InvalidShutdown`. It flags the target if:

* the `shutdown` is for a channel we never funded
* we sent an invalid signature, so the target should have failed the
  channel instead of replying
* its `scriptpubkey` isn't a standard form for the negotiated features

@ekzyis ekzyis changed the title smite: add ShutdownOracle smite: add shutdown oracle Sep 22, 2026
RecvShutdown consumes the SentShutdown of a previous SendShutdown and
waits for the target's `shutdown` on the given channel. It returns that
channel's scriptpubkey, or empty bytes if no `shutdown` was received.

The target can send `shutdown` at any time and on any channel, so a
received one is recorded into its channel's state like `channel_ready`,
and explicit receives skip past it instead of failing. SendShutdown
records the script we sent, which is what makes a reply expected there,
and RecvShutdown reads the reply from channel state, so one recorded
before it ran is reported just the same.

BOLT 2 lets the target warn about a non-standard scriptpubkey instead of
replying, but every implementation except LDK disconnects afterwards and
LDK acts as if the `shutdown` never came, so a warning just ends
execution like any other unexpected message.

A target that has not sent `channel_ready` may ignore our `shutdown`, so
RecvShutdown is a no-op until it has. That gives up coverage of targets
which do reply before then, in exchange for not spending a receive
timeout on every target which doesn't.
A received `shutdown` was recorded against its channel without being
judged, so a target naming a channel we never funded, replying on a
channel it should have failed, or using a `scriptpubkey` it was not
allowed to, went unreported.

Add a `ShutdownOracle` beside the other message oracles, evaluated by
`handle_implicit` before the `shutdown` is recorded, and report its
findings as `InvalidShutdown`. It flags the target if:

* the `shutdown` is for a channel we never funded
* we sent an invalid signature, so the target should have failed the
  channel instead of replying
* its `scriptpubkey` isn't a standard form for the negotiated features
@ekzyis

ekzyis commented Oct 22, 2026

Copy link
Copy Markdown
Contributor Author

f2da440: rebased on top of 677a7a6 (#163)

@ekzyis
ekzyis marked this pull request as draft October 23, 2026 18:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant