Ok, since you seem to imply each question is valuable, here's mine: how does Alice know RT2 has a route to Bob? If she knows that, can she also know T1 has a route to Bob? In any case, why can't she just build her small onion with Alice -> T1 -> Bob? I would expect that to be the most common case, am I right?
On Friday, August 2, 2019, Bastien TEINTURIER <bast...@acinq.fr> wrote: > Good morning list, > > I realized that trampoline routing has only been briefly described to this > list (credits to cdecker and pm47 for laying > out the foundations). I just published an updated PR [1] and want to take > this opportunity to present the high level > view here and the parts that need a concept ACK and more feedback. > > Trampoline routing is conceptually quite simple. Alice wants to send a > payment to Bob, but she doesn't know a > route to get there because Alice only keeps a small area of the routing > table locally (Alice has a crappy phone, > damn it Alice sell some satoshis and buy a real phone). However, Alice has > a few trampoline nodes in her > friends-of-friends and knows some trampoline nodes outside of her local > area (but she doesn't know how to reach > them). Alice would like to send a payment to a trampoline node she can > reach and defer calculation of the rest of > the route to that node. > > The onion routing part is very simple now that we have variable-length > onion payloads (thanks again cdecker!). > Just like russian dolls, we simply put a small onion inside a big onion. > And the HTLC management forwards very > naturally. > > It's always simpler with an example. Let's imagine that Alice can reach > three trampoline nodes: T1, T2 and T3. > She also knows the details of many remote trampoline nodes that she cannot > reach: RT1, RT2, RT3 and RT4. > Alice selects T1 and RT2 to use as trampoline hops. She builds a small > onion that describes the following route: > > *Alice -> T1 -> RT2 -> Bob* > > She finds a route to T1 and builds a normal onion to send a payment to T1: > > *Alice -> N1 -> N2 -> T1* > > In the payload for T1, Alice puts the small trampoline onion. > When T1 receives the payment, he is able to peel one layer of the > trampoline onion and discover that he must > forward the payment to RT2. T1 finds a route to RT2 and builds a normal > onion to send a payment to RT2: > > *T1 -> N3 -> RT2* > > In the payload for RT2, T1 puts the peeled small trampoline onion. > When RT2 receives the payment, he is able to peel one layer of the > trampoline onion and discover that he must > forward the payment to Bob. RT2 finds a route to Bob and builds a normal > onion to send a payment: > > *RT2 -> N4 -> N5 -> Bob* > > In the payload for Bob, RT2 puts the peeled small trampoline onion. > When Bob receives the payment, he is able to peel the last layer of the > trampoline onion and discover that he is > the final recipient, and fulfills the payment. > > Alice has successfully sent a payment to Bob deferring route calculation > to some chosen trampoline nodes. > That part was simple and (hopefully) not controversial, but it left out > some important details: > > 1. How do trampoline nodes specify their fees and cltv requirements? > 2. How does Alice sync the fees and cltv requirements for her remote > trampoline nodes? > > To answer 1., trampoline nodes needs to estimate a fee and cltv that > allows them to route to (almost) any other > trampoline node. This is likely going to increase the fees paid by > end-users, but they can't eat their cake and > have it too: by not syncing the whole network, users are trading fees for > ease of use and payment reliability. > > To answer 2., we can re-use the existing gossip infrastructure to exchange > a new *node_update *message that > contains the trampoline fees and cltv. However Alice doesn't want to > receive every network update because she > doesn't have the bandwidth to support it (damn it again Alice, upgrade > your mobile plan). My suggestion is to > create a filter system (similiar to BIP37) where Alice sends gossip > filters to her peers, and peers only forward to > Alice updates that match these filters. This doesn't have the issues BIP37 > has for Bitcoin because it has a cost > for Alice: she has to open a channel (and thus lock funds) to get a > connection to a peer. Peers can refuse to serve > filters if they are too expensive to compute, but the filters I propose in > the PR are very cheap (a simple xor or a > node distance comparison). > > If you're interested in the technical details, head over to [1]. > I would really like to get feedback from this list on the concept itself, > and especially on the gossip and fee estimation > parts. If you made it that far, I'm sure you have many questions and > suggestions ;). > > Cheers, > Bastien > > [1] https://github.com/lightningnetwork/lightning-rfc/pull/654 >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
