Fuzz multi-part payments by joostjager · Pull Request #4367 · lightningdevkit/rust-lightning

joostjager · 2026-02-02T11:41:45Z

Increases fuzz coverage for multi-path payments in chanmon_consistency. Helpful for increasing confidence that #4345 (which makes use of async persistence) is stable to use.

Changes

Expand chanmon_consistency from 2 to 6 channels (3 per peer pair)
Add MPP payment fuzzing commands (0x70-0x74) that split payments across multiple channels, with variants for direct, single-hop, and multi-hop paths
Assert no stuck payments after settling all state

ldk-reviews-bot · 2026-02-02T11:41:47Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2026-02-02T13:46:25Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.03%. Comparing base (372ba65) to head (0a6b6d4).
⚠️ Report is 29 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #4367 +/- ##
==========================================
- Coverage 86.04% 86.03% -0.02% 
==========================================
Files 156 156 Lines 103002 103002 Branches 103002 103002 ==========================================
- Hits 88627 88614 -13 - Misses 11865 11879 +14 + Partials 2510 2509 -1

Flag	Coverage Δ
tests	`86.03% <ø> (-0.02%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

joostjager · 2026-02-02T15:18:26Z

@TheBlueMatt we keep expanding the fuzz space. If we want to stick to byte commands to not make it unnecessarily difficult for the fuzzer, it seems we have to accept less variation. In particular when there are multiple channels, fuzzing operations on each of them individually is quickly using up all byte values.

For the same reason, I selected only four variations of mpp.

Do you think the trade-off is still right, or should we consider something like 1 byte command + 1 byte parameter?

TheBlueMatt

IMO one of the biggest coverage gaps that we can fix here is what happens to payments when a channel was closed. Its obviously not trivial (we have to handle clearing HTLCs via the monitor path) but I'm not actually sure the changes here would have found the bulk of the issues we've run into on 0.1, whereas closing some of the channels would.

ldk-reviews-bot · 2026-02-03T15:45:46Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

joostjager · 2026-02-03T16:26:04Z

IMO one of the biggest coverage gaps that we can fix here is what happens to payments when a channel was closed. Its obviously not trivial (we have to handle clearing HTLCs via the monitor path) but I'm not actually sure the changes here would have found the bulk of the issues we've run into on 0.1, whereas closing some of the channels would.

Yes I can definitely see that. My idea was to first add multiple channels and mpp in this PR, and then continue with force closing in the next. Do you think doing it the other way around is better?

TheBlueMatt · 2026-02-03T16:31:09Z

Oh, no, this is definitely fine, i just wanted to check if that was the next step/intended as a separate PR or if it wasn't planned. Happy to land this as-is first.

joostjager · 2026-02-03T16:33:35Z

Intended next step. I had added it to the PR description to avoid the question :)

TheBlueMatt · 2026-02-03T17:05:07Z

Maybe that'll teach me to read (it won't).

TheBlueMatt · 2026-02-04T22:22:21Z

 0x6c => send_hop_noret(0, 1, chan_a, 2, chan_b, 1, &mut p_ctr),
 0x6d => send_hop_noret(2, 1, chan_b, 0, chan_a, 1, &mut p_ctr),

+ // MPP payments


We also need to fuzz the case where the recipient receives an MPP via multiple parts over a single channel. Also probably the case where a forwarding node receives an MPP in multiple parts over a single channel.

Also probably the case where a forwarding node receives an MPP in multiple parts over a single channel.
This should have been covered already on commands 0x71 and 0x73.
Added a commit for the direct multi-part single-channel case.

Squashed it as it was only the two lines for the command.

joostjager · 2026-02-05T12:16:43Z

Tried hitting a panic in PaymentSent for all five mpp commands. Then I discovered #4385. With that applied, Claude came up with the following sequences for mpp:

Command	Description	Fuzz String (hex)
0x70	Direct MPP (multi A-B channels)	`00 70 11 19 1f 11 19 1f 11 19 1f 11 19 1f 11 19 17 11 19 17 11 19 17`
0x71	Hop MPP (multi A-B, single B-C)	`00 71 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x72	Hop MPP (multi A-B, multi B-C)	`00 72 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x73	Hop MPP (single A-B, multi B-C)	`00 73 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x74	Direct MPP (3 parts, single channel)	`00 74 11 19 1f 11 19 1f 11 19 1f 11 19 1f 11 19 17 11 19 17 11 19 17`

This expands the channel monitor consistency fuzz test from 2 channels to 6 channels (3 between A-B and 3 between B-C), enabling future MPP payment testing. Changes: - Extract `connect_peers!` macro from `make_channel!` to avoid duplicate peer connections - Create channel arrays `chan_ab_ids[3]` and `chan_bc_ids[3]` - Store SCIDs in `chan_ab_scids[3]` and `chan_bc_scids[3]` - Use funding transaction versions 1-6 to avoid txid collisions under fuzz hashing (which XORs all bytes to a single byte, causing versions 0-5 to collide between A-B and B-C channel pairs) - Update `test_return!` assertions to expect 3/6/3 channels Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Add multi-path payment (MPP) fuzzing commands that split payments across multiple channels: - send_mpp_payment: direct MPP from source to dest using multiple channels - send_mpp_hop_payment: MPP via intermediate node with multiple channels on either or both hops New fuzz commands: - 0x70: direct MPP 0->1 (uses all 3 A-B channels) - 0x71: MPP 0->1->2, multi channels on first hop (A-B) - 0x72: MPP 0->1->2, multi channels on both hops (A-B and B-C) - 0x73: MPP 0->1->2, multi channels on second hop (B-C) - 0x74: single-channel MPP 0->1 (all parts over one channel) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

