You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Make use of lightning::util::anchor_channel_reserves to improve anchor reserve estimation? #668
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.
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).
Activity
tnull commentedon Feb 5, 2026
We explored using
lightning::util::anchor_channel_reservesin #674 and found thatAnchorChannelReserveContext::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
AnchorChannelReserveContextparameters 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 useAnchorChannelReserveContext::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_reservesutil 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).