Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2019-08-02 📝 Original message: Good morning list, I ...
📅 Original date posted:2019-08-02
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190802/c9e8fa12/attachment.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190802/c9e8fa12/attachment.html>;