After settling all state at 0xff, verify that pending_payments is empty for all nodes. If payments remain stuck indefinitely, that indicates a bug in payment resolution. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

TheBlueMatt

Thanks!

joostjager · 2026-02-02T11:41:45Z

Increases fuzz coverage for multi-path payments in chanmon_consistency. Helpful for increasing confidence that #4345 (which makes use of async persistence) is stable to use.

Changes

Expand chanmon_consistency from 2 to 6 channels (3 per peer pair)
Add MPP payment fuzzing commands (0x70-0x74) that split payments across multiple channels, with variants for direct, single-hop, and multi-hop paths
Assert no stuck payments after settling all state

ldk-reviews-bot · 2026-02-02T11:41:47Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2026-02-02T13:46:25Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.03%. Comparing base (372ba65) to head (0a6b6d4).
⚠️ Report is 29 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #4367 +/- ##
==========================================
- Coverage 86.04% 86.03% -0.02% 
==========================================
Files 156 156 Lines 103002 103002 Branches 103002 103002 ==========================================
- Hits 88627 88614 -13 - Misses 11865 11879 +14 + Partials 2510 2509 -1

Flag	Coverage Δ
tests	`86.03% <ø> (-0.02%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

joostjager · 2026-02-02T15:18:26Z

@TheBlueMatt we keep expanding the fuzz space. If we want to stick to byte commands to not make it unnecessarily difficult for the fuzzer, it seems we have to accept less variation. In particular when there are multiple channels, fuzzing operations on each of them individually is quickly using up all byte values.

For the same reason, I selected only four variations of mpp.

Do you think the trade-off is still right, or should we consider something like 1 byte command + 1 byte parameter?

TheBlueMatt

IMO one of the biggest coverage gaps that we can fix here is what happens to payments when a channel was closed. Its obviously not trivial (we have to handle clearing HTLCs via the monitor path) but I'm not actually sure the changes here would have found the bulk of the issues we've run into on 0.1, whereas closing some of the channels would.

ldk-reviews-bot · 2026-02-03T15:45:46Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

joostjager · 2026-02-03T16:26:04Z

IMO one of the biggest coverage gaps that we can fix here is what happens to payments when a channel was closed. Its obviously not trivial (we have to handle clearing HTLCs via the monitor path) but I'm not actually sure the changes here would have found the bulk of the issues we've run into on 0.1, whereas closing some of the channels would.

Yes I can definitely see that. My idea was to first add multiple channels and mpp in this PR, and then continue with force closing in the next. Do you think doing it the other way around is better?

TheBlueMatt · 2026-02-03T16:31:09Z

Oh, no, this is definitely fine, i just wanted to check if that was the next step/intended as a separate PR or if it wasn't planned. Happy to land this as-is first.

joostjager · 2026-02-03T16:33:35Z

Intended next step. I had added it to the PR description to avoid the question :)

TheBlueMatt · 2026-02-03T17:05:07Z

Maybe that'll teach me to read (it won't).

TheBlueMatt · 2026-02-04T22:22:21Z

 0x6c => send_hop_noret(0, 1, chan_a, 2, chan_b, 1, &mut p_ctr),
 0x6d => send_hop_noret(2, 1, chan_b, 0, chan_a, 1, &mut p_ctr),

+ // MPP payments


We also need to fuzz the case where the recipient receives an MPP via multiple parts over a single channel. Also probably the case where a forwarding node receives an MPP in multiple parts over a single channel.

Also probably the case where a forwarding node receives an MPP in multiple parts over a single channel.
This should have been covered already on commands 0x71 and 0x73.
Added a commit for the direct multi-part single-channel case.

Squashed it as it was only the two lines for the command.

joostjager · 2026-02-05T12:16:43Z

Tried hitting a panic in PaymentSent for all five mpp commands. Then I discovered #4385. With that applied, Claude came up with the following sequences for mpp:

Command	Description	Fuzz String (hex)
0x70	Direct MPP (multi A-B channels)	`00 70 11 19 1f 11 19 1f 11 19 1f 11 19 1f 11 19 17 11 19 17 11 19 17`
0x71	Hop MPP (multi A-B, single B-C)	`00 71 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x72	Hop MPP (multi A-B, multi B-C)	`00 72 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x73	Hop MPP (single A-B, multi B-C)	`00 73 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x74	Direct MPP (3 parts, single channel)	`00 74 11 19 1f 11 19 1f 11 19 1f 11 19 1f 11 19 17 11 19 17 11 19 17`

