rich1.0René Pickhardt [ARCHIVE] (npub1zl…d2k4w)https://yabu.me/npub1zlxd3xlzjhq2ue03e5m5p2w6mp8v3dkhq5r39flsftjjsje04wvsdd2k4wnjumphttps://yabu.me📅 Original date posted:2019-03-29 📝 Original message: Dear ZmnSCPxj and fellow lightning developers, I want to point out two things and make a suggestion for a new gossip message. 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. > Intuitively (without simulation). I encourage to make that process not deerministic but rather probabilistic. It would be good if everyone had a different set of channels. (which is somewhat achieved with everyone keeping their local view) Nodes still need to track their direct channels (so they are implicitly > always in the routemap). > I strongly advice that the local view should be extended. Every node should always track their friends of a friend network. Maybe we could even create a new gossip query message `query_ask_egonetwork` that asks for the egonetwork of a node (the egonetwork are all the direct friends of a node together with their friendships) every node knows at least the nodes in their ego network and over time also the edges between them. If I was interested in my friend of a friend network I could just send the `query_ask_egonetwork` message to all my peers. Best Rene 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. > > Regards, > ZmnSCPxj > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190329/33d0bd13/attachment-0001.html>