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.
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
