What is the reason behind `limitdescendantcount`? #14867

I cannot find discussion on it and I am not sure if I understand it properly, so first let me try to explain what I understand it to be:

If I spend an unconfirmed transaction that has and output that' been spent over limitdescendantcount times, then my transaction will not be accepted in the mempool.

If this is correct, then why does it make sense to have this limitation? Why does the descendant count of the transaction I want to spend have anything to do with my transaction?

The reason why I ask this is, because this was recently used to (intentionally or not) DoS attack coinjoins in Wasabi: https://github.com/zkSNACKs/WalletWasabi/issues/904

Also note, increasing the limit is not a solution, because they can just make that many more transactions. What I will do is to refuse the registration from the transaction after he first disrupted the coinjoin, but I would like to understand why the limitation is there in the first place or if I even understand this correctly.

This was discussed on the bitcoin-dev mailing list and in some prior PRs a few years ago:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010221.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011401.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011722.html

See also #6771, where the current limits were set.

This is an anti-DoS measure -- ideally we wouldn't need restrictions like this (for instance, recently @TheBlueMatt proposed on the mailing list that we relax this restriction slightly to accommodate lightning better https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001697.html).

Thank you @sdaftuar! This looks very useful! I'll close this issue after I chew through the links (or continue the conversation here or on the mailing list if I have something valuable to add.)