Good morning Ariel,
> > A good pruning heuristic is "channel capacity", which can be checked > > onchain (the value of the UTXO backing the channel is the channel capacity). > > It is good to keep channels with large capacity in the routemap, because > > such large channels are more likely to successfully route a payment than > > smaller channels. > > So it is reasonable to delete channels with low capacity when the routemap > > memory is becoming close to full. > > I'm generally concerned about these heuristics because any time nodes > can game a heuristic they will be expected to do so. > Gaming a heuristic can be good or bad depending on the side-effects. > One side effect of the "channel capacity" heuristic is more reliable > payments but another side effect is that low capacity (but possibly > reliable) channels are neglected The heuristic is gameable at the cost of devoting more capacity to Lightning. It is also quite incentive-compatible to source nodes with limited storage but which may need to forward arbitrary amounts to arbitrary nodes. Low capacity channels cannot be used at all if their capacity is below my payment amount, no matter how reliable they may be, unless I do multipart payments, which increases base fee paid. > > > It seems to me that s/aggregate-channel/high-capacity-channel/g in your > > idea would still work. > > In effect, the high-capacity channel is very likely to successfully route > > in either direction. > > But if by chance it falls into a state where it is unable to route in one > > direction or other, the intermediate node has other, lower-capacity > > channels that it can use JIT-Routing with to improve the directionality of > > the high-capacity channel. > > Nothing in the JIT-Routing idea requires that the rebalancing loop is > > small, only that a loop exists. > > Nodes still need to track their direct channels (so they are implicitly > > always in the routemap). > > But payee nodes making BOLT1 invoices could also provide `r` routes in the > > invoice, with the given routes being from nodes with high-capacity > > channels, so that even if the intermediate channels are pruned due to low > > capacity, it is possible to get paid. > > Without low capacity channels spontaneous payments would not work. They would not be prevented a priori, only if all channels it has are too small to be kept in memory by typical source nodes. If I truly wanted to help such a node, I might make a large capacity channel to it and then send my spontaneous payment. > Or > they would depend on asking for an invoice under the hood. Which I think is better for spontaneous payments. > It feels to me that at some point, someone with complete knowledge of > the network needs to eb employed. Indeed. See the trampoline payments thread also under discuasion. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
