Fuzz mpp payments #4367
Fuzz mpp payments #4367
Conversation
|
👋 Hi! I see this is a draft PR. |
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]` - Start funding transaction versions at 1 to avoid Version(0) edge cases - 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) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
joostjager
force-pushed
the
fuzz-multi-channels
branch
from
e287a1f to
3038033
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4367 +/- ##
==========================================
- Coverage 86.09% 85.99% -0.10%
==========================================
Files 156 156
Lines 102804 102641 -163
Branches 102804 102641 -163
==========================================
- Hits 88508 88267 -241
- Misses 11788 11866 +78
Partials 2508 2508
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@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? |
2 participants
This PR is aiming to increase fuzz coverage generally, and for async persistence of channel monitors specifically. Helpful for increasing confidence that #4345 (which makes use of async persistence) is stable to use.
Changes
chanmon_consistencyfuzz test from 2 to 6 channels (3 per peer pair)New fuzz commands
0x70: Direct MPP A→B using all 3 channels0x71-0x73: MPP via intermediate node with multi-channel variants on first hop, both hops, or second hopFollow-up
Force-closing one of the channels