Trampoline onion format (Feature 56/57) #836
Conversation
rustyrussell
changed the title
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?
This commit adds the error messages that a trampoline node can return to a client according to the trampoline onoion format proposal lightning/bolts#836 Signed-off-by: Peter Neuroth <[email protected]>
We don't actually need to use MPP between trampoline nodes: a single part payment could work. We're thus removing the requirement to always provide the MPP field in the outer onion. Always using MPP (even for single-part payments) simplified our eclair implementation, but other implementations may work differently, so it shouldn't impact the spec.
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.
When a trampoline node inside a trampoline blinded path wants to fail an incoming payment, it must use `update_fail_malformed_htlc` to avoid leaking blinded path information. The introduction node will translate that into a real `temporary_trampoline_failure` that it then encrypts to the payer. We add a test vector that showcases this behavior.
| - MUST include `amt_to_forward`, `outgoing_cltv_value` and `total_amount_msat`. | ||
| - MUST NOT include any other field. | ||
| - MAY prepend additional trampoline nodes where the trampoline onion payload: | ||
| - MUST include `amt_to_forward` and `outgoing_cltv_value`. |
There was a problem hiding this comment.
Should behaviors be explicitly specified for the scenario where a receiving node's amt_to_forward inside the Trampoline onion is greater/less than in its outer onion? And similar discrepancies for the CLTV value?
There was a problem hiding this comment.
What do you mean? We're already stating that we must process the contents of the trampoline packet as a normal onion, and thus apply the same requirements. Can you be more precise and suggest specific changes to add to the spec?
There was a problem hiding this comment.
Sure, perhaps I'm missing the change, but do we explicitly specify the error code to be returned in this scenario, because trampoline_fee_or_expiry_insufficient's description only seems to refer to the forwarding scenario.
There was a problem hiding this comment.
Also, absent a total_msat in the outer onion, presumably the comparison in the following line should be made against the amt_to_forward value?
There was a problem hiding this comment.
Also, absent a total_msat in the outer onion, presumably the comparison in the following line should be made against the amt_to_forward value?
Good catch, now that we allow omitting the payment_data TLV, we must explicitly handle the case where it's absent, done in b4aec54
Sure, perhaps I'm missing the change, but do we explicitly specify the error code to be returned in this scenario, because trampoline_fee_or_expiry_insufficient's description only seems to refer to the forwarding scenario.
Since this is a final recipient error, in eclair we do the same thing as what we'd do in the similar case for a non-trampoline recipient:
- if the expiry is incorrect, we return
final_incorrect_cltv_expiry - if the amount is incorrect, we return
final_incorrect_htlc_amount
Do you want me to explicitly link those two error codes in the receiver requirements you added? Or is there a potential reason for implementations to use a different error code?
[Trampoline routing](lightning/bolts#836) allows nodes to send payments with limited access to the network graph, by relying on trampoline nodes to compute the missing parts of the route. The BOLTs only specify how such payments can be made to recipients who either support the trampoline feature or use Bolt12 with a blinded path. This leaves a gap when paying legacy nodes that don't support any of those features. This bLIP provides a mechanism to pay such legacy invoices, by revealing some of the invoice data to the last trampoline node, who converts the trampoline payment to a standard payment.
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.
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.
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.
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.
| - MUST use `current_path_key` from the trampoline onion or the outer onion to decrypt it. | ||
| - MUST validate its content as it would for the non-trampoline case. | ||
| - MUST include the next `current_path_key` in the `hop_payload` for the next trampoline node. | ||
| - MUST compute a route to the next trampoline node. |
There was a problem hiding this comment.
Are there any thoughts on how to protect against DoS here? Also wondering what the most effective way would be for an attacker to overload trampoline nodes. I suppose a max length route sending the htlc in circles with each hop needing to search for a hard to find path would be a component of it.
It seems to be a channel jamming like problem because there's again no info on sender or receiver to filter out / limit trampoline activitiy.
There was a problem hiding this comment.
It's up to the implementation/node operator to decide what to do here. In practice, trampoline will mostly be used by LSPs and routes will only be computed for mobile wallets that have paid fees to the LSP when getting a channel and liquidity, which is a form of DoS protection. But we'll probably need better heuristics to protect against resource exhaustion indeed!
There was a problem hiding this comment.
I am wondering what happens if a node doesn't filter for its own clients and just offers trampoline routing to anyone. Would it be advisable at all to enable this, or is this asking for trouble without having the heuristics in place too?
I wouldn't even know how to do these heuristics.
There was a problem hiding this comment.
I think that it shouldn't be too hard: you can benchmark how much path-finding you can do in parallel without exhausting your machine's resources, and then rate-limit the number of pending trampoline requests you receive based on that value? That obviously wouldn't be a fair rate-limiting, but it ensures that you don't end up being DoS-ed while still serving some requests, which is probably good enough for such public trampoline nodes?
There was a problem hiding this comment.
I'd imagine that it is easy for an attacker to just drown out the real requests completely.
There was a problem hiding this comment.
Probably, but it's easy to ensure they only DoS the requests that don't come from your customers: if you are a wallet provider, you would use separate queues for requests coming from your wallet users and public ones. And at some point when we start using upfront fees, maintaining this attack will have a cost for the attacker!
|
|
||
| The trampoline onion specified an `outgoing_node_id` that cannot be reached | ||
| from the processing node. | ||
|
|
There was a problem hiding this comment.
Perhaps this is obvious to others, but I think it would be helpful to add some trampoline-specific wording to the requirements section below for handling blinded failures, specifically: if current_path_key is set in the onion payload and it is not the final node
The trampoline is the final node in the top level onion path, but not actually the final node, so it can be a little ambiguous as it's currently written?
There was a problem hiding this comment.
This one was a bit tricky: I think I've improved it by renaming this "payment recipient" in 9938ab3 and removing the redundant "final node" in the "forwarding node" section, but if that's still confusing, let me know what I can change to make it better!
There is no identified scenario where intermediate trampoline nodes use a blinded path to reach the next trampoline node, since they know the identity of that next node. We thus disallow this case by specifying that the `current_path_key` can only be set in either the outer onion or the trampoline onion (for the introduction node).
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.
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.
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.