{"type":"rich","version":"1.0","author_name":"npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","author_url":"https://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-08-09\n📝 Original message:\nGood morning fiatjaf,\n\n\nSent with ProtonMail Secure Email.\n\n‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\nOn Friday, August 9, 2019 10:35 AM, fiatjaf \u003cfiatjaf at alhur.es\u003e wrote:\n\n\u003e Ok, here's another question/probably-bad-idea: how feasible is it for these trampoline nodes to return the route they've calculated somehow to the original caller so it can cache the route and use it without trampolines the next time? I don't know if caching routes is a good way improve routing overall in larger networks, but it seems to be working well for BLW[1] currently and overall it does make sense: in day-to-day payments we tend to pay the same people and stores over and over, rarely paying someone else (but of course these rare cases are still very common to be ignored).\n\u003e\n\u003e Anyway, I don't enough even to ask the question, but I guess it's theoretically possible for some information to be returned along with the preimage in the payment route, right?\n\u003e\n\u003e There remains a question of if and why the trampoline nodes would be or not interested in cheating Alice, sending back a bad route that favors them, or not returning any route at all as that would undermine their profits as trampolines.\n\u003e\n\u003e [1]: https://lightning-wallet.com/what-does-olympus-server-do\n\nIt is doable, and potentially a good idea.\n\nAs to economic incentive: the route returned would pass through the node that provides the route, so there is still economic incentive to do so.\nIn addition, the trampoline node would not have to cache it itself; instead the original payer does the caching, so this is a mild reduction in resources shouldered by the trampoline node (it avoids having to choose between recalculating the route vs caching it in its own storage).\n\nIt is even doable to support multipart payment, by simply allowing multiple routes to be returned.\n\nThough we need to redesign the route serialization.\nCurrent route serialization contains exact amount to be sent, and cannot be reused if amount is changed.\n\nRegards,\nZmnSCPxj\n\n\n\n\u003e\n\u003e On Friday, August 2, 2019, Bastien TEINTURIER \u003cbastien at acinq.fr\u003e wrote:\n\u003e\n\u003e \u003e Good morning list,\n\u003e \u003e\n\u003e \u003e I realized that trampoline routing has only been briefly described to this list (credits to cdecker and pm47 for laying \n\u003e \u003e out the foundations). I just published an updated PR [1] and want to take this opportunity to present the high level\n\u003e \u003e view here and the parts that need a concept ACK and more feedback.\n\u003e \u003e\n\u003e \u003e Trampoline routing is conceptually quite simple. Alice wants to send a payment to Bob, but she doesn't know a\n\u003e \u003e route to get there because Alice only keeps a small area of the routing table locally (Alice has a crappy phone,\n\u003e \u003e damn it Alice sell some satoshis and buy a real phone). However, Alice has a few trampoline nodes in her \n\u003e \u003e friends-of-friends and knows some trampoline nodes outside of her local area (but she doesn't know how to reach\n\u003e \u003e them). Alice would like to send a payment to a trampoline node she can reach and defer calculation of the rest of\n\u003e \u003e the route to that node.\n\u003e \u003e\n\u003e \u003e The onion routing part is very simple now that we have variable-length onion payloads (thanks again cdecker!).\n\u003e \u003e Just like russian dolls, we simply put a small onion inside a big onion. And the HTLC management forwards very\n\u003e \u003e naturally.\n\u003e \u003e\n\u003e \u003e It's always simpler with an example. Let's imagine that Alice can reach three trampoline nodes: T1, T2 and T3.\n\u003e \u003e She also knows the details of many remote trampoline nodes that she cannot reach: RT1, RT2, RT3 and RT4.\n\u003e \u003e Alice selects T1 and RT2 to use as trampoline hops. She builds a small onion that describes the following route:\n\u003e \u003e\n\u003e \u003e Alice -\u003e T1 -\u003e RT2 -\u003e Bob\n\u003e \u003e\n\u003e \u003e She finds a route to T1 and builds a normal onion to send a payment to T1:\n\u003e \u003e\n\u003e \u003e Alice -\u003e N1 -\u003e N2 -\u003e T1\n\u003e \u003e\n\u003e \u003e In the payload for T1, Alice puts the small trampoline onion.\n\u003e \u003e When T1 receives the payment, he is able to peel one layer of the trampoline onion and discover that he must\n\u003e \u003e forward the payment to RT2. T1 finds a route to RT2 and builds a normal onion to send a payment to RT2:\n\u003e \u003e\n\u003e \u003e T1 -\u003e N3 -\u003e RT2\n\u003e \u003e\n\u003e \u003e In the payload for RT2, T1 puts the peeled small trampoline onion.\n\u003e \u003e When RT2 receives the payment, he is able to peel one layer of the trampoline onion and discover that he must\n\u003e \u003e forward the payment to Bob. RT2 finds a route to Bob and builds a normal onion to send a payment:\n\u003e \u003e\n\u003e \u003e RT2 -\u003e N4 -\u003e N5 -\u003e Bob\n\u003e \u003e\n\u003e \u003e In the payload for Bob, RT2 puts the peeled small trampoline onion.\n\u003e \u003e When Bob receives the payment, he is able to peel the last layer of the trampoline onion and discover that he is\n\u003e \u003e the final recipient, and fulfills the payment.\n\u003e \u003e\n\u003e \u003e Alice has successfully sent a payment to Bob deferring route calculation to some chosen trampoline nodes.\n\u003e \u003e That part was simple and (hopefully) not controversial, but it left out some important details:\n\u003e \u003e\n\u003e \u003e 1.  How do trampoline nodes specify their fees and cltv requirements?\n\u003e \u003e 2.  How does Alice sync the fees and cltv requirements for her remote trampoline nodes?\n\u003e \u003e\n\u003e \u003e To answer 1., trampoline nodes needs to estimate a fee and cltv that allows them to route to (almost) any other\n\u003e \u003e trampoline node. This is likely going to increase the fees paid by end-users, but they can't eat their cake and\n\u003e \u003e have it too: by not syncing the whole network, users are trading fees for ease of use and payment reliability.\n\u003e \u003e\n\u003e \u003e To answer 2., we can re-use the existing gossip infrastructure to exchange a new node_update message that\n\u003e \u003e contains the trampoline fees and cltv. However Alice doesn't want to receive every network update because she\n\u003e \u003e doesn't have the bandwidth to support it (damn it again Alice, upgrade your mobile plan). My suggestion is to\n\u003e \u003e create a filter system (similiar to BIP37) where Alice sends gossip filters to her peers, and peers only forward to\n\u003e \u003e Alice updates that match these filters. This doesn't have the issues BIP37 has for Bitcoin because it has a cost\n\u003e \u003e for Alice: she has to open a channel (and thus lock funds) to get a connection to a peer. Peers can refuse to serve\n\u003e \u003e filters if they are too expensive to compute, but the filters I propose in the PR are very cheap (a simple xor or a\n\u003e \u003e node distance comparison).\n\u003e \u003e\n\u003e \u003e If you're interested in the technical details, head over to [1].\n\u003e \u003e I would really like to get feedback from this list on the concept itself, and especially on the gossip and fee estimation\n\u003e \u003e parts. If you made it that far, I'm sure you have many questions and suggestions ;).\n\u003e \u003e\n\u003e \u003e Cheers,\n\u003e \u003e Bastien\n\u003e \u003e\n\u003e \u003e [1] https://github.com/lightningnetwork/lightning-rfc/pull/654"}