lightningd: default public htlc_maximum_msat to 25% of channel capacity#9311
lightningd: default public htlc_maximum_msat to 25% of channel capacity#9311nGoline wants to merge 2 commits into
Conversation
Andezion
left a comment
Andezion
left a comment
There was a problem hiding this comment.
Does htlc_maximum_msat get updated?
I looked at update_channel_from_inflight() in peer_control.c:2251. It updates funding_sats and the reserve after a splice, but I could not find where it also updates htlc_maximum_msat (or htlc_minimum_msat). I checked channel_gossip.c too and did not see anything there either
If I'm right - then
Splice-in (channel gets bigger) - htlc_maximum_msatstays the same old number. So it becomes a smaller and smaller part of the new, bigger capacity. This does not break any rule, but the channel ends up more limited than the 25% default was supposed to give, and the node owner has no way to know this happened. Also - if different channels end up with very different max/capacity numbers just because some were spliced and some were not, could that give away information too?
Splice-out (channel gets smaller) - could htlc_maximum_msat end up bigger than the new, smaller capacity? That would break the BOLT7 rule that says htlc_maximum_msat must be <= capacity. It looks like this would fix itself the next time lightningd restarts (because channel_htlc_maximum_default() checks and lowers the stored value again when the channel is loaded), or if someone runs setchannel. But until then, could a bad channel_update get sent out to the network?
What do you think?
| * configured --htlc-maximum-msat (AMOUNT_MSAT(-1ULL) if unset). Public | ||
| * channels default to 25% of capacity for privacy; private channels and an | ||
| * explicit setting use the full amount, all capped at what we can send. */ | ||
| struct amount_msat channel_htlc_maximum_default(const struct channel *channel, |
There was a problem hiding this comment.
channel_htlc_maximum_default() doesn't clamp the result against channel->htlc_minimum_msat. With the previous capacity default this was effectively unreachable, but with a 25% ofcapacity default it's now realistic for small public channels combined with a non-default --htlc-minimum-msat, producing a channel_update with htlc_maximum_msat < htlc_minimum_msat (channel becomes unroutable). Should this function also do deflt = amount_msat_max(deflt, channel->htlc_minimum_msat) before the final cap, or at least log a warning when that happens?
… capacity The Oakland privacy proposal (Lightning Dev Summit) observes that probing for where payments went is much harder when the htlc maximum is well below the publicly-known channel capacity. Default public channels to 25% of capacity; update the setchannel test to expect this, xfail until the next commit implements it. Changelog-None
For publicly announced channels, when --htlc-maximum-msat is not set, advertise 25% of the channel capacity (capped by what we can actually send) rather than the full capacity: a maximum well below the publicly known capacity makes probing for where payments flow much harder. Private channels, whose capacity is not public, keep the full default. Changelog-Changed: Config: public channels now default `htlc-maximum-msat` to 25% of capacity (was full capacity), for better payment privacy.
9271abb to
16fbc32
Compare
2 participants
Implements the "Oakland" privacy proposal from the Lightning Dev Summit (reaffirmed at the Vienna summit): for publicly announced channels, default the advertised
htlc_maximum_msatto 25% of channel capacity (capped by what we can actually send) when the operator has not set--htlc-maximum-msat. A maximum well below the publicly-known capacity makes probing for where payments flow significantly harder.Scope:
--htlc-maximum-msatorsetchannel.Closes #9173