Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-03 📝 Original message: On 11/15/22 12:09 PM, ...
📅 Original date posted:2022-12-03
📝 Original message:
On 11/15/22 12:09 PM, Clara Shikhelman wrote:
> Matt – I don't know that I agree with "... upfront payments kinda kill the lightning UX ...". I
> think that upfront fees are almost essential, even outside the context of jamming. This also helps
> with probing, general spam, and other aspects. Furthermore, I think that the UX is very explainable,
Indeed, it may be explainable, but its still somewhat painful, I think. I do wonder if we can enable
probing via a non-HTLC message and do immediate pre-send-probing to avoid paying upfront fees on
paths that will fail.
> and in general nodes shouldn't be motivated to send a lot of failed payments, and should adopt
> better routing strategies.
I don't think so - today there are at least three different routing goals to maximize - (a) privacy,
(b) fees, (c) success rate. For "live" payment, you probably want to lean towards optimizing for
success rate, and many nodes do today by default. But that isn't the full story - many nodes do
background rebalancing and they prefer to take paths which optimize for fees, trying many paths they
think are likely to fail to see if they can rebalance with lower fees. I don't think we should tell
those users/use-cases that they aren't allowed to do that or they're doing something "wrong" - I
think choosing to optimize for fees (or, in the future, privacy) is an important thing to allow, and
ideally make as reliable as possible, without charging extra for it.
Matt
📝 Original message:
On 11/15/22 12:09 PM, Clara Shikhelman wrote:
> Matt – I don't know that I agree with "... upfront payments kinda kill the lightning UX ...". I
> think that upfront fees are almost essential, even outside the context of jamming. This also helps
> with probing, general spam, and other aspects. Furthermore, I think that the UX is very explainable,
Indeed, it may be explainable, but its still somewhat painful, I think. I do wonder if we can enable
probing via a non-HTLC message and do immediate pre-send-probing to avoid paying upfront fees on
paths that will fail.
> and in general nodes shouldn't be motivated to send a lot of failed payments, and should adopt
> better routing strategies.
I don't think so - today there are at least three different routing goals to maximize - (a) privacy,
(b) fees, (c) success rate. For "live" payment, you probably want to lean towards optimizing for
success rate, and many nodes do today by default. But that isn't the full story - many nodes do
background rebalancing and they prefer to take paths which optimize for fees, trying many paths they
think are likely to fail to see if they can rebalance with lower fees. I don't think we should tell
those users/use-cases that they aren't allowed to do that or they're doing something "wrong" - I
think choosing to optimize for fees (or, in the future, privacy) is an important thing to allow, and
ideally make as reliable as possible, without charging extra for it.
Matt