fuzz: add chanmon holder signer fuzz ops#4660
Conversation
|
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
joostjager
force-pushed
the
fuzz-chanmon-holder-signer-ops
branch
from
994d779 to
ba0e4c5
Compare
|
Good - the fuzzer uses I've now thoroughly reviewed the entire diff. The changes are correct:
No issues found. |
valentinewallace
left a comment
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.
|
👋 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.
joostjager
force-pushed
the
fuzz-chanmon-holder-signer-ops
branch
from
ba0e4c5 to
633aff4
Compare
4 participants
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.