Description
See the review of the HTLC endorsment scheme here. While I think the mitigation is very limited to mitigate against advanced channel jamming adversaries due to the native end-to-end construction nature of payment path in today’s LN and therefore anti-dos tokens negotiated end-to-end are more appropriate (as raised on the mailing list), I think the recommendation of HTLC endorsment reputation algorithm have an independent interest for fee-bumping reservers management.
See this is quite related to #2320 and there has been discussion in the past to what to do avoid “flood-and-loot” exposure for pending HTLC on the outgoing channels (iirc on #bitcoin-rust IRC chan years ago), the reputation algorithm could be useful there, independently what jamming solution emerges as the most robust from a liquidity “crypto-economic” management and bandwidth consumption viewpoint.
The first practical step can be to abstract more the HTLC intercepting interface introduced with #1835 to feed them to a decision-making process (such process can be its own module / repository under the org repo like we’re doing for the ldk-lsp-client thing until it’s more mature to be in main-tree and we’re sure we have a set of folks happy to long-term maintain it).