This expands the channel monitor consistency fuzz test from 2 channels to 6 channels (3 between A-B and 3 between B-C), enabling future MPP payment testing. Changes: - Extract `connect_peers!` macro from `make_channel!` to avoid duplicate peer connections - Create channel arrays `chan_ab_ids[3]` and `chan_bc_ids[3]` - Store SCIDs in `chan_ab_scids[3]` and `chan_bc_scids[3]` - Use funding transaction versions 1-6 to avoid txid collisions under fuzz hashing (which XORs all bytes to a single byte, causing versions 0-5 to collide between A-B and B-C channel pairs) - Update `test_return!` assertions to expect 3/6/3 channels Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Add multi-path payment (MPP) fuzzing commands that split payments across multiple channels: - send_mpp_payment: direct MPP from source to dest using multiple channels - send_mpp_hop_payment: MPP via intermediate node with multiple channels on either or both hops New fuzz commands: - 0x70: direct MPP 0->1 (uses all 3 A-B channels) - 0x71: MPP 0->1->2, multi channels on first hop (A-B) - 0x72: MPP 0->1->2, multi channels on both hops (A-B and B-C) - 0x73: MPP 0->1->2, multi channels on second hop (B-C) - 0x74: single-channel MPP 0->1 (all parts over one channel) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

After settling all state at 0xff, verify that pending_payments is empty for all nodes. If payments remain stuck indefinitely, that indicates a bug in payment resolution. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

TheBlueMatt

Thanks!

joostjager · 2026-02-02T11:41:45Z

Increases fuzz coverage for multi-path payments in chanmon_consistency. Helpful for increasing confidence that #4345 (which makes use of async persistence) is stable to use.

Changes

Expand chanmon_consistency from 2 to 6 channels (3 per peer pair)
Add MPP payment fuzzing commands (0x70-0x74) that split payments across multiple channels, with variants for direct, single-hop, and multi-hop paths
Assert no stuck payments after settling all state

ldk-reviews-bot · 2026-02-02T11:41:47Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2026-02-02T13:46:25Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.03%. Comparing base (372ba65) to head (0a6b6d4).
⚠️ Report is 29 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #4367 +/- ##
==========================================
- Coverage 86.04% 86.03% -0.02% 
==========================================
Files 156 156 Lines 103002 103002 Branches 103002 103002 ==========================================
- Hits 88627 88614 -13 - Misses 11865 11879 +14 + Partials 2510 2509 -1

Flag	Coverage Δ
tests	`86.03% <ø> (-0.02%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

joostjager · 2026-02-02T15:18:26Z

@TheBlueMatt we keep expanding the fuzz space. If we want to stick to byte commands to not make it unnecessarily difficult for the fuzzer, it seems we have to accept less variation. In particular when there are multiple channels, fuzzing operations on each of them individually is quickly using up all byte values.

For the same reason, I selected only four variations of mpp.

Do you think the trade-off is still right, or should we consider something like 1 byte command + 1 byte parameter?

TheBlueMatt

IMO one of the biggest coverage gaps that we can fix here is what happens to payments when a channel was closed. Its obviously not trivial (we have to handle clearing HTLCs via the monitor path) but I'm not actually sure the changes here would have found the bulk of the issues we've run into on 0.1, whereas closing some of the channels would.

ldk-reviews-bot · 2026-02-03T15:45:46Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

joostjager · 2026-02-03T16:26:04Z

IMO one of the biggest coverage gaps that we can fix here is what happens to payments when a channel was closed. Its obviously not trivial (we have to handle clearing HTLCs via the monitor path) but I'm not actually sure the changes here would have found the bulk of the issues we've run into on 0.1, whereas closing some of the channels would.

Yes I can definitely see that. My idea was to first add multiple channels and mpp in this PR, and then continue with force closing in the next. Do you think doing it the other way around is better?

TheBlueMatt · 2026-02-03T16:31:09Z

Oh, no, this is definitely fine, i just wanted to check if that was the next step/intended as a separate PR or if it wasn't planned. Happy to land this as-is first.

joostjager · 2026-02-03T16:33:35Z

Intended next step. I had added it to the PR description to avoid the question :)

TheBlueMatt · 2026-02-03T17:05:07Z

Maybe that'll teach me to read (it won't).

TheBlueMatt · 2026-02-04T22:22:21Z

 0x6c => send_hop_noret(0, 1, chan_a, 2, chan_b, 1, &mut p_ctr),
 0x6d => send_hop_noret(2, 1, chan_b, 0, chan_a, 1, &mut p_ctr),

+ // MPP payments


We also need to fuzz the case where the recipient receives an MPP via multiple parts over a single channel. Also probably the case where a forwarding node receives an MPP in multiple parts over a single channel.

Also probably the case where a forwarding node receives an MPP in multiple parts over a single channel.
This should have been covered already on commands 0x71 and 0x73.
Added a commit for the direct multi-part single-channel case.

Squashed it as it was only the two lines for the command.

joostjager · 2026-02-05T12:16:43Z

Tried hitting a panic in PaymentSent for all five mpp commands. Then I discovered #4385. With that applied, Claude came up with the following sequences for mpp:

Command	Description	Fuzz String (hex)
0x70	Direct MPP (multi A-B channels)	`00 70 11 19 1f 11 19 1f 11 19 1f 11 19 1f 11 19 17 11 19 17 11 19 17`
0x71	Hop MPP (multi A-B, single B-C)	`00 71 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x72	Hop MPP (multi A-B, multi B-C)	`00 72 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x73	Hop MPP (single A-B, multi B-C)	`00 73 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x74	Direct MPP (3 parts, single channel)	`00 74 11 19 1f 11 19 1f 11 19 1f 11 19 1f 11 19 17 11 19 17 11 19 17`

