📅 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.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:51:33
in reply to nevent1q…y6de
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:51:33Event JSON
{
"id": "5b4a04d932ec32ffcfa6f428dde6f8829abc23f0b155731f001cf618ba31ba96",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315093,
"kind": 1,
"tags": [
[
"e",
"34f972ce1f660f3d3f1ba8a09ccfbd7c4d82ba2dba504bf244e97255e67fae9d",
"",
"root"
],
[
"e",
"ae9458eb7e30e84041835986b42f302adad8a195bf472a50125d07ecbbf5f04a",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2018-10-08\n📝 Original message:\nMatt Corallo \u003clf-lists at mattcorallo.com\u003e writes:\n\u003e On a related note, it would be nice to get some clarity on appropriate\n\u003e usage of the r= field here.\n\u003e The way I had implemented it initially was that if an invoice had an r=\n\u003e field any publicly-discovered last-hop routes would be ignored as the r=\n\u003e data is most likely more up-to-date than any public route rumor information.\n\n\u003e However, if it's only used as a hint and only one or two out of\n\u003e potentially many channels are included in it, that may make little sense.\n\nThere were originally two proposed uses of r=:\n\n1. For payments via unannounced channels.\n2. For routing hints for nodes which don't have a complete topology.\n\n\u003e Not really sure what the appropriate guidance should be, probably\n\u003e something like SHOULD prefer to use invoice-r=-provided-hints over\n\u003e publicly-discovered routes however MAY use other last-hops in case a\n\u003e substantially better route is known?\n\nNote that r can provide zero-or-more full routes, not just a single hop\nas is done here. But there's no reason to believe that the invoicer has\nmore knowledge about all but the last hop.\n\nSo, I'd recommend that the payer SHOULD prefer to use the final hops\nspecified in `r` fields over other equivalent routes it knows.\n\n(Note the weasel word \"equivalent\" here: you might bias against these\ndue to fees, timeouts, or even privacy concerns. Also note that I\nhaven't implemented this yet!).\n\nCheers,\nRusty.",
"sig": "bc1efa7f3ed909e8aa08d2a0194338046dba23f4be01f2e8a17845f34f4c1dda7b269fb70e2cd097b523fe1709f25a00eb3a9af6cc8170d028c4682dcc2f74d7"
}