AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 17 Bitcoin

Replace splice failure wire tests with a 0.2 downgrade test

Public commit record

What the developer wrote

Authored by auto-pr-bot

91/100 · Strong
Replace splice failure wire tests with a 0.2 downgrade test

@matt said:

> Feel free to squash.

@jkczyz said:

> Squashed

@matt asked:

> This is at least straightforward now. There's a lot of tests checking
> low-level serialization which I don't really buy as a way to test the
> 0.2 deserialization logic - if we want to test the 0.2 deserialization
> logic we need to actually use the 0.2 deserialization logic, not a copy
> of it using 0.3 types. Gonna go ahead and land this since the code is
> right and we need to get it over the line, but @auto-pr-bot can you
> replace the tests in events/mod.rs with tests in `lightning-tests` that
> use the 0.2 code to check the events? There's already some tests that do
> this in the PR so check that you're not duplicating coverage first.

@matt asked on the diff:

> I don't see the point of any of these tests. They feel like tests for
> tests sake rather than actually testing something meaningful.
> @auto-pr-bot

@matt asked on the diff:

> Same here. If we want to test upgrade/downgrade semantics the correct
> way is a `lightning-tests` multi-version test, not a test that checks
> the "wire" encoding of an `Event`.
>
> @auto-pr-bot

@matt asked on the diff:

> Yes, this is implied by the lack of implementation lol there's no need
> to document this @auto-pr-bot.

The `events` tests removed here built an `Event` by hand, wrote it, and
asserted on the bytes, or read bytes assembled to look like something
0.2 would have written. Either way they only ever exercised current
code's reader and writer, so they could not have caught a mismatch with
what 0.2 actually does -- the thing the encoding changes were about.
Checking that requires running 0.2's serialization, which is what
`lightning-tests` is for.

The reloads there already cover a splice failure releasing its whole
contribution, both for a negotiation aborted in flight and for one still
queued on quiescence, along with the `DiscardFunding` event type 0.2 has
to skip. What none of them cover is a contribution which reuses inputs
or outputs already committed to a pending splice: that is refused with
only the parts unique to it released, and those are what a downgraded
0.2 node has to learn about via `SpliceFailed`, since the
`DiscardFunding` carrying them is written under an event type it
ignores. Add a reload of a manager written with such a partial failure
pending, asserting 0.2 surfaces exactly the released output.

`FundingContribution::new_for_test` existed only to build contributions
for the removed tests, so it goes with them, as does the
`FailedSpliceContribution` note about having no serialization of its
own -- that is implied by the lack of any `Writeable`/`Readable`
implementation, so it tells callers nothing they need.

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

Requested-by: @matt
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4920#issuecomment-442672
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4920#issuecomment-442657
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4920#issuecomment-442658
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4920#issuecomment-442669
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit is a test-only cleanup in the Lightning Dev Kit (LDK) Rust codebase. It removes low-level byte-level tests for splice failure events and replaces them with a single cross-version test that actually loads a 0.2 node with serialized state from current code. There is no change to production logic, no fix for an active vulnerability, and no new attack surface. The work is defensive testing to ensure future serialization changes stay compatible with older LDK versions.

Recommended action

No security action required. This is a routine test-quality refactor. Reviewers may want to confirm the new downgrade test is run in CI and that the removed tests are not needed elsewhere.

Security signals we found

01

Cross-version serialization compatibility test added

02

Removal of byte-level tests that could not detect real 0.2 mismatches

03

No production code changes

04

No vulnerability fix or advisory language in commit

05

References prior issue #4919 for context on DiscardFunding/SpliceFailed event handling

Risk score

Why this scored 17/100

Our methodology →
Potential impact 2/30
Exploitability 0/25
Stealth signal 1/15
Affected reach 2/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.