This expands the channel monitor consistency fuzz test from 2 channels to 6 channels (3 between A-B and 3 between B-C), enabling future MPP payment testing. Changes: - Extract `connect_peers!` macro from `make_channel!` to avoid duplicate peer connections - Create channel arrays `chan_ab_ids[3]` and `chan_bc_ids[3]` - Store SCIDs in `chan_ab_scids[3]` and `chan_bc_scids[3]` - Use funding transaction versions 1-6 to avoid txid collisions under fuzz hashing (which XORs all bytes to a single byte, causing versions 0-5 to collide between A-B and B-C channel pairs) - Update `test_return!` assertions to expect 3/6/3 channels Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Add multi-path payment (MPP) fuzzing commands that split payments across multiple channels: - send_mpp_payment: direct MPP from source to dest using multiple channels - send_mpp_hop_payment: MPP via intermediate node with multiple channels on either or both hops New fuzz commands: - 0x70: direct MPP 0->1 (uses all 3 A-B channels) - 0x71: MPP 0->1->2, multi channels on first hop (A-B) - 0x72: MPP 0->1->2, multi channels on both hops (A-B and B-C) - 0x73: MPP 0->1->2, multi channels on second hop (B-C) - 0x74: single-channel MPP 0->1 (all parts over one channel) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

After settling all state at 0xff, verify that pending_payments is empty for all nodes. If payments remain stuck indefinitely, that indicates a bug in payment resolution. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

TheBlueMatt

Thanks!

joostjager · 2026-02-02T11:41:45Z

Increases fuzz coverage for multi-path payments in chanmon_consistency. Helpful for increasing confidence that #4345 (which makes use of async persistence) is stable to use.

Changes

Expand chanmon_consistency from 2 to 6 channels (3 per peer pair)
Add MPP payment fuzzing commands (0x70-0x74) that split payments across multiple channels, with variants for direct, single-hop, and multi-hop paths
Assert no stuck payments after settling all state

ldk-reviews-bot · 2026-02-02T11:41:47Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2026-02-02T13:46:25Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.03%. Comparing base (372ba65) to head (0a6b6d4).
⚠️ Report is 29 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #4367 +/- ##
==========================================
- Coverage 86.04% 86.03% -0.02% 
==========================================
Files 156 156 Lines 103002 103002 Branches 103002 103002 ==========================================
- Hits 88627 88614 -13 - Misses 11865 11879 +14 + Partials 2510 2509 -1

Flag	Coverage Δ
tests	`86.03% <ø> (-0.02%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

joostjager · 2026-02-02T15:18:26Z

@TheBlueMatt we keep expanding the fuzz space. If we want to stick to byte commands to not make it unnecessarily difficult for the fuzzer, it seems we have to accept less variation. In particular when there are multiple channels, fuzzing operations on each of them individually is quickly using up all byte values.

For the same reason, I selected only four variations of mpp.

Do you think the trade-off is still right, or should we consider something like 1 byte command + 1 byte parameter?

TheBlueMatt

IMO one of the biggest coverage gaps that we can fix here is what happens to payments when a channel was closed. Its obviously not trivial (we have to handle clearing HTLCs via the monitor path) but I'm not actually sure the changes here would have found the bulk of the issues we've run into on 0.1, whereas closing some of the channels would.

ldk-reviews-bot · 2026-02-03T15:45:46Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

joostjager · 2026-02-03T16:26:04Z

IMO one of the biggest coverage gaps that we can fix here is what happens to payments when a channel was closed. Its obviously not trivial (we have to handle clearing HTLCs via the monitor path) but I'm not actually sure the changes here would have found the bulk of the issues we've run into on 0.1, whereas closing some of the channels would.

Yes I can definitely see that. My idea was to first add multiple channels and mpp in this PR, and then continue with force closing in the next. Do you think doing it the other way around is better?

TheBlueMatt · 2026-02-03T16:31:09Z

Oh, no, this is definitely fine, i just wanted to check if that was the next step/intended as a separate PR or if it wasn't planned. Happy to land this as-is first.

joostjager · 2026-02-03T16:33:35Z

Intended next step. I had added it to the PR description to avoid the question :)

TheBlueMatt · 2026-02-03T17:05:07Z

Maybe that'll teach me to read (it won't).

TheBlueMatt · 2026-02-04T22:22:21Z

 0x6c => send_hop_noret(0, 1, chan_a, 2, chan_b, 1, &mut p_ctr),
 0x6d => send_hop_noret(2, 1, chan_b, 0, chan_a, 1, &mut p_ctr),

+ // MPP payments


We also need to fuzz the case where the recipient receives an MPP via multiple parts over a single channel. Also probably the case where a forwarding node receives an MPP in multiple parts over a single channel.

Also probably the case where a forwarding node receives an MPP in multiple parts over a single channel.
This should have been covered already on commands 0x71 and 0x73.
Added a commit for the direct multi-part single-channel case.

Squashed it as it was only the two lines for the command.

joostjager · 2026-02-05T12:16:43Z

Tried hitting a panic in PaymentSent for all five mpp commands. Then I discovered #4385. With that applied, Claude came up with the following sequences for mpp:

Command	Description	Fuzz String (hex)
0x70	Direct MPP (multi A-B channels)	`00 70 11 19 1f 11 19 1f 11 19 1f 11 19 1f 11 19 17 11 19 17 11 19 17`
0x71	Hop MPP (multi A-B, single B-C)	`00 71 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x72	Hop MPP (multi A-B, multi B-C)	`00 72 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x73	Hop MPP (single A-B, multi B-C)	`00 73 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x74	Direct MPP (3 parts, single channel)	`00 74 11 19 1f 11 19 1f 11 19 1f 11 19 1f 11 19 17 11 19 17 11 19 17`

