Good morning Matt, In my implementation that might get into c-lightning (i.e. my pull request, which I should probably update some time before universe heat death) the r= fields are preferred, but if unable to find routes to the nodes indicated in the r= fields, we always fall back to our known node map before failing completely.
Basically, we retry each r= field until all routes to the node indicated have failed (no more viable routes), then move to the next r= field (if exists), or if no more r= fields, try finding the node itself directly in the node map. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, October 8, 2018 12:38 PM, Matt Corallo <lf-li...@mattcorallo.com> wrote: > Resending due to ML bugs.... > > On a related note, it would be nice to get some clarity on appropriate > usage of the r= field here. > The way I had implemented it initially was that if an invoice had an r= > field any publicly-discovered last-hop routes would be ignored as the r= > data is most likely more up-to-date than any public route rumor information. > However, if it's only used as a hint and only one or two out of > potentially many channels are included in it, that may make little sense. > > Not really sure what the appropriate guidance should be, probably > something like SHOULD prefer to use invoice-r=-provided-hints over > publicly-discovered routes however MAY use other last-hops in case a > substantially better route is known? > > Matt > > On 09/19/18 22:10, Rusty Russell wrote: > > > Hi all, > > > > I'm considering a change to c-lightning, where `invoice` would > > > > > > automatically append an 'r' field for a channel which has sufficient > > incoming capacity for the amount (using a weighted probability across > > our peers). > > > > This isn't quite what 'r' was for, but it would be a useful > > > > > > hint for payment routing and also potentially for establishing an > > initial channel. This is an issue for the Blockstream Store which > > deliberately doesn't advertize an address any more to avoid > > centralization. > > Thoughts welcome! > > Rusty. > > > > Lightning-dev mailing list > > Lightning-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
