bypass_{csv,cltv} option to testmempoolaccept
#25570
`maxfeerate` becomes a member of an "options" object rather than
a positional argument.
The idea is that any new parameters in the future will also go into
options.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
MemPoolBypass by w0xlt){Dump,Load}Mempool from ArgsManager by dongcarl)CheckSequenceLocksAtTip() by hebasto)If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
One small note: multi-line comments are evil. Consider a valid code
0/*
1func(/*param*/ p);
comment captures entire function. Consider
0struct ProcessTxCriteria {
1 bool test_accept;
2 std::optional<MempoolTestCriteria> test_criteria;
3} defaultTxCriterias = {};
4
5ProcessTransaction(txr, const ProcessTxCriteria& criterias = defaultTxCriterias);
This is for test_accepts only, and not allowed in an actual submission
to mempool - see assert statements.
Provide an option to bypass BIP68 nSequence and nLockTime checks. This
means clients can use testmempoolaccept to check whether L2 transaction
chains (which typically have timelock conditions) are valid without
submitting them. Note that BIP112 and BIP65 are still checked since they
are script (non-contextual) checks. This does not invalidate any
signature or script caching.
Co-authored-by: glozow <gloriajzhao@gmail.com>
Co-authored-by: glozow <gloriajzhao@gmail.com>
Test the bypass_timelock options in testmempoolaccept. This lets us
bypass BIP68 relative locktime checks (in nSequence) and absolute
locktime checks (in nLocktime).
Co-authored-by: glozow <gloriajzhao@gmail.com>
OP_CSV and OP_CLTV script checks are still done,
so setting bypass_timelocks=True doesn't mean that
bad scripts pass.
Co-authored-by: glozow <gloriajzhao@gmail.com>
🐙 This pull request conflicts with the target branch and needs rebase.
Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a “draft”.
I’m going to close this for now. I don’t think there is a need to have this PR open yet, when it’s building on multiple other PRs, which themselves still need conceptual review. You can always link to branches with example future changes, from the base PRs.