Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-22 📝 Original message: Good morning everyone, ...
📅 Original date posted:2019-10-22
📝 Original message:
Good morning everyone,
Since I'm a one-trick pony, I'd like to talk to you about...guess what?
Trampoline!
If you watched my talk at LNConf2019, I mentioned at the end that
Trampoline enables high AMP very easily.
Every Trampoline node in the route may aggregate an incoming multi-part
payment and then decide on how
to split the outgoing aggregated payment. It looks like this:
.-------- 1mBTC --------. .------- 2mBTC -------.
/ \ /
\
Alice ----- 3mBTC ------> Ted ------ 4mBTC ----> Terry ----- 6mBTC ----> Bob
\ /
`------- 2mBTC ----------'
In this example, Alice only has small-ish channels to Ted so she has to
split in 3 parts. Ted has good outgoing
capacity to Terry so he's able to split in only two parts. And Terry has a
big channel to Bob so he doesn't need
to split at all.
This is interesting because each intermediate Trampoline node has knowledge
of his local channels balances,
thus can make more informed decisions than Alice on how to efficiently
split to reach the next node.
But it doesn't stop there. Trampoline also enables a better rendez-vous
routing than normal payments.
Christian has done most of the hard work to figure out how we could do
rendez-vous on top of Sphinx [1]
(thanks Christian!), so I won't detail that here (but I do plan on
submitting a detailed spec proposal with all
the crypto equations and nice diagrams someday, unless Christian does it
first).
One of the issues with rendez-vous routing is that once Alice (the
recipient) has created her part of the onion,
she needs to communicate that to Bob (the sender). If we use a Bolt 11
invoice for that, it means we need to
put 1366 additional bytes to the invoice (plus some additional information
for the ephemeral key switch).
If the amount Alice wants to receive is big and may require multi-part,
Alice has to decide upfront on how to split
and provide multiple pre-encrypted onions (so we need 1366 bytes *per
partial payment*, which kinda sucks).
But guess what? Bitcoin Trampoline fixes that*™*. Instead of doing the
pre-encryption on a normal onion, Alice
would do the pre-encryption on a Trampoline onion (which is much smaller,
in my prototype it's 466 bytes).
And that allows rendez-vous routing to benefit from Trampoline's ability to
do multi-part at each hop.
Obviously since the onion is smaller, that limits the number of trampoline
hops that can be used, but don't
forget that there are additional "normal" hops between each Trampoline node
(and the final Trampoline spec
can choose the size of the Trampoline onion to enable a good enough
rendez-vous).
Here is what it would look like. Alice chooses to rendez-vous at Terry.
Alice wants the payment to go through Terry
and Teddy so she pre-encrypts a Trampoline onion with that route:
Alice <--- Teddy <--- Terry
She creates a Bolt 11 invoice containing that pre-encrypted onion. Bob
picks up that invoice and can either reach
Terry directly (via a normal payment route) or via another Trampoline node
(Toad?). Bob finalizes the encryption of
the Trampoline onion and sends it onward. Bob can use multi-part and split
the payment however he wishes,
because every Trampoline node in the route will be free to aggregate and
re-split differently.
Terry is the only intermediate node to know that rendez-vous routing was
used. Terry doesn't learn anything about
Alice because the payment still needs to go through Teddy. Teddy only
learns that this is a Trampoline payment, so
he doesn't know his position in the Trampoline route (especially since he
doesn't know that rendez-vous was used).
I believe this makes rendez-vous routing reasonable to implement: the
trade-offs aren't as strong as in the normal
payment case. If I missed something (maybe other issues related to the
current rendez-vous proposal) please let me know.
Of course Trampoline itself also has trade-offs that in some cases may
impact privacy (e.g. when paying to legacy nodes
that don't understand the Trampoline onion). This is why Eclair is
currently implementing it to identify all the places where
it falls short, so that we can then leverage the community's amazing brain
power to converge on a spec that everyone is
happy with and that minimizes the trade-offs we need to make. Stay tuned
for more information and updates to the spec PR
once we make progress on our Trampoline experiments.
Thank you for reading this, don't hesitate to throw ideas and/or criticize
this proposal.
Note that all the cryptographic details are left as an exercise to the
reader.
Bastien
[1]
https://github.com/lightningnetwork/lightning-rfc/wiki/Rendez-vous-mechanism-on-top-of-Sphinx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191022/9d0f01f4/attachment.html>;
📝 Original message:
Good morning everyone,
Since I'm a one-trick pony, I'd like to talk to you about...guess what?
Trampoline!
If you watched my talk at LNConf2019, I mentioned at the end that
Trampoline enables high AMP very easily.
Every Trampoline node in the route may aggregate an incoming multi-part
payment and then decide on how
to split the outgoing aggregated payment. It looks like this:
.-------- 1mBTC --------. .------- 2mBTC -------.
/ \ /
\
Alice ----- 3mBTC ------> Ted ------ 4mBTC ----> Terry ----- 6mBTC ----> Bob
\ /
`------- 2mBTC ----------'
In this example, Alice only has small-ish channels to Ted so she has to
split in 3 parts. Ted has good outgoing
capacity to Terry so he's able to split in only two parts. And Terry has a
big channel to Bob so he doesn't need
to split at all.
This is interesting because each intermediate Trampoline node has knowledge
of his local channels balances,
thus can make more informed decisions than Alice on how to efficiently
split to reach the next node.
But it doesn't stop there. Trampoline also enables a better rendez-vous
routing than normal payments.
Christian has done most of the hard work to figure out how we could do
rendez-vous on top of Sphinx [1]
(thanks Christian!), so I won't detail that here (but I do plan on
submitting a detailed spec proposal with all
the crypto equations and nice diagrams someday, unless Christian does it
first).
One of the issues with rendez-vous routing is that once Alice (the
recipient) has created her part of the onion,
she needs to communicate that to Bob (the sender). If we use a Bolt 11
invoice for that, it means we need to
put 1366 additional bytes to the invoice (plus some additional information
for the ephemeral key switch).
If the amount Alice wants to receive is big and may require multi-part,
Alice has to decide upfront on how to split
and provide multiple pre-encrypted onions (so we need 1366 bytes *per
partial payment*, which kinda sucks).
But guess what? Bitcoin Trampoline fixes that*™*. Instead of doing the
pre-encryption on a normal onion, Alice
would do the pre-encryption on a Trampoline onion (which is much smaller,
in my prototype it's 466 bytes).
And that allows rendez-vous routing to benefit from Trampoline's ability to
do multi-part at each hop.
Obviously since the onion is smaller, that limits the number of trampoline
hops that can be used, but don't
forget that there are additional "normal" hops between each Trampoline node
(and the final Trampoline spec
can choose the size of the Trampoline onion to enable a good enough
rendez-vous).
Here is what it would look like. Alice chooses to rendez-vous at Terry.
Alice wants the payment to go through Terry
and Teddy so she pre-encrypts a Trampoline onion with that route:
Alice <--- Teddy <--- Terry
She creates a Bolt 11 invoice containing that pre-encrypted onion. Bob
picks up that invoice and can either reach
Terry directly (via a normal payment route) or via another Trampoline node
(Toad?). Bob finalizes the encryption of
the Trampoline onion and sends it onward. Bob can use multi-part and split
the payment however he wishes,
because every Trampoline node in the route will be free to aggregate and
re-split differently.
Terry is the only intermediate node to know that rendez-vous routing was
used. Terry doesn't learn anything about
Alice because the payment still needs to go through Teddy. Teddy only
learns that this is a Trampoline payment, so
he doesn't know his position in the Trampoline route (especially since he
doesn't know that rendez-vous was used).
I believe this makes rendez-vous routing reasonable to implement: the
trade-offs aren't as strong as in the normal
payment case. If I missed something (maybe other issues related to the
current rendez-vous proposal) please let me know.
Of course Trampoline itself also has trade-offs that in some cases may
impact privacy (e.g. when paying to legacy nodes
that don't understand the Trampoline onion). This is why Eclair is
currently implementing it to identify all the places where
it falls short, so that we can then leverage the community's amazing brain
power to converge on a spec that everyone is
happy with and that minimizes the trade-offs we need to make. Stay tuned
for more information and updates to the spec PR
once we make progress on our Trampoline experiments.
Thank you for reading this, don't hesitate to throw ideas and/or criticize
this proposal.
Note that all the cryptographic details are left as an exercise to the
reader.
Bastien
[1]
https://github.com/lightningnetwork/lightning-rfc/wiki/Rendez-vous-mechanism-on-top-of-Sphinx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191022/9d0f01f4/attachment.html>;