> 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.
Right, the trade-offs here are really tricky to navigate and to whatever extent this is possible the choice of what trade-offs to make should be pushed to the user. For example, not knowing the real time channel balances clearly hurts routing success. If this degraded routing success from 95 percent to say 90 percent the network as a whole would probably be willing to pay that routing success "cost" to ensure better balance privacy. But if it degraded routing success from 95 percent to say 50 percent I expect much of the network wouldn't be willing to put up with that terrible routing success percentage and routing nodes would probably seek to broadcast their channel balances either in gossip or out of band. Similarly a routing node not knowing the source of the payment and the intermediate nodes on the route is fine (it is clearly *much* better for privacy) assuming jamming attacks occur rarely. But if the network is being paralyzed regularly by jamming attacks a routing node is going to show a lot more interest in which Lightning node it is routing payments for and which other Lightning nodes are also part of the route. You aren't going to want to continue to be subject to jamming attacks by the same Lightning node. Hence I stick by this from a protocol developer perspective. "Decisions protocol developers make will impact what data can be collected and how easy that data is to collect (there are already some tricky trade-offs with regards to privacy, routing success and transparency for when things go wrong) but beyond that protocol developers should leave it to others." A protocol developer (and individual implementation developer I guess) is going to have to wrestle with these trade-offs and to what extent options can be pushed to the user. But protocol reputation tokens that can be sold or transferred to an attacker or worse collected through gaming the system, ouch. The protocol developer has taken a problem (jamming attacks) that already exists and added an additional problem (reputation) which no doubt will be addressed by adding an additional problem on top of that and another on top of that etc etc. -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ------- Original Message ------- On Sunday, December 4th, 2022 at 02:03, Matt Corallo <[email protected]> wrote: > > 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 > _______________________________________________ > Lightning-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
