📅 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>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:00:57
in reply to nevent1q…pp6l
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:00:57Event JSON
{
"id": "e20d5218abf5129454bc5a8c34df4d5bcd6dd13d315179418562e710bed282cc",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315657,
"kind": 1,
"tags": [
[
"e",
"bf5d675863f97a951d35eeee3ef3828dfc349552a8c3471bf6b8f80c10432a22",
"",
"root"
],
[
"e",
"e775dae2f6fb2734128e1769a71ef5b5b43a36ddbb7b0222daef2bc765415412",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 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",
"sig": "52694bb6bcace5f1fba000d15fe56c623434ac6e7bb3b7050942ea9d2477fb0feec35be66b215be704e44a54840e901a058c9443204dc2440c71d907f8b5b504"
}