Good morning t-bast, > Please forget about channel jamming, upfront fees et al and simply consider > the parameters I'm > mentioning. It feels to me that these are by nature dynamic channel > parameters (some of them are > even present in `channel_update`, but no-one updates them yet because direct > peers don't take the > update into account anyway). I'd like to raise `htlc_minimum_msat` on some > big channels because > I'd like these channels to be used only for big-ish payments. Today I can't, > I have to close that > channel and open a new one for such a trivial configuration update, which is > sad.
At the risk of once more derailing the conversation: from the MPP trenches, raising the minimum payment size is another headache. The general assumption with MPP is that smaller amounts are more likely to get through, but if anyone is making a significant bump up in `htlc_minimum_msat`, that assumption is upended and we have to reconsider if we may actually want to merge multiple failing splits into one, as well as considering asymmetric splits (in particular asymmetric presplits) because maybe the smaller splits will be unable to pass through the bigger channels but the bigger-side split *might*. On the other hand: one can consider that the use of big payments as an aggregation. For example: a forwarding node might support smaller `htlc_minimum_msat`, then after making multiple such forwards, find that a channel is now heavily balanced towards one side or another. It can then make a single large rebalance via one of the high-`htlc_minimum_msat` channels t-bast is running. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
