Skip to content

Add experimental support for HTLC endorsment reputation algorithm #2425

Open
@ariard

Description

@ariard

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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions