Uh oh!
There was an error while loading. Please reload this page.
fuzz: add chanmon holder signer fuzz ops - #4660
Conversation
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
994d779 to
ba0e4c5CompareGood - the fuzzer uses I've now thoroughly reviewed the entire diff. The changes are correct:
No issues found. |
valentinewallace
left a comment
There was a problem hiding this comment.
Are there any heuristics on when to save vs spend fuzz opcodes? I'm not sure how to make that call, probably @TheBlueMatt should take a look. We can always update post-merge though, I suppose.
| // Keep holder signer unblocks adjacent to the existing signer op | ||
| // bytes. The helper re-enables both holder-side operations for |
There was a problem hiding this comment.
"Adjacent" makes me think these bytes should be 0xd3..d5, so I find that a bit confusing.
There was a problem hiding this comment.
Hm yes they were adjacent in an earlier version of this. Moved.
| self.node.timer_tick_occurred(); | ||
| } | ||
| // Re-enables holder-side signer operations and asks the chain monitor to |
There was a problem hiding this comment.
I think the commit message could be improved. It references a larger refactor, which I'm not sure is helpful as someone without much context, and I don't think it explains the "why" of the diff as it is stand-alone.
There was a problem hiding this comment.
Also a left-over from cherry-picking these changes, fixed.
| // bytes. The helper re-enables both holder-side operations for | ||
| // every signer owned by the selected node, matching the existing | ||
| // key-manager-wide blocking model. | ||
| 0xe4 => harness.nodes[0].enable_holder_signer_ops(), |
There was a problem hiding this comment.
Other bytes of this fuzzer seem much more granular and enable/unblock on a per-op and per-channel basis. Maybe we could document why we're taking a more sweeping approach here? Also "the existing key-manager-wide blocking model" -- what does that mean?
There was a problem hiding this comment.
It's to save fuzz opcode byte space. Also not sure which trade-off is right here.
"the existing key-manager-wide blocking model" refers to signing being disabled for all channels at once, and enabling mirroring that. Improved comment.
ldk-reviews-bot
commented
Jun 5, 2026
👋 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. |
Allow chanmon consistency fuzz inputs to block holder-side signer operations and later retry monitor-driven claim signing. This gives force-close sequences a way to cover local on-chain claim construction while reusing the harness' existing signer-op blocking machinery.
ba0e4c5 to
633aff4Compare
TheBlueMatt
left a comment
There was a problem hiding this comment.
Seems fine to do this IMO but also weird to do it when we don't support FCing? Doesn't seem like a large commit to just include in an FC PR (or as a followup).
joostjager
commented
Jun 8, 2026
As mentioned in the PR description, I split it out to discuss and review separately. The force close PR is big already. But agreed that this is merging code that doesn't do much at the moment. Can cherry-pick it back into the bigger PR too. |
joostjager
commented
Jun 18, 2026
Closing because of reason mentioned above, but will carry over conclusion to the FC PR. |
Allow chanmon consistency inputs to block and later unblock holder-side signing operations. This lets focused force-close fuzzing reuse the signer-op machinery without carrying the larger mining and settlement model.
I split this out ahead of the broader force-close fuzzing work so we can review the signer-op modeling independently. The main question is whether these holder-side unblock actions are worth spending dedicated chanmon consistency opcodes on, or whether we should keep the opcode surface smaller and rely on final cleanup to re-enable them.