Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-08 📝 Original message: Matt Corallo <lf-lists at ...
📅 Original date posted:2018-10-08
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
> 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.
There were originally two proposed uses of r=:
1. For payments via unannounced channels.
2. For routing hints for nodes which don't have a complete topology.
> 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?
Note that r can provide zero-or-more full routes, not just a single hop
as is done here. But there's no reason to believe that the invoicer has
more knowledge about all but the last hop.
So, I'd recommend that the payer SHOULD prefer to use the final hops
specified in `r` fields over other equivalent routes it knows.
(Note the weasel word "equivalent" here: you might bias against these
due to fees, timeouts, or even privacy concerns. Also note that I
haven't implemented this yet!).
Cheers,
Rusty.
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
> 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.
There were originally two proposed uses of r=:
1. For payments via unannounced channels.
2. For routing hints for nodes which don't have a complete topology.
> 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?
Note that r can provide zero-or-more full routes, not just a single hop
as is done here. But there's no reason to believe that the invoicer has
more knowledge about all but the last hop.
So, I'd recommend that the payer SHOULD prefer to use the final hops
specified in `r` fields over other equivalent routes it knows.
(Note the weasel word "equivalent" here: you might bias against these
due to fees, timeouts, or even privacy concerns. Also note that I
haven't implemented this yet!).
Cheers,
Rusty.