{"type":"rich","version":"1.0","author_name":"npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","author_url":"https://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-10-09\n📝 Original message:\nHey Zman,\n\nraising the minimum payment size is another headache\n\u003e\n\nIt's true that it may (depending on the algorithm) lower the success rate\nof MPP-split.\nBut it's already a parameter that node operators can configure at will (at\nchannel creation time),\nso IMO it's a complexity we have to deal with anyway. Making it dynamic\nshouldn't have a high\nimpact on MPP algorithms (apart from failures while `channel_update`s are\npropagating).\n\nTo be fully honest, my (maybe unpopular) opinion about MPP is that it's not\nnecessary on the\nnetwork's backbone, only at its edges. Once the network matures, I expect\nchannels between\n\"serious\" routing nodes to be way bigger than the size of individual\npayments. The only places\nwhere there may be small or almost-empty channels are between end-users\n(wallets) and\nrouting nodes.\nIf something like Trampoline were to be implemented, MPP would only be\nneeded to reach a\nfirst routing node (short route), that routing node would aggregate the\nparts and forward as a\nsingle HTLC to the next routing node. It would be split again once it\nreaches the other edge\nof the network (for a short route as well). In a network like this, the MPP\nroutes would only have\nto be computed on a small subset of the network, which makes brute-force\nalgorithms completely\nreasonable and the success rate higher.\n\nThis is an interesting fork of the discussion, but I don't think it's a\ngood reason to prevent these\nparameters from being updated on live channels, what do you think?\n\nBastien\n\n\nLe jeu. 8 oct. 2020 à 22:05, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e a écrit :\n\n\u003e Good morning t-bast,\n\u003e\n\u003e \u003e Please forget about channel jamming, upfront fees et al and simply\n\u003e consider the parameters I'm\n\u003e \u003e mentioning. It feels to me that these are by nature dynamic channel\n\u003e parameters (some of them are\n\u003e \u003e even present in `channel_update`, but no-one updates them yet because\n\u003e direct peers don't take the\n\u003e \u003e update into account anyway). I'd like to raise `htlc_minimum_msat` on\n\u003e some big channels because\n\u003e \u003e I'd like these channels to be used only for big-ish payments. Today I\n\u003e can't, I have to close that\n\u003e \u003e channel and open a new one for such a trivial configuration update,\n\u003e which is sad.\n\u003e\n\u003e At the risk of once more derailing the conversation: from the MPP\n\u003e trenches, raising the minimum payment size is another headache.\n\u003e The general assumption with MPP is that smaller amounts are more likely to\n\u003e get through, but if anyone is making a significant bump up in\n\u003e `htlc_minimum_msat`, that assumption is upended and we have to reconsider\n\u003e if we may actually want to merge multiple failing splits into one, as well\n\u003e as considering asymmetric splits (in particular asymmetric presplits)\n\u003e because maybe the smaller splits will be unable to pass through the bigger\n\u003e channels but the bigger-side split *might*.\n\u003e\n\u003e On the other hand: one can consider that the use of big payments as an\n\u003e aggregation.\n\u003e For example: a forwarding node might support smaller `htlc_minimum_msat`,\n\u003e then after making multiple such forwards, find that a channel is now\n\u003e heavily balanced towards one side or another.\n\u003e It can then make a single large rebalance via one of the\n\u003e high-`htlc_minimum_msat` channels t-bast is running.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201009/cdca8cc5/attachment-0001.html\u003e"}