rich1.0npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0shttps://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0snjumphttps://nostr.ae📅 Original date posted:2020-10-09 📝 Original message: Hey Zman, raising the minimum payment size is another headache > It's true that it may (depending on the algorithm) lower the success rate of MPP-split. But it's already a parameter that node operators can configure at will (at channel creation time), so IMO it's a complexity we have to deal with anyway. Making it dynamic shouldn't have a high impact on MPP algorithms (apart from failures while `channel_update`s are propagating). To be fully honest, my (maybe unpopular) opinion about MPP is that it's not necessary on the network's backbone, only at its edges. Once the network matures, I expect channels between "serious" routing nodes to be way bigger than the size of individual payments. The only places where there may be small or almost-empty channels are between end-users (wallets) and routing nodes. If something like Trampoline were to be implemented, MPP would only be needed to reach a first routing node (short route), that routing node would aggregate the parts and forward as a single HTLC to the next routing node. It would be split again once it reaches the other edge of the network (for a short route as well). In a network like this, the MPP routes would only have to be computed on a small subset of the network, which makes brute-force algorithms completely reasonable and the success rate higher. This is an interesting fork of the discussion, but I don't think it's a good reason to prevent these parameters from being updated on live channels, what do you think? Bastien Le jeu. 8 oct. 2020 à 22:05, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit : > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201009/cdca8cc5/attachment-0001.html>