This expands the channel monitor consistency fuzz test from 2 channels to 6 channels (3 between A-B and 3 between B-C), enabling future MPP payment testing. Changes: - Extract `connect_peers!` macro from `make_channel!` to avoid duplicate peer connections - Create channel arrays `chan_ab_ids[3]` and `chan_bc_ids[3]` - Store SCIDs in `chan_ab_scids[3]` and `chan_bc_scids[3]` - Use funding transaction versions 1-6 to avoid txid collisions under fuzz hashing (which XORs all bytes to a single byte, causing versions 0-5 to collide between A-B and B-C channel pairs) - Update `test_return!` assertions to expect 3/6/3 channels Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Add multi-path payment (MPP) fuzzing commands that split payments across multiple channels: - send_mpp_payment: direct MPP from source to dest using multiple channels - send_mpp_hop_payment: MPP via intermediate node with multiple channels on either or both hops New fuzz commands: - 0x70: direct MPP 0->1 (uses all 3 A-B channels) - 0x71: MPP 0->1->2, multi channels on first hop (A-B) - 0x72: MPP 0->1->2, multi channels on both hops (A-B and B-C) - 0x73: MPP 0->1->2, multi channels on second hop (B-C) - 0x74: single-channel MPP 0->1 (all parts over one channel) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

After settling all state at 0xff, verify that pending_payments is empty for all nodes. If payments remain stuck indefinitely, that indicates a bug in payment resolution. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

TheBlueMatt

Thanks!

joostjager · 2026-02-02T11:41:45Z

Increases fuzz coverage for multi-path payments in chanmon_consistency. Helpful for increasing confidence that #4345 (which makes use of async persistence) is stable to use.

Changes

Expand chanmon_consistency from 2 to 6 channels (3 per peer pair)
Add MPP payment fuzzing commands (0x70-0x74) that split payments across multiple channels, with variants for direct, single-hop, and multi-hop paths
Assert no stuck payments after settling all state

ldk-reviews-bot · 2026-02-02T11:41:47Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2026-02-02T13:46:25Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.03%. Comparing base (372ba65) to head (0a6b6d4).
⚠️ Report is 29 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #4367 +/- ##
==========================================
- Coverage 86.04% 86.03% -0.02% 
==========================================
Files 156 156 Lines 103002 103002 Branches 103002 103002 ==========================================
- Hits 88627 88614 -13 - Misses 11865 11879 +14 + Partials 2510 2509 -1

Flag	Coverage Δ
tests	`86.03% <ø> (-0.02%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

joostjager · 2026-02-02T15:18:26Z

@TheBlueMatt we keep expanding the fuzz space. If we want to stick to byte commands to not make it unnecessarily difficult for the fuzzer, it seems we have to accept less variation. In particular when there are multiple channels, fuzzing operations on each of them individually is quickly using up all byte values.

For the same reason, I selected only four variations of mpp.

Do you think the trade-off is still right, or should we consider something like 1 byte command + 1 byte parameter?

TheBlueMatt

IMO one of the biggest coverage gaps that we can fix here is what happens to payments when a channel was closed. Its obviously not trivial (we have to handle clearing HTLCs via the monitor path) but I'm not actually sure the changes here would have found the bulk of the issues we've run into on 0.1, whereas closing some of the channels would.

ldk-reviews-bot · 2026-02-03T15:45:46Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

joostjager · 2026-02-03T16:26:04Z

IMO one of the biggest coverage gaps that we can fix here is what happens to payments when a channel was closed. Its obviously not trivial (we have to handle clearing HTLCs via the monitor path) but I'm not actually sure the changes here would have found the bulk of the issues we've run into on 0.1, whereas closing some of the channels would.

Yes I can definitely see that. My idea was to first add multiple channels and mpp in this PR, and then continue with force closing in the next. Do you think doing it the other way around is better?

TheBlueMatt · 2026-02-03T16:31:09Z

Oh, no, this is definitely fine, i just wanted to check if that was the next step/intended as a separate PR or if it wasn't planned. Happy to land this as-is first.

joostjager · 2026-02-03T16:33:35Z

Intended next step. I had added it to the PR description to avoid the question :)

TheBlueMatt · 2026-02-03T17:05:07Z

Maybe that'll teach me to read (it won't).

TheBlueMatt · 2026-02-04T22:22:21Z

 0x6c => send_hop_noret(0, 1, chan_a, 2, chan_b, 1, &mut p_ctr),
 0x6d => send_hop_noret(2, 1, chan_b, 0, chan_a, 1, &mut p_ctr),

+ // MPP payments


We also need to fuzz the case where the recipient receives an MPP via multiple parts over a single channel. Also probably the case where a forwarding node receives an MPP in multiple parts over a single channel.

Also probably the case where a forwarding node receives an MPP in multiple parts over a single channel.
This should have been covered already on commands 0x71 and 0x73.
Added a commit for the direct multi-part single-channel case.

Squashed it as it was only the two lines for the command.

joostjager · 2026-02-05T12:16:43Z

Tried hitting a panic in PaymentSent for all five mpp commands. Then I discovered #4385. With that applied, Claude came up with the following sequences for mpp:

Command	Description	Fuzz String (hex)
0x70	Direct MPP (multi A-B channels)	`00 70 11 19 1f 11 19 1f 11 19 1f 11 19 1f 11 19 17 11 19 17 11 19 17`
0x71	Hop MPP (multi A-B, single B-C)	`00 71 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x72	Hop MPP (multi A-B, multi B-C)	`00 72 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x73	Hop MPP (single A-B, multi B-C)	`00 73 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x74	Direct MPP (3 parts, single channel)	`00 74 11 19 1f 11 19 1f 11 19 1f 11 19 1f 11 19 17 11 19 17 11 19 17`

