fuzz: add mempool_dag fuzzer for transaction dependency testing #33038

1. 
   frankomosh commented at 3:55 pm on July 22, 2025: none

   adds a new target, mempool_dag, to test mempool DAG invariants by constructing transaction chains with controlled parent/child dependencies. main focus areas include:

   a. ancestor / descendant count and size limits (-limitancestorcount, -limitancestorsize, -limitdescendantcount, -limitdescendantsize)

   b. TRUC-policy interaction with non-TRUC transactions

   c. fee-rate consistency after partial package eviction

   Invariants are asserted after every successful AcceptToMemoryPool. parent mask systematically constructs transaction dependency chains used here.

2. DrahtBot added the label Tests on Jul 22, 2025
3. 
   DrahtBot commented at 3:55 pm on July 22, 2025: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33038.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

   LLM Linter (✨ experimental)

   Possible typos and grammar issues:

   • globals issues -> global issues [“globals issues” is a typo; should read “global issues”]

   drahtbot_id_4_m

4. fuzz: add mempool_dag fuzzer for transaction dependency testing

   Tests the mempool DAG structure by creating transaction dependency chaining(parent child relationships) and validating ancestor/descendant limits, fee consistency,  and topology invariants during  AcceptToMemoryPool()

   4c3e140419
5. frankomosh force-pushed on Jul 22, 2025
6. DrahtBot added the label CI failed on Jul 22, 2025
7. 
   DrahtBot commented at 5:03 pm on July 22, 2025: contributor

   🚧 At least one of the CI tasks failed. Task lint: https://github.com/bitcoin/bitcoin/runs/46490093277 LLM reason (✨ experimental): The CI failure is due to errors in the lint check related to trailing whitespace and missing trailing newline in the file src/test/fuzz/mempool_dag.cpp.

   Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

   • Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.

   • A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.

   • An intermittent issue.

   Leave a comment here, if you need help tracking down a confusing failure.

8. in src/test/fuzz/mempool_dag.cpp:64 in 4c3e140419

   59+    g_setup->m_node.validation_signals->SyncWithValidationInterfaceQueue();
   60+}
   61+
   62+void SetMempoolConstraints(ArgsManager& args, FuzzedDataProvider& fuzzed_data_provider)
   63+{
   64+    // setting mempool limits to ranges which are reasonable, for DAG testing
   

   ---

   ---

   

   maflcko commented at 5:48 pm on July 22, 2025:

   this is just copy-pasted from src/test/fuzz/tx_pool.cpp, same for the function above, with slight modifications.

   it would be good to explain what exactly you are trying to test and why the existing fuzz targets are insufficient. Then, it would be good to provide coverage reports to show you have achieved your goal. Finally, it would be good to put this in the existing src/test/fuzz/tx_pool.cpp file, so that shared code can be re-used.

   ---

   

   frankomosh commented at 7:18 pm on July 22, 2025:

   You are right about the duplication. The main difference is I wanted to systematically construct transaction dependency chains, which I thought to do in a seperate target because tx_pool.cpp tests only individual transaction acceptance(and I did not want to mess with it anyway).

   The goal is to target directed acyclic graph specific edge cases in ancestor/descendant limit enforcement that random transaction generation maybe does not hit.

   ---

   

   frankomosh commented at 7:18 pm on July 22, 2025:

   i’ll generate report and only proceed if there is new coverage
9. frankomosh marked this as a draft on Jul 22, 2025
10. DrahtBot removed the label CI failed on Jul 22, 2025
11. 
    maflcko commented at 7:08 am on July 23, 2025: member

    @frankomosh Is this code llm generated?
12. 
    frankomosh commented at 7:15 am on July 23, 2025: none

    @frankomosh Is this code llm generated?

    have had some LLM assistance, especially in structuring and best c++ practices. Is it a problem @maflcko

13. 
    maflcko commented at 7:51 am on July 23, 2025: member

    Historically LLM generated pull requests in this repo were easy to dismiss, because they were obviously wrong on the surface level and usually the tests and CI were failing in similarly obvious ways. However, it now seems that non-trivial LLM generated pull request in this repo looked reasonable on a first glance (compiles and passes CI), but they still miss the point (adding tests without increasing test coverage, or adding features that are useless and counter-productive #32949 (comment), …)

    The problem with that is that it eats review resources for no gain, because the pull request will most likely be dismissed and all review feedback (if there was one) likely won’t train a human, but at best only ends up in the training set of the next LLM.

    Not sure if there is a solution to the problem, just wanted to share the problem, since you asked for it.

14. 
    frankomosh commented at 8:52 am on July 23, 2025: none

    Historically LLM generated pull requests in this repo were easy to dismiss, because they were obviously wrong on the surface level and usually the tests and CI were failing in similarly obvious ways. However, it now seems that non-trivial LLM generated pull request in this repo looked reasonable on a first glance (compiles and passes CI), but they still miss the point (adding tests without increasing test coverage, or adding features that are useless and counter-productive #32949 (comment), …)

    The problem with that is that it eats review resources for no gain, because the pull request will most likely be dismissed and all review feedback (if there was one) likely won’t train a human, but at best only ends up in the training set of the next LLM.

    Not sure if there is a solution to the problem, just wanted to share the problem, since you asked for it.

    Historically LLM generated pull requests in this repo were easy to dismiss, because they were obviously wrong on the surface level and usually the tests and CI were failing in similarly obvious ways. However, it now seems that non-trivial LLM generated pull request in this repo looked reasonable on a first glance (compiles and passes CI), but they still miss the point (adding tests without increasing test coverage, or adding features that are useless and counter-productive #32949 (comment), …)

    The problem with that is that it eats review resources for no gain, because the pull request will most likely be dismissed and all review feedback (if there was one) likely won’t train a human, but at best only ends up in the training set of the next LLM.

    Not sure if there is a solution to the problem, just wanted to share the problem, since you asked for it.

    Aah.. I see your point. Part of the reason I am rasing PR here this is because I am unable to do large scale fuzzing myself. Anyway i’ll close it and investigate privately these mempool issues and if I find concrete evidence of my suspicions then I will raise them through an issue or something.

15. frankomosh closed this on Jul 23, 2025

    ---

16. frankomosh deleted the branch on Jul 23, 2025
17. frankomosh restored the branch on Jul 23, 2025
18. frankomosh deleted the branch on Jul 23, 2025

Contributors
frankomosh DrahtBot maflcko

Labels
Tests