š
Original date posted:2020-10-08
š Original message:
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
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-09 13:00:57
in reply to nevent1qā¦q06t
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 13:00:57Event JSON
{
"id": "e775dae2f6fb2734128e1769a71ef5b5b43a36ddbb7b0222daef2bc765415412",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315657,
"kind": 1,
"tags": [
[
"e",
"bf5d675863f97a951d35eeee3ef3828dfc349552a8c3471bf6b8f80c10432a22",
"",
"root"
],
[
"e",
"4bac74b45870ff4fce11c3d6ccd2e630aefa877795e7c8dfa63659a9a3f4746a",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "š
Original date posted:2020-10-08\nš Original message:\nGood morning t-bast,\n\n\u003e Please forget about channel jamming, upfront fees et al and simply consider the parameters I'm\n\u003e mentioning. It feels to me that these are by nature dynamic channel parameters (some of them are\n\u003e even present in `channel_update`, but no-one updates them yet because direct peers don't take the\n\u003e update into account anyway). I'd like to raise `htlc_minimum_msat` on some big channels because\n\u003e I'd like these channels to be used only for big-ish payments. Today I can't, I have to close that\n\u003e channel and open a new one for such a trivial configuration update, which is sad.\n\nAt the risk of once more derailing the conversation: from the MPP trenches, raising the minimum payment size is another headache.\nThe 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*.\n\nOn the other hand: one can consider that the use of big payments as an aggregation.\nFor 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.\nIt can then make a single large rebalance via one of the high-`htlc_minimum_msat` channels t-bast is running.\n\nRegards,\nZmnSCPxj",
"sig": "bf05ff81024c523629dfee30e3e3fa6aa321dba2313ad25792dbf919869d6641236c0267e40aba1e0943f4de73fecc0519ddef40919143a093119cb97fbe6014"
}