📅 Original date posted:2018-10-10
📝 Original message:
I agree the r-fields are useful to populate for public channels in many
situations, but care must be taken to not _always_ try them first without
accounting for potentially high fees on those channels.
- Johan
On Wed, Oct 10, 2018 at 5:46 AM Rusty Russell <rusty at blockstream.com> wrote:
> Pierre <pm+lists at acinq.fr> writes:
> >> But there's no reason to believe that the invoicer has more knowledge
> about all but the last hop.
> >
> > I disagree: there is a good chance that the receiver is a 24/7 running
> > merchant/website, with a full up-to-date view of the network, whereas
> > the payer is most likely a mobile wallet with less
> > accurate/partial/out of date information.
> >
> > At least this is what we are seeing on the current mainnet. Routing
> > table sync is hard on mobile clients, and I think that it makes sense
> > that receivers "help" senders, after all incentives are aligned.
>
> Good qualification; I agree. Certainly if the payer knows its
> information is less reliable it should prefer the provided route.
>
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181010/f522d3b5/attachment-0001.html>;
Johan Torås Halseth [ARCHIVE] /
npub1pp…hs2fw
2023-06-09 12:51:33
in reply to nevent1q…vzqd
Author Public Key
npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwPublished at
2023-06-09 12:51:33Event JSON
{
"id": "31238ee3c44b5a06803c20a980fad990fec55391595955ecbd53ff585d34fbd9",
"pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f",
"created_at": 1686315093,
"kind": 1,
"tags": [
[
"e",
"34f972ce1f660f3d3f1ba8a09ccfbd7c4d82ba2dba504bf244e97255e67fae9d",
"",
"root"
],
[
"e",
"ab0422ac697d7dfd6298a33ab61eb3b2374a9996b27507b873e3ef6c9dd1207f",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2018-10-10\n📝 Original message:\nI agree the r-fields are useful to populate for public channels in many\nsituations, but care must be taken to not _always_ try them first without\naccounting for potentially high fees on those channels.\n\n- Johan\nOn Wed, Oct 10, 2018 at 5:46 AM Rusty Russell \u003crusty at blockstream.com\u003e wrote:\n\n\u003e Pierre \u003cpm+lists at acinq.fr\u003e writes:\n\u003e \u003e\u003e But there's no reason to believe that the invoicer has more knowledge\n\u003e about all but the last hop.\n\u003e \u003e\n\u003e \u003e I disagree: there is a good chance that the receiver is a 24/7 running\n\u003e \u003e merchant/website, with a full up-to-date view of the network, whereas\n\u003e \u003e the payer is most likely a mobile wallet with less\n\u003e \u003e accurate/partial/out of date information.\n\u003e \u003e\n\u003e \u003e At least this is what we are seeing on the current mainnet. Routing\n\u003e \u003e table sync is hard on mobile clients, and I think that it makes sense\n\u003e \u003e that receivers \"help\" senders, after all incentives are aligned.\n\u003e\n\u003e Good qualification; I agree. Certainly if the payer knows its\n\u003e information is less reliable it should prefer the provided route.\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181010/f522d3b5/attachment-0001.html\u003e",
"sig": "3d741ff29db63fe6fb9f1ddebbb7ea5ea4cb78fb33ff3fbe1f9dfaf88c0a650eb7d78eacc2bfb9922096433a555f32119396ed6f5c98da637aa2424bd2a5c39d"
}