{"type":"rich","version":"1.0","author_name":"npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","author_url":"https://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-08-05\n📝 Original message:\nGood morning fiatjaf,\n\nThis is a good question, I'm glad you asked.\n\nAs ZmnSCPxj points out, Alice doesn't know. By not syncing the full network\ngraph, Alice has to accept\n\"being in the dark\" for some decisions. She is merely hoping that RT2 *can\nfind a route* to Bob. Note that\nit's quite easy to help Alice make informed decision by proving routing\nhints in the invoice and in gossip\nmessages (which we already do for \"normal\" routing).\n\nThe graph today is strongly connected, so it's quite a reasonable\nassumption (and Alice can easily retry\nwith another choice of trampoline node if the first one fails - just like\nwe do today with normal payments).\n\nI fully agree with ZmnSCPxj though that in the future this might not be\ntrue anymore. When/if the network\nbecomes too large we will likely lose its strongly connected nature. When\nthat happens, the Lightning\nNetwork will need some kind of hierarchical / packet switched routing\narchitecture and we won't require\ntrampoline nodes to know the whole network graph and be able to route to\nmostly anyone.\nI argue that trampoline routing is a first step towards enabling that. It's\na good engineering trade-off between\nease of implementation and deployment, fixing a problem we have today and\nenabling future scaling for\nproblems we'll have tomorrow. It's somewhat easy once we have trampoline\npayments to evolve that to a\nsystem closer to the internet's packet switching infrastructure, so we'll\ndeal with that once the need for it\nbecomes obvious.\n\nDoes that answer your question?\n\nCheers,\nBastien\n\nLe sam. 3 août 2019 à 05:48, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e a écrit :\n\n\u003e Good morning fiatjaf,\n\u003e\n\u003e I proposed before that we could institute a rule where nodes are mapped to\n\u003e some virtual space, and nodes should preferably retain the part of the\n\u003e network graph that connects itself to those nodes near to it in this\n\u003e virtual space (and possibly prefer to channel to those nodes).\n\u003e\n\u003e\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001959.html\n\u003e\n\u003e Thus Alice might **not** know that some route exists between T1 and T2.\n\u003e\n\u003e T1 itself might not know of a route from itself to T2.\n\u003e But if T1 knows a route to T1.5, and it knows that T1.5 is nearer to T2\n\u003e than to itself in the virtual space, it can **try** to route through T1.5\n\u003e in the hope T1.5 knows a route from itself to T2.\n\u003e This can be done if T1 can remove itself from the trampoline route and\n\u003e replace itself with T1.5, offerring in exchange some of the fee to T1.5.\n\u003e\n\u003e Other ways of knowing some distillation of the public network without\n\u003e remembering the channel level details are also possible.\n\u003e My recent pointlessly long spam email for example has a section on\n\u003e Hierarchical Maps.\n\u003e\n\u003e\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-August/002095.html\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e Sent with ProtonMail Secure Email.\n\u003e\n\u003e ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\n\u003e On Saturday, August 3, 2019 12:29 AM, fiatjaf \u003cfiatjaf at alhur.es\u003e wrote:\n\u003e\n\u003e \u003e Ok, since you seem to imply each question is valuable, here's mine: how\n\u003e does Alice know RT2 has a route to Bob? If she knows that, can she also\n\u003e know T1 has a route to Bob? In any case, why can't she just build her small\n\u003e onion with Alice -\u003e T1 -\u003e Bob? I would expect that to be the most common\n\u003e case, am I right?\n\u003e \u003e\n\u003e \u003e On Friday, August 2, 2019, Bastien TEINTURIER \u003cbastien at acinq.fr\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e Good morning list,\n\u003e \u003e \u003e\n\u003e \u003e \u003e I realized that trampoline routing has only been briefly described to\n\u003e this list (credits to cdecker and pm47 for laying\n\u003e \u003e \u003e out the foundations). I just published an updated PR [1] and want to\n\u003e take this opportunity to present the high level\n\u003e \u003e \u003e view here and the parts that need a concept ACK and more feedback.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Trampoline routing is conceptually quite simple. Alice wants to send a\n\u003e payment to Bob, but she doesn't know a\n\u003e \u003e \u003e route to get there because Alice only keeps a small area of the\n\u003e routing table locally (Alice has a crappy phone,\n\u003e \u003e \u003e damn it Alice sell some satoshis and buy a real phone). However, Alice\n\u003e has a few trampoline nodes in her\n\u003e \u003e \u003e friends-of-friends and knows some trampoline nodes outside of her\n\u003e local area (but she doesn't know how to reach\n\u003e \u003e \u003e them). Alice would like to send a payment to a trampoline node she can\n\u003e reach and defer calculation of the rest of\n\u003e \u003e \u003e the route to that node.\n\u003e \u003e \u003e\n\u003e \u003e \u003e The onion routing part is very simple now that we have variable-length\n\u003e onion payloads (thanks again cdecker!).\n\u003e \u003e \u003e Just like russian dolls, we simply put a small onion inside a big\n\u003e onion. And the HTLC management forwards very\n\u003e \u003e \u003e naturally.\n\u003e \u003e \u003e\n\u003e \u003e \u003e It's always simpler with an example. Let's imagine that Alice can\n\u003e reach three trampoline nodes: T1, T2 and T3.\n\u003e \u003e \u003e She also knows the details of many remote trampoline nodes that she\n\u003e cannot reach: RT1, RT2, RT3 and RT4.\n\u003e \u003e \u003e Alice selects T1 and RT2 to use as trampoline hops. She builds a small\n\u003e onion that describes the following route:\n\u003e \u003e \u003e\n\u003e \u003e \u003e Alice -\u003e T1 -\u003e RT2 -\u003e Bob\n\u003e \u003e \u003e\n\u003e \u003e \u003e She finds a route to T1 and builds a normal onion to send a payment to\n\u003e T1:\n\u003e \u003e \u003e\n\u003e \u003e \u003e Alice -\u003e N1 -\u003e N2 -\u003e T1\n\u003e \u003e \u003e\n\u003e \u003e \u003e In the payload for T1, Alice puts the small trampoline onion.\n\u003e \u003e \u003e When T1 receives the payment, he is able to peel one layer of the\n\u003e trampoline onion and discover that he must\n\u003e \u003e \u003e forward the payment to RT2. T1 finds a route to RT2 and builds a\n\u003e normal onion to send a payment to RT2:\n\u003e \u003e \u003e\n\u003e \u003e \u003e T1 -\u003e N3 -\u003e RT2\n\u003e \u003e \u003e\n\u003e \u003e \u003e In the payload for RT2, T1 puts the peeled small trampoline onion.\n\u003e \u003e \u003e When RT2 receives the payment, he is able to peel one layer of the\n\u003e trampoline onion and discover that he must\n\u003e \u003e \u003e forward the payment to Bob. RT2 finds a route to Bob and builds a\n\u003e normal onion to send a payment:\n\u003e \u003e \u003e\n\u003e \u003e \u003e RT2 -\u003e N4 -\u003e N5 -\u003e Bob\n\u003e \u003e \u003e\n\u003e \u003e \u003e In the payload for Bob, RT2 puts the peeled small trampoline onion.\n\u003e \u003e \u003e When Bob receives the payment, he is able to peel the last layer of\n\u003e the trampoline onion and discover that he is\n\u003e \u003e \u003e the final recipient, and fulfills the payment.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Alice has successfully sent a payment to Bob deferring route\n\u003e calculation to some chosen trampoline nodes.\n\u003e \u003e \u003e That part was simple and (hopefully) not controversial, but it left\n\u003e out some important details:\n\u003e \u003e \u003e\n\u003e \u003e \u003e 1.  How do trampoline nodes specify their fees and cltv requirements?\n\u003e \u003e \u003e 2.  How does Alice sync the fees and cltv requirements for her remote\n\u003e trampoline nodes?\n\u003e \u003e \u003e\n\u003e \u003e \u003e To answer 1., trampoline nodes needs to estimate a fee and cltv that\n\u003e allows them to route to (almost) any other\n\u003e \u003e \u003e trampoline node. This is likely going to increase the fees paid by\n\u003e end-users, but they can't eat their cake and\n\u003e \u003e \u003e have it too: by not syncing the whole network, users are trading fees\n\u003e for ease of use and payment reliability.\n\u003e \u003e \u003e\n\u003e \u003e \u003e To answer 2., we can re-use the existing gossip infrastructure to\n\u003e exchange a new node_update message that\n\u003e \u003e \u003e contains the trampoline fees and cltv. However Alice doesn't want to\n\u003e receive every network update because she\n\u003e \u003e \u003e doesn't have the bandwidth to support it (damn it again Alice, upgrade\n\u003e your mobile plan). My suggestion is to\n\u003e \u003e \u003e create a filter system (similiar to BIP37) where Alice sends gossip\n\u003e filters to her peers, and peers only forward to\n\u003e \u003e \u003e Alice updates that match these filters. This doesn't have the issues\n\u003e BIP37 has for Bitcoin because it has a cost\n\u003e \u003e \u003e for Alice: she has to open a channel (and thus lock funds) to get a\n\u003e connection to a peer. Peers can refuse to serve\n\u003e \u003e \u003e filters if they are too expensive to compute, but the filters I\n\u003e propose in the PR are very cheap (a simple xor or a\n\u003e \u003e \u003e node distance comparison).\n\u003e \u003e \u003e\n\u003e \u003e \u003e If you're interested in the technical details, head over to [1].\n\u003e \u003e \u003e I would really like to get feedback from this list on the concept\n\u003e itself, and especially on the gossip and fee estimation\n\u003e \u003e \u003e parts. If you made it that far, I'm sure you have many questions and\n\u003e suggestions ;).\n\u003e \u003e \u003e\n\u003e \u003e \u003e Cheers,\n\u003e \u003e \u003e Bastien\n\u003e \u003e \u003e\n\u003e \u003e \u003e [1] https://github.com/lightningnetwork/lightning-rfc/pull/654\n\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190805/b9f66da2/attachment.html\u003e"}