This expands the channel monitor consistency fuzz test from 2 channels to 6 channels (3 between A-B and 3 between B-C), enabling future MPP payment testing. Changes: - Extract `connect_peers!` macro from `make_channel!` to avoid duplicate peer connections - Create channel arrays `chan_ab_ids[3]` and `chan_bc_ids[3]` - Store SCIDs in `chan_ab_scids[3]` and `chan_bc_scids[3]` - Use funding transaction versions 1-6 to avoid txid collisions under fuzz hashing (which XORs all bytes to a single byte, causing versions 0-5 to collide between A-B and B-C channel pairs) - Update `test_return!` assertions to expect 3/6/3 channels Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Add multi-path payment (MPP) fuzzing commands that split payments across multiple channels: - send_mpp_payment: direct MPP from source to dest using multiple channels - send_mpp_hop_payment: MPP via intermediate node with multiple channels on either or both hops New fuzz commands: - 0x70: direct MPP 0->1 (uses all 3 A-B channels) - 0x71: MPP 0->1->2, multi channels on first hop (A-B) - 0x72: MPP 0->1->2, multi channels on both hops (A-B and B-C) - 0x73: MPP 0->1->2, multi channels on second hop (B-C) - 0x74: single-channel MPP 0->1 (all parts over one channel) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

After settling all state at 0xff, verify that pending_payments is empty for all nodes. If payments remain stuck indefinitely, that indicates a bug in payment resolution. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

TheBlueMatt

Thanks!

joostjager · 2026-02-02T11:41:45Z

Increases fuzz coverage for multi-path payments in chanmon_consistency. Helpful for increasing confidence that #4345 (which makes use of async persistence) is stable to use.

Changes

Expand chanmon_consistency from 2 to 6 channels (3 per peer pair)
Add MPP payment fuzzing commands (0x70-0x74) that split payments across multiple channels, with variants for direct, single-hop, and multi-hop paths
Assert no stuck payments after settling all state

ldk-reviews-bot · 2026-02-02T11:41:47Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2026-02-02T13:46:25Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.03%. Comparing base (372ba65) to head (0a6b6d4).
⚠️ Report is 29 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #4367 +/- ##
==========================================
- Coverage 86.04% 86.03% -0.02% 
==========================================
Files 156 156 Lines 103002 103002 Branches 103002 103002 ==========================================
- Hits 88627 88614 -13 - Misses 11865 11879 +14 + Partials 2510 2509 -1

Flag	Coverage Δ
tests	`86.03% <ø> (-0.02%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

joostjager · 2026-02-02T15:18:26Z

@TheBlueMatt we keep expanding the fuzz space. If we want to stick to byte commands to not make it unnecessarily difficult for the fuzzer, it seems we have to accept less variation. In particular when there are multiple channels, fuzzing operations on each of them individually is quickly using up all byte values.

For the same reason, I selected only four variations of mpp.

Do you think the trade-off is still right, or should we consider something like 1 byte command + 1 byte parameter?

TheBlueMatt

IMO one of the biggest coverage gaps that we can fix here is what happens to payments when a channel was closed. Its obviously not trivial (we have to handle clearing HTLCs via the monitor path) but I'm not actually sure the changes here would have found the bulk of the issues we've run into on 0.1, whereas closing some of the channels would.

ldk-reviews-bot · 2026-02-03T15:45:46Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

joostjager · 2026-02-03T16:26:04Z

IMO one of the biggest coverage gaps that we can fix here is what happens to payments when a channel was closed. Its obviously not trivial (we have to handle clearing HTLCs via the monitor path) but I'm not actually sure the changes here would have found the bulk of the issues we've run into on 0.1, whereas closing some of the channels would.

Yes I can definitely see that. My idea was to first add multiple channels and mpp in this PR, and then continue with force closing in the next. Do you think doing it the other way around is better?

TheBlueMatt · 2026-02-03T16:31:09Z

Oh, no, this is definitely fine, i just wanted to check if that was the next step/intended as a separate PR or if it wasn't planned. Happy to land this as-is first.

joostjager · 2026-02-03T16:33:35Z

Intended next step. I had added it to the PR description to avoid the question :)

TheBlueMatt · 2026-02-03T17:05:07Z

Maybe that'll teach me to read (it won't).

TheBlueMatt · 2026-02-04T22:22:21Z

 0x6c => send_hop_noret(0, 1, chan_a, 2, chan_b, 1, &mut p_ctr),
 0x6d => send_hop_noret(2, 1, chan_b, 0, chan_a, 1, &mut p_ctr),

+ // MPP payments


We also need to fuzz the case where the recipient receives an MPP via multiple parts over a single channel. Also probably the case where a forwarding node receives an MPP in multiple parts over a single channel.

Also probably the case where a forwarding node receives an MPP in multiple parts over a single channel.
This should have been covered already on commands 0x71 and 0x73.
Added a commit for the direct multi-part single-channel case.

Squashed it as it was only the two lines for the command.

joostjager · 2026-02-05T12:16:43Z

Tried hitting a panic in PaymentSent for all five mpp commands. Then I discovered #4385. With that applied, Claude came up with the following sequences for mpp:

Command	Description	Fuzz String (hex)
0x70	Direct MPP (multi A-B channels)	`00 70 11 19 1f 11 19 1f 11 19 1f 11 19 1f 11 19 17 11 19 17 11 19 17`
0x71	Hop MPP (multi A-B, single B-C)	`00 71 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x72	Hop MPP (multi A-B, multi B-C)	`00 72 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x73	Hop MPP (single A-B, multi B-C)	`00 73 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x74	Direct MPP (3 parts, single channel)	`00 74 11 19 1f 11 19 1f 11 19 1f 11 19 1f 11 19 17 11 19 17 11 19 17`

