The process requires a nuanced understanding of setting up lightning and bitcoind nodes, which is a task that few developers have mastered due to the considerable time commitment required for such technical endeavors. This testing approach has been somewhat rare, given the expertise and time required from the few developers proficient in these areas.

The email further elaborates on the requirements for conducting such tests, indicating that the amount in each channel isn't a critical factor as long as transactions can exceed the GetDustThreshold, ensuring they are not classified as dust. For effective testing, having at least two channels is necessary, with a possible third to facilitate liquidity rebalancing. Antoine clarifies that there's no specific need for volunteers to have channels with each other or any particular network topology, aside from a basic routing node setup. Additionally, he mentions that Tor connections are not essential for testing simpler scenarios.

Antoine also references a years-old gist (visit the gist here) that documents transaction-relay jamming attacks, suggesting its relevance and applicability to current challenges, with the notable exception of a "replacement cycling attack" not being identified until two years after it was initially overlooked. This oversight signifies a missed opportunity within the Bitcoin community to address a significant vulnerability sooner.