Trampoline onion format (Feature 56/57) #836
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
21 tasks
This was referenced Feb 9, 2021
Closed
19 tasks
rustyrussell
changed the title
9 tasks
11 tasks
9 tasks
12 tasks
9 tasks
10 tasks
12 tasks
11 tasks
15 tasks
18 tasks
15 tasks
19 tasks
19 tasks
19 tasks
21 tasks
21 tasks
21 tasks
21 tasks
lightning-developer
suggested changes
Dec 8, 2021
There was a problem hiding this comment.
I believe the spec should make a recommendation for CLTV and fee budgets that senders of trampoline onions should use for each trampoline to reduce the usage of temporary_trampoline_failure.
Also it seems reasonable to just reply with a single fee_budget_msat instead of * [u32:fee_base_msat] and [u32:fee_proportional_millionths] as those fields seem not to make sense in the context of trampolines.
Trampolines could announce the fee_budget_msat and cltv_budget (in case you like the new name) that they believe to be sufficient in their node announcements?
19 tasks
21 tasks
18 tasks
t-bast
added a commit
to ACINQ/lightning-kmp
that referenced
this pull request
Sep 18, 2024
We update our trampoline payments to blinded paths to match the official specification from lightning/bolts#836. The blinded paths and recipient features are included in the trampoline onion, which potentially allows using multiple trampoline hops. That was already what we were doing with experimental TLVs, so we simply update the TLV values to match the spec values.
t-bast
added a commit
to ACINQ/lightning-kmp
that referenced
this pull request
Sep 18, 2024
We add the ability to pay recipients that support trampoline *and* blinded paths. We include the blinded path data in the trampoline payloads for each node inside the blinded path. This doesn't reveal unnecessary information to the trampoline node: this is specified in details in lightning/bolts#836.
t-bast
added a commit
to ACINQ/lightning-kmp
that referenced
this pull request
Oct 8, 2024
We previously supported having multiple channels with our peer, because we didn't yet support splicing. Now that we support splicing, we always have at most one active channel with our peer. This lets us simplify greatly the outgoing payment state machine: payments are always made with a single outgoing HTLC instead of potentially multiple HTLCs (MPP). We don't need any kind of path-finding: we simply need to check the balance of our active channel, if any. We may introduce support for connecting to multiple peers in the future. When that happens, we will still have a single active channel per peer, but we may allow splitting outgoing payments across our peers. We will need to re-work the outgoing payment state machine when this happens, but it is too early to support this now anyway. This refactoring makes it easier to create payment onion, by creating the trampoline onion *and* the outer onion in the same function call. This will make it simpler to migrate to the version of trampoline that is currently specified in lightning/bolts#836 where some fields will be included in the payment onion instead of the trampoline onion.
20 tasks
t-bast
added a commit
to ACINQ/lightning-kmp
that referenced
this pull request
Oct 16, 2024
We previously supported having multiple channels with our peer, because we didn't yet support splicing. Now that we support splicing, we always have at most one active channel with our peer. This lets us simplify greatly the outgoing payment state machine: payments are always made with a single outgoing HTLC instead of potentially multiple HTLCs (MPP). We don't need any kind of path-finding: we simply need to check the balance of our active channel, if any. We may introduce support for connecting to multiple peers in the future. When that happens, we will still have a single active channel per peer, but we may allow splitting outgoing payments across our peers. We will need to re-work the outgoing payment state machine when this happens, but it is too early to support this now anyway. This refactoring makes it easier to create payment onion, by creating the trampoline onion *and* the outer onion in the same function call. This will make it simpler to migrate to the version of trampoline that is currently specified in lightning/bolts#836 where some fields will be included in the payment onion instead of the trampoline onion.
t-bast
added a commit
to ACINQ/lightning-kmp
that referenced
this pull request
Oct 21, 2024
We previously supported having multiple channels with our peer, because we didn't yet support splicing. Now that we support splicing, we always have at most one active channel with our peer. This lets us simplify greatly the outgoing payment state machine: payments are always made with a single outgoing HTLC instead of potentially multiple HTLCs (MPP). We don't need any kind of path-finding: we simply need to check the balance of our active channel, if any. We may introduce support for connecting to multiple peers in the future. When that happens, we will still have a single active channel per peer, but we may allow splitting outgoing payments across our peers. We will need to re-work the outgoing payment state machine when this happens, but it is too early to support this now anyway. This refactoring makes it easier to create payment onion, by creating the trampoline onion *and* the outer onion in the same function call. This will make it simpler to migrate to the version of trampoline that is currently specified in lightning/bolts#836 where some fields will be included in the payment onion instead of the trampoline onion. Co-authored-by: Thomas HUET <[email protected]>
t-bast
added a commit
to ACINQ/lightning-kmp
that referenced
this pull request
Oct 22, 2024
We update the trampoline feature to match the official specification from lightning/bolts#836. We remove support for the previous version of trampoline, which means that when paying nodes that use the experimental version, we will use the trampoline-to-non-trampoline flow instead. Similarly, when older nodes pay updated nodes, they won't understand the new trampoline feature bit and will use the trampoline-to-non-trampoline flow. We update the trampoline-to-non-trampoline flow to remove the unused trampoline payload in the onion, which saves some space. Note that we don't want to officially specify this scenario, as it leaks some data about the recipient to the trampoline node. We rather wait for nodes to either support trampoline or blinded paths, which fixes this issue.
t-bast
added a commit
to ACINQ/lightning-kmp
that referenced
this pull request
Oct 22, 2024
We update our trampoline payments to blinded paths to match the official specification from lightning/bolts#836. The blinded paths and recipient features are included in the trampoline onion, which potentially allows using multiple trampoline hops. That was already what we were doing with experimental TLVs, so we simply update the TLV values to match the spec values.
t-bast
added a commit
to ACINQ/lightning-kmp
that referenced
this pull request
Oct 22, 2024
We add the ability to pay recipients that support trampoline *and* blinded paths. We include the blinded path data in the trampoline payloads for each node inside the blinded path. This doesn't reveal unnecessary information to the trampoline node: this is specified in details in lightning/bolts#836.
Trampoline routing uses layered onions to trustlessly and privately offload the calculation of parts of a payment route to remote trampoline nodes. A normal onion contains a smaller onion for the last hop of the route, and that smaller onion contains routing information about the next trampoline hop. Intermediate trampoline nodes "fill the gap" by finding a route to the next trampoline node, and sending it the peeled trampoline onion, until that reaches the final destination.
When paying a Bolt 12 invoice, the payer may use a trampoline node to relay that payment. If the recipient doesn't support trampoline, the payer simply includes some of the blinded paths in the onion payload for the trampoline node, who will relay to those blinded paths. The trampoline node doesn't learn anything about the final recipient, it only learns the blinded paths they use, which should protect their privacy (unless using empty blinded paths). If the recipient supports trampoline and the `invoice_request` contains the trampoline feature bit, the recipient may set it in its invoice. In that case, the sender can use every node in the blinded path as a trampoline node and include the encrypted blinded path data in the trampoline onion. This also provides the opportunity for the sender to include additional TLVs for the recipient.
t-bast
force-pushed
the
trampoline-onion
branch
from
b4405d8 to
fa0594a
Compare
t-bast
added a commit
to ACINQ/lightning-kmp
that referenced
this pull request
Oct 23, 2024
We update the trampoline feature to match the official specification from lightning/bolts#836. We remove support for the previous version of trampoline, which means that when paying nodes that use the experimental version, we will use the trampoline-to-non-trampoline flow instead. Similarly, when older nodes pay updated nodes, they won't understand the new trampoline feature bit and will use the trampoline-to-non-trampoline flow. We update the trampoline-to-non-trampoline flow to remove the unused trampoline payload in the onion, which saves some space. Note that we don't want to officially specify this scenario, as it leaks some data about the recipient to the trampoline node. We rather wait for nodes to either support trampoline or blinded paths, which fixes this issue.
t-bast
added a commit
to ACINQ/lightning-kmp
that referenced
this pull request
Oct 23, 2024
We update our trampoline payments to blinded paths to match the official specification from lightning/bolts#836. The blinded paths and recipient features are included in the trampoline onion, which potentially allows using multiple trampoline hops. That was already what we were doing with experimental TLVs, so we simply update the TLV values to match the spec values.
t-bast
added a commit
to ACINQ/lightning-kmp
that referenced
this pull request
Oct 23, 2024
We add the ability to pay recipients that support trampoline *and* blinded paths. We include the blinded path data in the trampoline payloads for each node inside the blinded path. This doesn't reveal unnecessary information to the trampoline node: this is specified in details in lightning/bolts#836.
|
@arik-so @JssDWt this PR has been updated to match the discussions of the lightning summit. It now fully supports Bolt 11 and Bolt 12, as described in https://github.com/t-bast/trampoline-blinded-paths. The test vectors should be really helpful to figure out where each piece of data goes. This is implemented in ACINQ/lightning-kmp#688 if you want to see some code (I need to update |
|
Incredible, thanks so much! |
19 tasks
t-bast
added a commit
to ACINQ/eclair
that referenced
this pull request
Nov 27, 2024
We add support for the official version of trampoline payments, as specified in lightning/bolts#836. We keep supporting trampoline payments that use the legacy protocol to allow a smooth transition. We hardcode the legacy feature bit 149 in a few places to make this work, which is a bit hacky but simple and should be removed 6 months after releasing the official version. We also keep supporting payments from trampoline wallets to nodes that don't support trampoline: this is bad from a privacy standpoint, but will be fixed when recipients start supporting Bolt 12.
t-bast
added a commit
to ACINQ/eclair
that referenced
this pull request
Nov 27, 2024
We add support for the official version of trampoline payments, as specified in lightning/bolts#836. We keep supporting trampoline payments that use the legacy protocol to allow a smooth transition. We hardcode the legacy feature bit 149 in a few places to make this work, which is a bit hacky but simple and should be removed 6 months after releasing the official version. We also keep supporting payments from trampoline wallets to nodes that don't support trampoline: this is bad from a privacy standpoint, but will be fixed when recipients start supporting Bolt 12.
t-bast
added a commit
to ACINQ/eclair
that referenced
this pull request
Nov 29, 2024
We add support for the official version of trampoline payments, as specified in lightning/bolts#836. We keep supporting trampoline payments that use the legacy protocol to allow a smooth transition. We hardcode the legacy feature bit 149 in a few places to make this work, which is a bit hacky but simple and should be removed 6 months after releasing the official version. We also keep supporting payments from trampoline wallets to nodes that don't support trampoline: this is bad from a privacy standpoint, but will be fixed when recipients start supporting Bolt 12.
t-bast
added a commit
to ACINQ/eclair
that referenced
this pull request
Dec 3, 2024
We add support for the official version of trampoline payments, as specified in lightning/bolts#836. We keep supporting trampoline payments that use the legacy protocol to allow a smooth transition. We hardcode the legacy feature bit 149 in a few places to make this work, which is a bit hacky but simple and should be removed 6 months after releasing the official version. We also keep supporting payments from trampoline wallets to nodes that don't support trampoline: this is bad from a privacy standpoint, but will be fixed when recipients start supporting Bolt 12.
t-bast
added a commit
to ACINQ/eclair
that referenced
this pull request
Dec 4, 2024
We add support for the official version of trampoline payments, as specified in lightning/bolts#836. We keep supporting trampoline payments that use the legacy protocol to allow a smooth transition. We hardcode the legacy feature bit 149 in a few places to make this work, which is a bit hacky but simple and should be removed 6 months after releasing the official version. We also keep supporting payments from trampoline wallets to nodes that don't support trampoline: this is bad from a privacy standpoint, but will be fixed when recipients start supporting Bolt 12.
t-bast
added a commit
to ACINQ/eclair
that referenced
this pull request
Dec 5, 2024
We add support for the official version of trampoline payments, as specified in lightning/bolts#836. We keep supporting trampoline payments that use the legacy protocol to allow a smooth transition. We hardcode the legacy feature bit 149 in a few places to make this work, which is a bit hacky but simple and should be removed 6 months after releasing the official version. We also keep supporting payments from trampoline wallets to nodes that don't support trampoline: this is bad from a privacy standpoint, but will be fixed when recipients start supporting Bolt 12.
t-bast
added a commit
to ACINQ/eclair
that referenced
this pull request
Dec 5, 2024
We add support for the official version of trampoline payments, as specified in lightning/bolts#836. We keep supporting trampoline payments that use the legacy protocol to allow a smooth transition. We hardcode the legacy feature bit 149 in a few places to make this work, which is a bit hacky but simple and should be removed 6 months after releasing the official version. We also keep supporting payments from trampoline wallets to nodes that don't support trampoline: this is bad from a privacy standpoint, but will be fixed when recipients start supporting Bolt 12.
t-bast
added a commit
to ACINQ/lightning-kmp
that referenced
this pull request
Dec 5, 2024
We update the trampoline feature to match the official specification from lightning/bolts#836. We remove support for the previous version of trampoline, which means that when paying nodes that use the experimental version, we will use the trampoline-to-non-trampoline flow instead. Similarly, when older nodes pay updated nodes, they won't understand the new trampoline feature bit and will use the trampoline-to-non-trampoline flow. We update the trampoline-to-non-trampoline flow to remove the unused trampoline payload in the onion, which saves some space. Note that we don't want to officially specify this scenario, as it leaks some data about the recipient to the trampoline node. We rather wait for nodes to either support trampoline or blinded paths, which fixes this issue.
t-bast
added a commit
to ACINQ/lightning-kmp
that referenced
this pull request
Dec 5, 2024
We update our trampoline payments to blinded paths to match the official specification from lightning/bolts#836. The blinded paths and recipient features are included in the trampoline onion, which potentially allows using multiple trampoline hops. That was already what we were doing with experimental TLVs, so we simply update the TLV values to match the spec values.
t-bast
added a commit
to ACINQ/lightning-kmp
that referenced
this pull request
Dec 5, 2024
We add the ability to pay recipients that support trampoline *and* blinded paths. We include the blinded path data in the trampoline payloads for each node inside the blinded path. This doesn't reveal unnecessary information to the trampoline node: this is specified in details in lightning/bolts#836.
Add a test vector detailing how trampoline failures are encrypted and decrypted until they reach the sender.
19 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Trampoline routing uses layered onions to trustlessly and privately offload the calculation of parts of a payment route to remote trampoline nodes.
A normal onion contains a smaller onion for the last hop of the route, and that smaller onion contains routing information about the next trampoline hop.
Intermediate trampoline nodes "fill the gap" by finding a route to the next trampoline node, and sending it the peeled trampoline onion, until that reaches the final destination.
This PR details the onion construction and requirements for supporting nodes. I advise readers to also have a look at #829 which gives a more high-level view of the different components, how they interact, and provides nice diagrams that help understand the low-level details.