{"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-02\n📝 Original message:\nGood morning list,\n\nI realized that trampoline routing has only been briefly described to this\nlist (credits to cdecker and pm47 for laying\nout the foundations). I just published an updated PR [1] and want to take\nthis opportunity to present the high level\nview here and the parts that need a concept ACK and more feedback.\n\nTrampoline routing is conceptually quite simple. Alice wants to send a\npayment to Bob, but she doesn't know a\nroute to get there because Alice only keeps a small area of the routing\ntable locally (Alice has a crappy phone,\ndamn it Alice sell some satoshis and buy a real phone). However, Alice has\na few trampoline nodes in her\nfriends-of-friends and knows some trampoline nodes outside of her local\narea (but she doesn't know how to reach\nthem). Alice would like to send a payment to a trampoline node she can\nreach and defer calculation of the rest of\nthe route to that node.\n\nThe onion routing part is very simple now that we have variable-length\nonion payloads (thanks again cdecker!).\nJust like russian dolls, we simply put a small onion inside a big onion.\nAnd the HTLC management forwards very\nnaturally.\n\nIt's always simpler with an example. Let's imagine that Alice can reach\nthree trampoline nodes: T1, T2 and T3.\nShe also knows the details of many remote trampoline nodes that she cannot\nreach: RT1, RT2, RT3 and RT4.\nAlice selects T1 and RT2 to use as trampoline hops. She builds a small\nonion that describes the following route:\n\n*Alice -\u003e T1 -\u003e RT2 -\u003e Bob*\n\nShe finds a route to T1 and builds a normal onion to send a payment to T1:\n\n*Alice -\u003e N1 -\u003e N2 -\u003e T1*\n\nIn the payload for T1, Alice puts the small trampoline onion.\nWhen T1 receives the payment, he is able to peel one layer of the\ntrampoline onion and discover that he must\nforward the payment to RT2. T1 finds a route to RT2 and builds a normal\nonion to send a payment to RT2:\n\n*T1 -\u003e N3 -\u003e RT2*\n\nIn the payload for RT2, T1 puts the peeled small trampoline onion.\nWhen RT2 receives the payment, he is able to peel one layer of the\ntrampoline onion and discover that he must\nforward the payment to Bob. RT2 finds a route to Bob and builds a normal\nonion to send a payment:\n\n*RT2 -\u003e N4 -\u003e N5 -\u003e Bob*\n\nIn the payload for Bob, RT2 puts the peeled small trampoline onion.\nWhen Bob receives the payment, he is able to peel the last layer of the\ntrampoline onion and discover that he is\nthe final recipient, and fulfills the payment.\n\nAlice has successfully sent a payment to Bob deferring route calculation to\nsome chosen trampoline nodes.\nThat part was simple and (hopefully) not controversial, but it left out\nsome important details:\n\n   1. How do trampoline nodes specify their fees and cltv requirements?\n   2. How does Alice sync the fees and cltv requirements for her remote\n   trampoline nodes?\n\nTo answer 1., trampoline nodes needs to estimate a fee and cltv that allows\nthem to route to (almost) any other\ntrampoline node. This is likely going to increase the fees paid by\nend-users, but they can't eat their cake and\nhave it too: by not syncing the whole network, users are trading fees for\nease of use and payment reliability.\n\nTo answer 2., we can re-use the existing gossip infrastructure to exchange\na new *node_update *message that\ncontains the trampoline fees and cltv. However Alice doesn't want to\nreceive every network update because she\ndoesn't have the bandwidth to support it (damn it again Alice, upgrade your\nmobile plan). My suggestion is to\ncreate a filter system (similiar to BIP37) where Alice sends gossip filters\nto her peers, and peers only forward to\nAlice updates that match these filters. This doesn't have the issues BIP37\nhas for Bitcoin because it has a cost\nfor Alice: she has to open a channel (and thus lock funds) to get a\nconnection to a peer. Peers can refuse to serve\nfilters if they are too expensive to compute, but the filters I propose in\nthe PR are very cheap (a simple xor or a\nnode distance comparison).\n\nIf you're interested in the technical details, head over to [1].\nI would really like to get feedback from this list on the concept itself,\nand especially on the gossip and fee estimation\nparts. If you made it that far, I'm sure you have many questions and\nsuggestions ;).\n\nCheers,\nBastien\n\n[1] https://github.com/lightningnetwork/lightning-rfc/pull/654\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190802/c9e8fa12/attachment.html\u003e"}