This expands the channel monitor consistency fuzz test from 2 channels to 6 channels (3 between A-B and 3 between B-C), enabling future MPP payment testing. Changes: - Extract `connect_peers!` macro from `make_channel!` to avoid duplicate peer connections - Create channel arrays `chan_ab_ids[3]` and `chan_bc_ids[3]` - Store SCIDs in `chan_ab_scids[3]` and `chan_bc_scids[3]` - Use funding transaction versions 1-6 to avoid txid collisions under fuzz hashing (which XORs all bytes to a single byte, causing versions 0-5 to collide between A-B and B-C channel pairs) - Update `test_return!` assertions to expect 3/6/3 channels Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Add multi-path payment (MPP) fuzzing commands that split payments across multiple channels: - send_mpp_payment: direct MPP from source to dest using multiple channels - send_mpp_hop_payment: MPP via intermediate node with multiple channels on either or both hops New fuzz commands: - 0x70: direct MPP 0->1 (uses all 3 A-B channels) - 0x71: MPP 0->1->2, multi channels on first hop (A-B) - 0x72: MPP 0->1->2, multi channels on both hops (A-B and B-C) - 0x73: MPP 0->1->2, multi channels on second hop (B-C) - 0x74: single-channel MPP 0->1 (all parts over one channel) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

After settling all state at 0xff, verify that pending_payments is empty for all nodes. If payments remain stuck indefinitely, that indicates a bug in payment resolution. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

TheBlueMatt

Thanks!

joostjager · 2026-02-02T11:41:45Z

Increases fuzz coverage for multi-path payments in chanmon_consistency. Helpful for increasing confidence that #4345 (which makes use of async persistence) is stable to use.

Changes

Expand chanmon_consistency from 2 to 6 channels (3 per peer pair)
Add MPP payment fuzzing commands (0x70-0x74) that split payments across multiple channels, with variants for direct, single-hop, and multi-hop paths
Assert no stuck payments after settling all state

ldk-reviews-bot · 2026-02-02T11:41:47Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2026-02-02T13:46:25Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.03%. Comparing base (372ba65) to head (0a6b6d4).
⚠️ Report is 29 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #4367 +/- ##
==========================================
- Coverage 86.04% 86.03% -0.02% 
==========================================
Files 156 156 Lines 103002 103002 Branches 103002 103002 ==========================================
- Hits 88627 88614 -13 - Misses 11865 11879 +14 + Partials 2510 2509 -1

