Corné Plooy [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-25 📝 Original message: Cool: non-source ...
📅 Original date posted:2019-10-25
📝 Original message:
Cool: non-source rendez-vous routing. Getting closer to 2013 Amiko Pay,
with the added experience of 2019 Lightning with Sphinx routing and AMP.
https://cornwarecjp.github.io/amiko-pay/doc/amiko_draft_2.pdf
(esp. section 2.1.3)
Please forgive the use of the term "Ripple". 2013 was a different time.
CJP
On 22-10-19 14:01, Bastien TEINTURIER 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
📝 Original message:
Cool: non-source rendez-vous routing. Getting closer to 2013 Amiko Pay,
with the added experience of 2019 Lightning with Sphinx routing and AMP.
https://cornwarecjp.github.io/amiko-pay/doc/amiko_draft_2.pdf
(esp. section 2.1.3)
Please forgive the use of the term "Ripple". 2013 was a different time.
CJP
On 22-10-19 14:01, Bastien TEINTURIER 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