Skip to content

Make use of lightning::util::anchor_channel_reserves to improve anchor reserve estimation? #668

Open

Description

@tnull

Rather than always requiring the user a flat fee, we could consider to make use of the changes in
lightningdevkit/rust-lightning#3487 to allow for a more detailed estimation.

Activity

  1. tnull commented on Feb 5, 2026

    @tnull
    CollaboratorAuthor

    We explored using lightning::util::anchor_channel_reserves in #674 and found that AnchorChannelReserveContext::default() results in reserve values that are unfeasibly high for most (edge) users.

    We played around with the numbers there, and it seems we'll have to set really low AnchorChannelReserveContext parameters to arrive at reasonable (comaparable to our current default) reserve values. So, just as before, it will be very hard to set sane default parameters that make sense for ~all or ~most users. It likely comes down to 'user profiles': if you run a forwarding node that is exposed to a lot of HTLC-related risks, you might want to bump the numbers or use AnchorChannelReserveContext::default() numbers. Most edge nodes however likely want to considerably reduce these numbers.

    Hence, most users will continue to have a very hard time to wrap their head around what risk they are taking and what numbers they should pick here, which is exactly what we hoped to improve upon by using the anchor_channel_reserves util over just having them choose some per-channel reserve value.

    So, at some point it might make sense to introduce the notion of 'user profiles' as a general concept, but I'm not sure right now is the right time to do that. So I think we should just kick the can down the road a bit further, and revisit this issue some time down the road, maybe in conjunction with Server-specific behavior (cc @benthecarman).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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