Flag	Coverage Δ
tests	`86.03% <ø> (-0.02%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

joostjager · 2026-02-02T15:18:26Z

@TheBlueMatt we keep expanding the fuzz space. If we want to stick to byte commands to not make it unnecessarily difficult for the fuzzer, it seems we have to accept less variation. In particular when there are multiple channels, fuzzing operations on each of them individually is quickly using up all byte values.

For the same reason, I selected only four variations of mpp.

Do you think the trade-off is still right, or should we consider something like 1 byte command + 1 byte parameter?

TheBlueMatt

IMO one of the biggest coverage gaps that we can fix here is what happens to payments when a channel was closed. Its obviously not trivial (we have to handle clearing HTLCs via the monitor path) but I'm not actually sure the changes here would have found the bulk of the issues we've run into on 0.1, whereas closing some of the channels would.

ldk-reviews-bot · 2026-02-03T15:45:46Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

joostjager · 2026-02-03T16:26:04Z

IMO one of the biggest coverage gaps that we can fix here is what happens to payments when a channel was closed. Its obviously not trivial (we have to handle clearing HTLCs via the monitor path) but I'm not actually sure the changes here would have found the bulk of the issues we've run into on 0.1, whereas closing some of the channels would.

Yes I can definitely see that. My idea was to first add multiple channels and mpp in this PR, and then continue with force closing in the next. Do you think doing it the other way around is better?

TheBlueMatt · 2026-02-03T16:31:09Z

Oh, no, this is definitely fine, i just wanted to check if that was the next step/intended as a separate PR or if it wasn't planned. Happy to land this as-is first.

joostjager · 2026-02-03T16:33:35Z

Intended next step. I had added it to the PR description to avoid the question :)

TheBlueMatt · 2026-02-03T17:05:07Z

Maybe that'll teach me to read (it won't).

TheBlueMatt · 2026-02-04T22:22:21Z

 0x6c => send_hop_noret(0, 1, chan_a, 2, chan_b, 1, &mut p_ctr),
 0x6d => send_hop_noret(2, 1, chan_b, 0, chan_a, 1, &mut p_ctr),

+ // MPP payments


We also need to fuzz the case where the recipient receives an MPP via multiple parts over a single channel. Also probably the case where a forwarding node receives an MPP in multiple parts over a single channel.

Also probably the case where a forwarding node receives an MPP in multiple parts over a single channel.
This should have been covered already on commands 0x71 and 0x73.
Added a commit for the direct multi-part single-channel case.

Squashed it as it was only the two lines for the command.

joostjager · 2026-02-05T12:16:43Z

Tried hitting a panic in PaymentSent for all five mpp commands. Then I discovered #4385. With that applied, Claude came up with the following sequences for mpp:

Command	Description	Fuzz String (hex)
0x70	Direct MPP (multi A-B channels)	`00 70 11 19 1f 11 19 1f 11 19 1f 11 19 1f 11 19 17 11 19 17 11 19 17`
0x71	Hop MPP (multi A-B, single B-C)	`00 71 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x72	Hop MPP (multi A-B, multi B-C)	`00 72 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x73	Hop MPP (single A-B, multi B-C)	`00 73 11 19 1f 11 19 1f 11 19 1f 11 19 1f 21 27 11 19 21 27 11 19 21 27 11 19 21 27 21 27 21 27 21 27 21 27 11 19 1f 11 19 1f 11 19 1f 11 19 1f 17 17 17 17 17 17 17 17`
0x74	Direct MPP (3 parts, single channel)	`00 74 11 19 1f 11 19 1f 11 19 1f 11 19 1f 11 19 17 11 19 17 11 19 17`

This expands the channel monitor consistency fuzz test from 2 channels to 6 channels (3 between A-B and 3 between B-C), enabling future MPP payment testing. Changes: - Extract `connect_peers!` macro from `make_channel!` to avoid duplicate peer connections - Create channel arrays `chan_ab_ids[3]` and `chan_bc_ids[3]` - Store SCIDs in `chan_ab_scids[3]` and `chan_bc_scids[3]` - Use funding transaction versions 1-6 to avoid txid collisions under fuzz hashing (which XORs all bytes to a single byte, causing versions 0-5 to collide between A-B and B-C channel pairs) - Update `test_return!` assertions to expect 3/6/3 channels Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Add multi-path payment (MPP) fuzzing commands that split payments across multiple channels: - send_mpp_payment: direct MPP from source to dest using multiple channels - send_mpp_hop_payment: MPP via intermediate node with multiple channels on either or both hops New fuzz commands: - 0x70: direct MPP 0->1 (uses all 3 A-B channels) - 0x71: MPP 0->1->2, multi channels on first hop (A-B) - 0x72: MPP 0->1->2, multi channels on both hops (A-B and B-C) - 0x73: MPP 0->1->2, multi channels on second hop (B-C) - 0x74: single-channel MPP 0->1 (all parts over one channel) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

After settling all state at 0xff, verify that pending_payments is empty for all nodes. If payments remain stuck indefinitely, that indicates a bug in payment resolution. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

TheBlueMatt

Thanks!

joostjager force-pushed the fuzz-multi-channels branch from e287a1f to 3038033Compare February 2, 2026 11:48

joostjager force-pushed the fuzz-multi-channels branch 2 times, most recently from 81c11a0 to e0ba40eCompare February 3, 2026 15:18

joostjager marked this pull request as ready for review February 3, 2026 15:20

joostjager requested review from TheBlueMatt and valentinewallace and removed request for valentinewallace February 3, 2026 15:20

joostjager changed the title ~~Fuzz mpp payments~~Fuzz multi-part paymentsFeb 3, 2026

TheBlueMatt reviewed Feb 3, 2026
View reviewed changes

joostjager mentioned this pull request Feb 4, 2026
fuzz: add force-close support to chanmon_consistency #4381
Closed

TheBlueMatt reviewed Feb 4, 2026
View reviewed changes

joostjager added this to Weekly Goals Feb 5, 2026

joostjager self-assigned this Feb 5, 2026

joostjagerand others added 2 commits February 6, 2026 10:32

joostjager force-pushed the fuzz-multi-channels branch from a5affab to 61caa03Compare February 6, 2026 09:33

fuzz: assert no stuck payments in chanmon_consistency
0a6b6d4
After settling all state at 0xff, verify that pending_payments is empty for all nodes. If payments remain stuck indefinitely, that indicates a bug in payment resolution. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

joostjager requested a review from TheBlueMatt February 9, 2026 16:04

TheBlueMatt approved these changes Feb 9, 2026
View reviewed changes

TheBlueMatt merged commit 7044bc7 into lightningdevkit:mainFeb 9, 2026
20 of 21 checks passed

github-project-automationBot moved this to Done in Weekly Goals Feb 9, 2026

wpaulino mentioned this pull request Feb 12, 2026
Drive splices to completion in chanmon_consistency #4411
Merged

This was referenced Mar 23, 2026
Fuzz failure backlog #4504
Closed
fuzz: three panics introduced by splice RBF (chanmon_consistency) #4502
Closed