Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-05 📝 Original message: Hi t-bast, > She creates ...
📅 Original date posted:2019-11-05
📝 Original message:
Hi t-bast,
> She creates a Bolt 11 invoice containing that pre-encrypted onion.
This seem insufficient, as if the prescribed route that Alice selects fails,
then the sender has no further information to go off of (let's say Teddy is
offline, but there're other pats). cdecker's rendezvous sketch using Sphinx
you
linked above also suffers from the same issue: you need some other
bi-directional communication medium between the sender and receiver in
order to
account for payment failures. Beyond that, if any failures occur in the
latter
half of the route (the part that's opaque to the sender), then the sender
isn't
able to incorporate the failure information into their path finding. As a
result, the payer would need to send the error back to the receiver for
decrypting, possibly ping-ponging several times in a payment attempt.
On the other hand, using HORNET for rendezvous routing as was originally
intended gives the sender+receiver a communication channel they can use to
exchange further payment information, and also a channel to use for
decryption
of the opaque errors. Amongst many other things, it would also give us a
payment-level ACK [1], which may be a key component for payment splitting
(otherwise
you have no idea if _any_ shards have even arrived at the other side).
[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001524.html
-- Laolu
On Tue, Oct 22, 2019 at 5:02 AM Bastien TEINTURIER <bastien at acinq.fr> wrote:
> 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
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191105/3f9453a1/attachment.html>;
📝 Original message:
Hi t-bast,
> She creates a Bolt 11 invoice containing that pre-encrypted onion.
This seem insufficient, as if the prescribed route that Alice selects fails,
then the sender has no further information to go off of (let's say Teddy is
offline, but there're other pats). cdecker's rendezvous sketch using Sphinx
you
linked above also suffers from the same issue: you need some other
bi-directional communication medium between the sender and receiver in
order to
account for payment failures. Beyond that, if any failures occur in the
latter
half of the route (the part that's opaque to the sender), then the sender
isn't
able to incorporate the failure information into their path finding. As a
result, the payer would need to send the error back to the receiver for
decrypting, possibly ping-ponging several times in a payment attempt.
On the other hand, using HORNET for rendezvous routing as was originally
intended gives the sender+receiver a communication channel they can use to
exchange further payment information, and also a channel to use for
decryption
of the opaque errors. Amongst many other things, it would also give us a
payment-level ACK [1], which may be a key component for payment splitting
(otherwise
you have no idea if _any_ shards have even arrived at the other side).
[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001524.html
-- Laolu
On Tue, Oct 22, 2019 at 5:02 AM Bastien TEINTURIER <bastien at acinq.fr> wrote:
> 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
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191105/3f9453a1/attachment.html>;