fuzz: model chanmon mempool mining#4657
Draft
joostjager wants to merge 1 commit into
Draft
Conversation
Add a modeled mempool and wallet-backed transaction relay to the chanmon consistency target. Broadcast transactions are admitted through explicit relay steps, mined by block commands, and then replayed to the monitor and manager through the harness chain state. Track confirmed UTXOs so mempool admission can reject duplicate or unknown inputs, model direct RBF conflicts, and keep wallet UTXOs in sync with confirmed change outputs.
|
👋 Hi! I see this is a draft PR. |
Contributor
Author
|
@wpaulino FYI, this may intersect with the existing splice fuzzing failures you’re looking at. This PR makes splice transaction mining in |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This prepares
chanmon_consistencyfor force-close fuzzing by making its chain model closer to the environment LDK sees in normal operation.Force-close scenarios depend heavily on transaction timing: claims may be broadcast, replaced, confirmed, followed by additional claims, and later become spendable only after more blocks. The previous harness mostly folded transaction confirmation into sync-style actions, which made it harder to express those flows accurately and made future force-close coverage depend on shortcuts in the test harness.
The updated model gives the harness an explicit mempool and block-mining path. Broadcast transactions can be relayed into the modeled mempool, mined into harness blocks, and then replayed to both monitors and managers through chain callbacks. The harness also tracks confirmed UTXOs and wallet change so later splice, anchor, and claim transactions have a realistic view of what can be spent.
This should make upcoming force-close fuzzing changes easier to review: first establish a more faithful chain environment, then add the force-close-specific scenarios and invariants on top of it.