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
