Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-08 📝 Original message: Resending due to ML ...

📅 Original date posted:2018-10-08
📝 Original message:
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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>