Clara Shikhelman [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-08 📝 Original message: Hi Matt, > Indeed, it may ...
📅 Original date posted:2022-12-08
📝 Original message:
Hi Matt,
> 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.
>
>
This could be a good idea, but I think that it shouldn't be a prerequisite
for unconditional fees.
> 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.
>
I agree that fees and privacy are important, and play a bigger role in
transactions that are not very time sensitive. That being said, locking up
funds in channels knowing that with a decent probability the nodes along
the route won't be compensated at all is not great. If it's on a small
scale, we don't have to think about this as "wrong". The sender is asking
the nodes along the route to provide a service (lock up funds and provide
information about liquidity) and is paying a small fee for it.
Speaking of "wrong" - on Monday we'll be discussing further parameters to
be considered in reputation schemes. I think that your input will be very
valuable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221208/329f785d/attachment.html>;
📝 Original message:
Hi Matt,
> 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.
>
>
This could be a good idea, but I think that it shouldn't be a prerequisite
for unconditional fees.
> 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.
>
I agree that fees and privacy are important, and play a bigger role in
transactions that are not very time sensitive. That being said, locking up
funds in channels knowing that with a decent probability the nodes along
the route won't be compensated at all is not great. If it's on a small
scale, we don't have to think about this as "wrong". The sender is asking
the nodes along the route to provide a service (lock up funds and provide
information about liquidity) and is paying a small fee for it.
Speaking of "wrong" - on Monday we'll be discussing further parameters to
be considered in reputation schemes. I think that your input will be very
valuable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221208/329f785d/attachment.html>;