Trampoline Routing (2021 edition) (Feature 56/57) #829

t-bast · 2020-12-28T16:15:25Z

This proposal allows nodes running on constrained devices to sync only a small portion of the network and leverage trampoline nodes to calculate the missing parts of the payment route while providing the same privacy as fully source-routed payments.

The main idea is to use layered onions: 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.

This PR provides a high-level view of trampoline routing, where concepts and designs are presented in a more user-friendly format than formal spec work. This document lets reviewers see the big picture and how all the pieces work together. It also contains pretty detailed examples that should give reviewers some intuition about the subtle low-level details.

Then reviewers can move on to #836 which contains the usual spec format for the onion construction: this is where we'll work on the nitty-gritty details.

This PR supercedes #654 based on what we learnt after 1 year running trampoline in production in Phoenix and many discussions with @ecdsa while Electrum worked on their own trampoline implementation. The important changes are:

the trampoline onion is now variable-size: it's much more flexible and has no privacy downside since it's not observable at the network layer (which is the reason why the outer onion is constant size)
trampoline doesn't need any new gossip mechanism and instead relies on the recipient doing a small amount of work to include trampoline hints in invoices that specify the fees and cltv_expiry_delta that must be used for the last trampoline hop
trampoline nodes may send back an error asking the payer to retry with a higher fee or cltv_expiry_delta: since senders need at most two trampoline hops to protect their privacy (and in some cases, only one trampoline hop), this retry-on-failure approach doesn't add too much latency in practice

saubyk · 2020-12-28T16:51:45Z

Hi @t-bast can you please link to proposals/trampoline.md? I am not able to locate it.

t-bast · 2020-12-28T16:56:22Z

Hi @t-bast can you please link to proposals/trampoline.md?

https://github.com/lightningnetwork/lightning-rfc/blob/trampoline-routing-no-gossip/proposals/trampoline.md is the best way to read it (with github's markdown viewer).

ecdsa · 2020-12-31T13:05:19Z

Regarding trampoline invoices: Do you suggest to create a new tagged field for trampoline_hints, or are we going to reuse the existing r tags, and to consider them as trampoline hints if the invoice has trampoline_routing_opt in its features?

fiatjaf · 2021-01-04T04:54:42Z

@ecdsa the proposed spec has a new tagged field t: https://github.com/lightningnetwork/lightning-rfc/blob/trampoline-routing-no-gossip/trampoline.md#invoice-trampoline-hints

t-bast · 2021-01-04T08:55:33Z

Yes, I think it's better to introduce a new one, tailored for trampoline.
But that is of course open to discussion if there's a better way.

cdecker · 2021-01-04T19:49:33Z

Very nice proposal, can't wait to see this in action. The onion
construction is mostly taken care of if you implement @rustyrussell's
offers proposal (which also uses the same construction and
parametrizes the size of the onion).

A rationale that I couldn't find, but I think Acinq are using this for
is the efficiency gain if the sender is on a slow / high latency
connection, each payment attempt requires a roundtrip to the sender
(in Eclair's case a mobile phone on a potentially flaky
connection). Outsourcing the path finding and retry logic to a better
connected node can result in far lower time-to-completion for the
payment, and the sender can save some bandwidth.

I just have the following points that I am still a bit unclear on:

There seem to be no limits in place for the inner onion, other than
that it's smaller. Specifically we have an issue with the inner x outer path length. If we generate an inner onion consisting of
nodes that are diametrically opposed in the network, we can end up
with a route that is many times larger than the implicit 20 hop
limit we have at the moment. The diameter of the network is
currently about 7, so an inner onion with 20 hops (using the outer
onion limit as a proxy here), could end up with 140 effective
routing hops, which also acts as a force-multiplier for an attacker
wanting to hold up as much liquidity in the network as possible.
Are trampoline hints intended to replace or augment the route
hints? In the former case we end up in a situation where the
destination must be known to at least one trampoline, in the latter
we may end up duplicating a lot of information in the
invoice. Further the duplication seems to be solely due to the fact
that route hints don't have a feature bitset.
- Should we just bump route hints to v2 and make them a TLV so we
  can add a feature bitset? It'd potentially save us some trouble
  in the future.
- Do we want to have trampoline hints at all? Isn't it in the
  sender's interest to not have them, and instead adding the
  existing route hints to the last trampoline's payload? That way
  we don't make the invoices larger for everyone, while still
  maintaining their functionality.

t-bast · 2021-01-08T11:44:12Z

There seem to be no limits in place for the inner onion, other than that it's smaller. (...) which also acts as a force-multiplier for an attacker wanting to hold up as much liquidity in the network as possible.

This is true. However, attackers have no control on what channels will be used to relay with trampoline, so this would be a blind attack against the whole network rather than targetting specific nodes (which is still concerning).
There has been some progress recently on proposals to fight spam, so we can hope that this issue will eventually be fixed.
But in the meantime, implementations can restrict the maximum size of the trampoline onion (we can add a recommended value in the spec) just like we restricted channel capacity at first.

Are trampoline hints intended to replace or augment the route hints?

I think we want to introduce a different, more flexible invoice routing hint.
It's probably a good opportunity, as you mention, to introduce the tlv format in these routing hints v2.
I know @rustyrussell mentioned it multiple times in the past, do you have some requirements / early designs for these new routing hints?

Let's explore the advantages and drawbacks of using the current routing hints (let me know if I'm missing important points there):

Advantages:
- Invoices don't get bigger than they are today
Drawbacks:
- It takes a lot of space in the trampoline onion
- It encourages single-trampoline payments, which is bad for privacy (trampoline node may know both sender and recipient)
- It offers a less flexible design space for recipient anonymity schemes

It's also important to note that to receive trampoline payments, the recipient still needs to upgrade his software to support trampoline onion decryption, so it's a good opportunity to implement a new routing hint format at the same time.

The advantages and drawbacks of using new routing hints are:

Advantages:
- Opportunity to add missing fields (features) and add future fields while staying backwards-compatible
- Opportunity to remove unused fields when unnecessary, resulting in smaller invoices
- No additional data needs to be transmitted in the trampoline onion
- Trampoline routes must use at least two trampolines, which is much better for privacy
- No channel information is leaked in invoices, which is better for privacy
- More flexible design space for recipient anonymity schemes
Drawbacks:
- Invoices get bigger if we want them to potentially be paid by "legacy" senders (but note that in some cases we could instead issue two invoices, a legacy one and a trampoline one, and that will eventually go away when everyone support the new format)

To exemplify the argument that the design space for recipient privacy would be bigger, I've been toying with the idea of short-lived tor-like circuits between mobile wallet recipients and trampoline nodes.
Imagine we have a graph like this, where Bob wants to be paid without revealing his identity to trampoline nodes and without revealing private channel information:

                            public              private
                      T1 ------------> Carol -------------+
                                                          |
                                                          v
                                                         Bob
                                                          ^
                                                          |
      public                public             private    |
T2 ------------> Mallory ------------> Dave --------------+

Obviously if Bob uses a mobile wallet with private channels, Carol and Dave know that he is the final recipient when forwarding payments to him (frequent IP address changes, offline most of the time, etc).
But Bob doesn't want his invoices to reveal that he's connected to Carol and Dave (e.g. to hide what lightning service provider he's using).
Bob could send anonymous onion messages to T1 and T2 to create short-lived circuits (for the duration of the invoice validity) to get them to route payments in the right direction, without revealing more than the next hop.
He then only needs to specify T1 and T2 in his routing hints, information about Carol, Dave or concrete channels is not needed.

Of course, this idea is very hand-wavy for now and has a lot of holes (and maybe route blinding works better and achieves the same results), so please don't poke at it too much yet, you will find issues, but that's not the point. I'm mentioning it because it shows how more flexible routing hints can provide a wider design space for recipients, which is important IMO.

ecdsa · 2021-01-08T14:27:58Z

The current proposal adds a single new failure message, trampoline_fee_expiry_insufficient. It does not specify any new failure message if a trampoline node fails to find a route to the next trampoline in a multi trampoline route.

The current Eclair implementation seems to return amount_below_minimum in all cases, regardless of the failure scenario. For example, if I create a route with two trampolines, and the second trampoline does not exist, I receive that failure message. It would be good to specify what message a trampoline node must return in that case (does it have to be amount_below_minimum?), and it might be useful to distinguish between "next trampoline is temporarily unreachable" and "next trampoline is unknown".

ecdsa · 2021-01-08T15:26:09Z

trampoline doesn't need any new gossip mechanism and instead relies on the recipient doing a small amount of work to include trampoline hints in invoices

The previous proposal had a node_update gossip message. That message is not equivalently replaced by the trampoline_hints in the invoice. If the sender decides to use an intermediate trampoline not in the invoice, they need to find out the fee/cltv parameters for that intermediate trampoline.

It is true that we may rely on trial-and-error and the trampoline_fee_expiry_insufficient message for that. However, I think that this induced an important change in the semantics of the fee and cltv fields in data:

in the previous proposal, the node_update message was used to publish fee and cltv values. By definition, these values used to be a function of time, but not of the payment sent to the trampoline.
in the new proposal, the fee and cltv parameters might depend on the payment. The proposal says: "The fee amount or cltv value was below that required by the trampoline node to forward to the next trampoline node." This seems to imply that the fee and cltv fields returned in data will be what the trampoline node would require for the current payment, but this does not guarantee success for a payment to another route.

I think the proposal should clarify whether the values returned in the error message are relative to the current payment, or independent of the payment. (note that I have a slight preference for fixed values. If these values depend on the payment, clients might have to do more trial-and-error in order to discover them, which might result in more htlcs flying around)

t-bast · 2021-01-08T16:53:51Z

The current Eclair implementation seems to return amount_below_minimum in all cases, regardless of the failure scenario

If it does that, it's a bug. It should only do that for small payments to phoenix wallets that don't have enough incoming liquidity (and thus need a new channel opened on-the-fly). For other cases it should return unknown_next_peer. It's definitely possible that this case isn't currently handled correctly since only single-trampoline has been implemented.

I think the errors returned should be the following:

I need more fees/cltv to relay: trampoline_fee_expiry_insufficient
There's no route in the graph to the next trampoline node: unknown_next_peer
There's a route in the graph to the next trampoline node, but I don't have enough balance: temporary_node_failure
There's a route in the graph to the next trampoline node, but it fails downstream: depending on the downstream failure, either directly relay that failure or replace it with a temporary_node_failure

Of course, trampoline nodes may also use other errors such as amount_below_minimum (or other Bolt 4 errors) in specific cases where that makes sense. Does that sound good?

The previous proposal had a node_update gossip message. That message is not equivalently replaced by the trampoline_hints in the invoice. If the sender decides to use an intermediate trampoline not in the invoice, they need to find out the fee/cltv parameters for that intermediate trampoline.

I decided to remove that mechanism because it wasn't working well: it's impossible to correctly estimate fees for all possible payments. It will force clients to overpay too often, or will still need a trial-and-error when you try to minimize the overpayment.

I'm now more in favour of the trial-and-error approach, where trampoline_fee_expiry_insufficient will return the fees/cltv that should will work for this specific payment. This guarantees that the retry should work if the trampoline correctly ran his path-finding algorithm, and used a small error buffer just in case (which minimizes sender-side retries). Some trampoline nodes may choose to return a value that would work for other payments as well (and maybe overpay this one), this is an implementation choice (and is a trade-off routing nodes should consciously choose to make or not). Clients may cache this value and use it for other payments as well, which may work (or may not, in which case the trial-and-error will let them correct this).

I think this approach is the most flexible one: we should leave some room for implementations to make different choices, to ensure we have a diverse network.

ecdsa · 2021-01-22T11:29:17Z

Yes, I think it's better to introduce a new one, tailored for trampoline. But that is of course open to discussion if there's a better way.

In practice, wallets will be compelled to include both trampoline_hints and routing_hints in their invoices, because they do not know if the sender understands trampoline. For an invoice with a reasonably sized description and a single routing hint, this results in a 10% size increase.

I guess the data in trampoline_hints will most of the time be redundant with what is in routing_hints (the payee is going to infer the trampoline fee/cltv from the routes it knows). Are there use cases where that would not be redundant?

t-bast · 2021-01-22T11:42:55Z

In practice, wallets will be compelled to include both trampoline_hints and routing_hints in their invoices, because they do not know if the sender understands trampoline.

Yes, that's true. And the transition period during which both will be required will likely last months (hopefully not years though as non-trampoline wallets will have an incentive to migrate to the new routing hints, even if they don't want to support trampoline).

I think these new routing hints will solve a few issues that the current routing hints have, so people would upgrade to use them regardless of trampoline, and once that's done the size overhead will be somewhat negligible.

Are there use cases where that would not be redundant?

They will be different for cases where current routing_hints include more than one hop, but in practice I don't think anyone is using this (yet).

cdecker · 2021-01-22T18:02:26Z

It seems to me like this proposal should be split into two: one that
introduces just the trampoline construction and forwarding logic, and
a second one that allows recipients to specify trampolines for
incoming payments. This is because in my eyes the latter is a new
requirement, that deviates from the original trampoline proposal, and
I'd like to unbundle the two.

It's also important to note that to receive trampoline payments, the
recipient still needs to upgrade his software to support trampoline
onion decryption, so it's a good opportunity to implement a new
routing hint format at the same time.

This looks like a new requirement to me, since the last trampoline
could be signaled to pay the final destination in non-trampoline mode,
thus not requiring the recipient to even understand the trampoline
protocol. It's the difference between "some node must support
trampolines" and "this specific recipient needs to support
trampolines". This is particularly important given that trampolines
are first and foremost a tool for the sender, and requiring the
recipient to play nice for the sender is an extra requirement.

I think we want to introduce a different, more flexible invoice
routing hint. It's probably a good opportunity, as you mention, to
introduce the tlv format in these routing hints v2. I know
@rustyrussell mentioned it multiple times in the past, do you have
some requirements / early designs for these new routing hints?

We can totally do that as well, however I think upgrading the
route-hints to be TLVs with all the mentioned improvements is
orthogonal to trampolines, hence my objection.

Bob could send anonymous onion messages to T1 and T2 to create
short-lived circuits (for the duration of the invoice validity) to get
them to route payments in the right direction, without revealing more
than the next hop. He then only needs to specify T1 and T2 in his
routing hints, information about Carol, Dave or concrete channels is
not needed.

Is this not orthogonal to the original trampoline proposal? I don't
see why we need to mix it in here, especially since with route
blinding there is already a competing proposal that achieves pretty
much the same.

If it does that, it's a bug. It should only do that for small payments
to phoenix wallets that don't have enough incoming liquidity (and thus
need a new channel opened on-the-fly). For other cases it should
return unknown_next_peer. It's definitely possible that this case
isn't currently handled correctly since only single-trampoline has
been implemented.

Reusing an existing error code seems wrong to me
here. unknown_next_peer implicitly assumes the sender knows what the
next peer should be, which in this case it doesn't. It's not like
we're running out of error number, so why not add a new
unknown_next_trampoline error?

Overall I think two smaller proposals with a single feature being
added are likely to make progress much quicker than bundling them
up. The larger the surface the more likely someone will object (in
this case that's me 😉)

t-bast · 2021-01-25T09:09:40Z

It seems to me like this proposal should be split into two: one that
introduces just the trampoline construction and forwarding logic, and
a second one that allows recipients to specify trampolines for
incoming payments.

Sounds good, I'll keep the current PR open and up-to-date for people who want
to see the whole thing, and will open a smaller PR in spec format for the
onion construction.

the last trampoline could be signaled to pay the final destination in non-trampoline mode,
thus not requiring the recipient to even understand the trampoline protocol

I don't see any satisfactory way of doing that...
All the solutions I tried involve giving that last trampoline invoice information
that force you to trust that this trampoline node will not cheat you, whereas it
could steal money (payment_secret for amountless invoices for example).

That's why I want to avoid having that scenario in the spec and prefer doing E2E
trampoline. For mobile wallets that can't fallback on normal payments when the
invoice doesn't have trampoline support, then a trusted solution where you give
parts of the invoice to a trampoline node may be implemented (that's what we do
in Phoenix), but I don't think it should be in the spec because it's unsatisfactory.

If you find a satisfying way of achieving that I'm interested, but I don't think
it's possible (it will sacrifice privacy and in some cases funds safety).

upgrading the route-hints to be TLVs with all the mentioned improvements is
orthogonal to trampolines

That's a reasonable objection, I'll make a separate PR.

Is this not orthogonal to the original trampoline proposal? I don't
see why we need to mix it in here, especially since with route
blinding there is already a competing proposal that achieves pretty
much the same.

I mentioned this simply as an example to show that it allows a larger design
space than we previously had. And because circuit-based approaches have had
more research put into them than route blinding, I would feel better having
the possibility of studying multiple approaches in case route blinding turns
out to be insufficient or not secure enough...

It's not like we're running out of error number, so why not add a new
unknown_next_trampoline error?

Sure, we can do that, it's more explicit that way.

ecdsa · 2021-01-25T11:14:02Z

It's not like we're running out of error number, so why not add a new unknown_next_trampoline error?

Like I said above, it would be useful to have distinct error numbers for unknown_next_trampoline and next_trampoline_unreachable (in case the trampoline fails to find a path, or fails to forward the payment).

In the first case, Trampoline A does not know about Trampoline B, and the sender should not ask TA to forward to TB again. In the second case, the sender will know that TA failed to forward a certain amount to TB, but it may be able to forward a different amount right now, or the same amount later.

Perhaps even more granularity is desirable. If TA fails to find a path to TB, it might return the "capacity" it believes it can send to TB in the error message.

t-bast · 2021-01-25T13:03:11Z

I integrated all these requirements in the trampoline onion PR, let's discuss it there: #836.

proposals/trampoline.md

arik-so · 2025-03-24T17:02:26Z

proposals/trampoline.md

+trampoline node, and adds a trampoline node in her own neighborhood at the
+beginning of the trampoline route. She includes the invoice's encrypted data
+for each node in their respective trampoline payload: this is very similarly
+to paying a blinded path without trampoline.


Just a point of double-checking following a discussion with @joostjager: blinded paths to a non-Trampoline node are meant to be the only mechanism to use Trampoline for payments to a legacy node, and the spec no longer supports legacy payment recipients without blinded paths?

Yes, because there is no good solution that doesn't sacrifice the payment privacy when paying Bolt 11 invoices that don't support trampoline, so I don't want to introduce it to the BOLTs. As discussed during the last spec meeting, I will document how this can be done in a bLIP however, which can be used while transitioning to trampoline and/or blinded paths.

f321x · 2025-10-08T16:19:55Z

proposals/trampoline.md

+        |                                           +---------------------------+   |                 |   HTLC(1480 msat, 600065 cltv)            | total_amount: 2500 msat     |   |
+        |                                           |             EOF           |   |                 |    +-----------------------+              | trampoline_onion:           |   |
+        |                                           +---------------------------+   |                 |    | amount_fwd: 1400 msat |              | +-------------------------+ |   |
+        |                                            HTLC(500 msat, 600112 cltv)    |                 |    | expiry: 600000        |              | | amount_fwd: 2500 msat   | |   |


You set amount_fwd == total_amount in the final trampoline onions for the receiver in this mpp ascii drawing. Is there any specific reason to do this?
I cannot find details about this in the conditions for final nodes in

bolts/04-onion-routing.md

Lines 547 to 553 in 9938ab3

- If it is the final node:

- MUST reject the payment if:

- The outer onion's `outgoing_cltv_value` is smaller than the trampoline onion's `outgoing_cltv_value`.

- If this is a multi-part payment:

- The outer onion's `total_msat` is smaller than the trampoline onion's `amt_to_forward`.

- Otherwise:

- The outer onion's `amt_to_forward` is smaller than the trampoline onion's `amt_to_forward`.

Is it fine to set the final trampoline_onions amount_fwd to the outer onions amount_fwd as well?

Is it fine to set the final trampoline_onions amount_fwd to the outer onions amount_fwd as well?

That would be fine whenever you use a single trampoline route, but that wouldn't work if you want to split a payment across multiple trampoline routes: that's where the trampoline onion's total_msat field is necessary.

For example, if you want to send 250 000 sats that you split into two trampoline routes:

sender -> T1 -> T2 -> recipient where you send 100 000 sats

sender -> T3 -> T4 -> recipient where you send 150 000 sats

The trampoline onion's total_msat would be 250 000 sats in both routes, whereas the outer onions will only believe they carry a 100 000 sats payment for the first route and a 150 000 sats payment for the second route.

Does that make sense?

I cannot find details about this in the conditions for final nodes in

I haven't duplicated every requirement because for most of the logic, the trampoline onion must be validated very similarly to the outer onion. I was hoping this case would be captured by:

- MUST process the `trampoline_onion_packet` as an `onion_packet`. - MUST fail the HTLC if dictated by the requirements under [Failure Messages](#failure-messages).

But if you think it's worth explicitly detailing this requirement, I can add that!

Consider e.g. this paragraph:

bolts/04-onion-routing.md

Lines 373 to 377 in 9938ab3

Note that `amt_to_forward` is the amount for this HTLC only: a

`total_msat` field containing a greater value is a promise by the

ultimate sender that the rest of the payment will follow in succeeding

HTLCs; we call these outstanding HTLCs which have the same preimage,

an "HTLC set".

What we mean by HTLC there becomes really fuzzy with this recursion.
When looking at the amt_to_forward inside the trampoline onion, first the final recipient needs to aggregate all the outer_onion level htlcs that have a matching payment_hash+outer_payment_secret. The htlc-value-sum of this set, should match the inner amt_to_forward.

Then a second-level of aggregation can be done: the sum of the inner amt_to_forwards matches the inner total_amount.

I guess the outer total_amount matching the inner amt_to_forward is invariant.

@t-bast's ascii drawings are magnificent, but we need to go even larger :D

HTLC(1500 msat, 600112 cltv) +---------------------------+ | amount_fwd: 1500 msat | | expiry: 600112 | HTLC(1560 msat, 600124 cltv) | payment_secret: aaaaa | +-----------------------+ | total_amount: 2800 msat | | amount_fwd: 1500 msat | | trampoline_onion: | HTLC1(1100 msat, 600000 cltv) | expiry: 600112 | | +-----------------------+ | +-----------------------------+ +--> | channel_id: 3 | ---> I1 ---> | | amount_fwd: 2500 msat | | --+ | amount_fwd: 1100 msat | | |-----------------------| | | expiry: 600000 | | | | expiry: 600000 | | | (encrypted) | | | node_id: Bob | | | | payment_secret: xxxxx | | +-----------------------+ | +-----------------------+ | | HTLC(1150 msat, 600080 cltv) | total_amount: 2500 msat | | | | (encrypted) | | | +-----------------------+ | trampoline_onion: | | | +-----------------------+ | | | amount_fwd: 1100 msat | | +-------------------------+ | | +---------------------------+ | | expiry: 600000 | | | amount_fwd: 2500 msat | | | | EOF | | +--> | channel_id: 561 | ---> I4 ---> | | expiry: 600000 | | --+ | +---------------------------+ | | |-----------------------| | | total_amount: 5200 msat | | | | HTLC(800 msat, 600112 cltv) | | | (encrypted) | | | payment_secret: yyyyy | | | | +---------------------------+ | | +-----------------------+ | +-------------------------+ | | | | amount_fwd: 800 msat | | | | | EOF | | | | | expiry: 600112 | | | | +-------------------------+ | | | HTLC(820 msat, 600130 cltv) | payment_secret: aaaaa | | | +-----------------------------+ | | +-----------------------+ | total_amount: 2800 msat | | | | EOF | | | | amount_fwd: 800 msat | | trampoline_onion: | | | +-----------------------------+ | | | expiry: 600112 | | +-----------------------+ | | | | +-------+--> | channel_id: 5 | ---> I2 ---> | | amount_fwd: 2500 msat | | --+----> T1 ------+ +----+ | | |-----------------------| | | expiry: 600000 | | | (fee 170 msat) | HTLC2(1400 msat, 600000 cltv) | | | | | (encrypted) | | | node_id: Bob | | | (delta 32) | +-----------------------------+ | | | | +-----------------------+ | +-----------------------+ | | | | amount_fwd: 1400 msat | | | | | | | (encrypted) | | | | | expiry: 600000 | | | | | | +-----------------------+ | | | | payment_secret: xxxxx | | | | | +---------------------------+ | | HTLC(1480 msat, 600065 cltv) | total_amount: 2500 msat | | | | | | EOF | | | +-----------------------+ | trampoline_onion: | | | | | +---------------------------+ | | | amount_fwd: 1400 msat | | +-------------------------+ | | | | | HTLC(500 msat, 600112 cltv) | | | expiry: 600000 | | | amount_fwd: 2500 msat | | | | | | +---------------------------+ | +--> | channel_id: 1105 | ---> I5 ---> | | expiry: 600000 | | --+ | | | | amount_fwd: 500 msat | | |-----------------------| | | total_amount: 5200 msat | | | | | | expiry: 600112 | | | (encrypted) | | | payment_secret: yyyyy | | | | | HTLC(510 msat, 600120 cltv) | payment_secret: aaaaa | | +-----------------------+ | +-------------------------+ | | | | +-----------------------+ | total_amount: 2800 msat | | | | EOF | | | | | | amount_fwd: 500 msat | | trampoline_onion: | | | +-------------------------+ | | | | | expiry: 600112 | | +-----------------------+ | | +-----------------------------+ | | +--> | channel_id: 7 | ---> I3 ---> | | amount_fwd: 2500 msat | | --+ | EOF | | | |-----------------------| | | expiry: 600000 | | +-----------------------------+ | | | (encrypted) | | | node_id: Bob | | | | +-----------------------+ | +-----------------------+ | | | | | (encrypted) | | | | | +-----------------------+ | | | +---------------------------+ | | | EOF | | | +---------------------------+ | | | Alice --+ +--> Bob | | | | | HTLC(1500 msat, 600112 cltv) | | +---------------------------+ | | | amount_fwd: 1500 msat | | | | expiry: 600112 | | | HTLC(1560 msat, 600124 cltv) | payment_secret: bbbbb | | | +-----------------------+ | total_amount: 3000 msat | | | | amount_fwd: 1500 msat | | trampoline_onion: | HTLC3(1200 msat, 600000 cltv) | | | expiry: 600112 | | +-----------------------+ | +-----------------------------+ | | +--> | channel_id: 4 | ---> J1 ---> | | amount_fwd: 2700 msat | | --+ | amount_fwd: 1200 msat | | | | |-----------------------| | | expiry: 600000 | | | | expiry: 600000 | | | | | (encrypted) | | | node_id: Bob | | | | payment_secret: zzzzz | | | | +-----------------------+ | +-----------------------+ | | HTLC(1250 msat, 600080 cltv) | total_amount: 2700 msat | | | | | | (encrypted) | | | +-----------------------+ | trampoline_onion: | | | | | +-----------------------+ | | | amount_fwd: 1200 msat | | +-------------------------+ | | | | +---------------------------+ | | expiry: 600000 | | | amount_fwd: 2700 msat | | | | | | EOF | | +--> | channel_id: 563 | ---> J4 ---> | | expiry: 600000 | | --+ | | | +---------------------------+ | | |-----------------------| | | total_amount: 5200 msat | | | | | | HTLC(900 msat, 600112 cltv) | | | (encrypted) | | | payment_secret: yyyyy | | | | | | +---------------------------+ | | +-----------------------+ | +-------------------------+ | | | | | | amount_fwd: 900 msat | | | | | EOF | | | | | | | expiry: 600112 | | | | +-------------------------+ | | | | | HTLC(920 msat, 600130 cltv) | payment_secret: bbbbb | | | +-----------------------------+ | | | | +-----------------------+ | total_amount: 3000 msat | | | | EOF | | | | | | amount_fwd: 900 msat | | trampoline_onion: | | | +-----------------------------+ | | | | | expiry: 600112 | | +-----------------------+ | | | | | +-------+--> | channel_id: 6 | ---> J2 ---> | | amount_fwd: 2700 msat | | --+----> T2 ------+ +----+ | |-----------------------| | | expiry: 600000 | | | (fee 170 msat) | HTLC4(1500 msat, 600000 cltv) | | | (encrypted) | | | node_id: Bob | | | (delta 32) | +-----------------------------+ | | +-----------------------+ | +-----------------------+ | | | | amount_fwd: 1500 msat | | | | | (encrypted) | | | | | expiry: 600000 | | | | +-----------------------+ | | | | payment_secret: zzzzz | | | +---------------------------+ | | HTLC(1580 msat, 600065 cltv) | total_amount: 2700 msat | | | | EOF | | | +-----------------------+ | trampoline_onion: | | | +---------------------------+ | | | amount_fwd: 1500 msat | | +-------------------------+ | | | HTLC(600 msat, 600112 cltv) | | | expiry: 600000 | | | amount_fwd: 2700 msat | | | | +---------------------------+ | +--> | channel_id: 1108 | ---> J5 ---> | | expiry: 600000 | | --+ | | amount_fwd: 600 msat | | |-----------------------| | | total_amount: 5200 msat | | | | expiry: 600112 | | | (encrypted) | | | payment_secret: yyyyy | | | HTLC(610 msat, 600120 cltv) | payment_secret: bbbbb | | +-----------------------+ | +-------------------------+ | | +-----------------------+ | total_amount: 3000 msat | | | | EOF | | | | amount_fwd: 600 msat | | trampoline_onion: | | | +-------------------------+ | | | expiry: 600112 | | +-----------------------+ | | +-----------------------------+ +--> | channel_id: 8 | ---> J3 ---> | | amount_fwd: 2700 msat | | --+ | EOF | |-----------------------| | | expiry: 600000 | | +-----------------------------+ | (encrypted) | | | node_id: Bob | | +-----------------------+ | +-----------------------+ | | | (encrypted) | | | +-----------------------+ | +---------------------------+ | EOF | +---------------------------+

t-bast mentioned this pull request Dec 28, 2020

Lightning Specification Meeting 2021/01/04 #830

Closed

16 tasks

t-bast mentioned this pull request Jan 11, 2021

Lightning Specification Meeting 2021/01/18 #831

Closed

17 tasks

This was referenced Jan 25, 2021

Trampoline onion format (Feature 56/57) #836

Open

Lightning Specification Meeting 2021/02/01 #838

Closed

This was referenced Feb 9, 2021

Lightning Specification Meeting 2021/02/15 #840

Closed

Trampoline Routing #654

Closed

t-bast mentioned this pull request Feb 23, 2021

Lightning Specification Meeting 2021/03/01 #850

Closed

19 tasks

t-bast changed the title ~~Trampoline Routing (2021 edition)~~ Trampoline Routing (2021 edition) (Feature 24/25) Mar 2, 2021

t-bast mentioned this pull request Mar 15, 2021

Lightning Specification Meeting 2021/03/15 #853

Closed

9 tasks

Roasbeef mentioned this pull request Mar 17, 2021

channeldb+invoices: add spontaneous AMP receiving + sending via SendToRoute lightningnetwork/lnd#5108

Merged

3 tasks

t-bast mentioned this pull request Mar 24, 2021

Lightning Specification Meeting 2021/03/29 #856

Closed

11 tasks

t-bast mentioned this pull request Apr 8, 2021

Lightning Specification Meeting 2021/04/12 #860

Closed

9 tasks

t-bast mentioned this pull request Apr 22, 2021

Lightning Specification Meeting 2021/04/26 #864

Closed

12 tasks

t-bast mentioned this pull request May 10, 2021

Lightning Specification Meeting 2021/05/10 #870

Closed

9 tasks

t-bast force-pushed the trampoline-routing-no-gossip branch from b80370d to 03e9309 Compare October 23, 2024 08:34

t-bast mentioned this pull request Nov 22, 2024

Lightning Specification Meeting 2024/12/02 #1210

Closed

19 tasks

t-bast mentioned this pull request Dec 9, 2024

Lightning Specification Meeting 2024/12/16 #1213

Closed

19 tasks

t-bast mentioned this pull request Jan 6, 2025

Lightning Specification Meeting 2025/01/13 #1216

Closed

19 tasks

ecdsa mentioned this pull request Jan 15, 2025

Change OnionFailureCode returned when failing trampoline forwarding spesmilo/electrum#9433

Merged

t-bast mentioned this pull request Jan 22, 2025

Lightning Specification Meeting 2025/01/27 #1221

Closed

23 tasks

t-bast mentioned this pull request Feb 4, 2025

Lightning Specification Meeting 2025/02/10 #1224

Closed

21 tasks

t-bast mentioned this pull request Feb 19, 2025

Lightning Specification Meeting 2025/02/24 #1229

Closed

18 tasks

arik-so reviewed Feb 28, 2025

View reviewed changes

proposals/trampoline.md Show resolved Hide resolved

t-bast mentioned this pull request Mar 6, 2025

Lightning Specification Meeting 2025/03/10 #1234

Closed

19 tasks

t-bast mentioned this pull request Mar 20, 2025

Lightning Specification Meeting 2025/03/24 #1238

Closed

20 tasks

arik-so reviewed Mar 24, 2025

View reviewed changes

t-bast mentioned this pull request Apr 3, 2025

Lightning Specification Meeting 2025/04/07 #1244

Closed

24 tasks

t-bast mentioned this pull request Apr 16, 2025

Lightning Specification Meeting 2025/04/21 #1251

Closed

23 tasks

t-bast mentioned this pull request Apr 30, 2025

Lightning Specification Meeting 2025/05/05 #1255

Closed

22 tasks

t-bast mentioned this pull request May 15, 2025

Lightning Specification Meeting 2025/05/19 #1258

Closed

24 tasks

t-bast mentioned this pull request May 28, 2025

Lightning Specification Meeting 2025/06/02 #1262

Closed

26 tasks

t-bast mentioned this pull request Jun 11, 2025

Lightning Specification Meeting 2025/06/16 #1267

Closed

25 tasks

t-bast mentioned this pull request Jun 26, 2025

Lightning Specification Meeting 2025/06/30 #1272

Closed

25 tasks

t-bast mentioned this pull request Jul 8, 2025

Lightning Specification Meeting 2025/07/14 #1273

Closed

25 tasks

t-bast mentioned this pull request Jul 25, 2025

Lightning Specification Meeting 2025/07/28 #1275

Closed

24 tasks

t-bast mentioned this pull request Aug 7, 2025

Lightning Specification Meeting 2025/08/11 #1277

Closed

25 tasks

t-bast mentioned this pull request Aug 20, 2025

Lightning Specification Meeting 2025/08/25 #1283

Closed

27 tasks

This was referenced Sep 2, 2025

Trampoline support: client ElementsProject/lightning#8526

Open

Trampoline support: server ElementsProject/lightning#8527

Open

t-bast mentioned this pull request Sep 3, 2025

Lightning Specification Meeting 2025/09/08 #1286

Closed

26 tasks

t-bast mentioned this pull request Sep 17, 2025

Lightning Specification Meeting 2025/09/22 #1291

Closed

24 tasks

t-bast mentioned this pull request Oct 1, 2025

Lightning Specification Meeting 2025/10/06 #1293

Open

24 tasks

f321x reviewed Oct 8, 2025

View reviewed changes

f321x mentioned this pull request Oct 8, 2025

lightning: refactor htlc switch spesmilo/electrum#10230

Open

	- If it is the final node:
	- MUST reject the payment if:
	- The outer onion's `outgoing_cltv_value` is smaller than the trampoline onion's `outgoing_cltv_value`.
	- If this is a multi-part payment:
	- The outer onion's `total_msat` is smaller than the trampoline onion's `amt_to_forward`.
	- Otherwise:
	- The outer onion's `amt_to_forward` is smaller than the trampoline onion's `amt_to_forward`.

	Note that `amt_to_forward` is the amount for this HTLC only: a
	`total_msat` field containing a greater value is a promise by the
	ultimate sender that the rest of the payment will follow in succeeding
	HTLCs; we call these outstanding HTLCs which have the same preimage,
	an "HTLC set".

Trampoline Routing (2021 edition) (Feature 56/57) #829

Are you sure you want to change the base?

Trampoline Routing (2021 edition) (Feature 56/57) #829

Conversation

t-bast commented Dec 28, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

saubyk commented Dec 28, 2020

Uh oh!

t-bast commented Dec 28, 2020

Uh oh!

ecdsa commented Dec 31, 2020

Uh oh!

fiatjaf commented Jan 4, 2021

Uh oh!

t-bast commented Jan 4, 2021

Uh oh!

cdecker commented Jan 4, 2021

Uh oh!

t-bast commented Jan 8, 2021

Uh oh!

ecdsa commented Jan 8, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ecdsa commented Jan 8, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

t-bast commented Jan 8, 2021

Uh oh!

ecdsa commented Jan 22, 2021

Uh oh!

t-bast commented Jan 22, 2021

Uh oh!

cdecker commented Jan 22, 2021

Uh oh!

t-bast commented Jan 25, 2021

Uh oh!

ecdsa commented Jan 25, 2021

Uh oh!

t-bast commented Jan 25, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

arik-so Mar 24, 2025

Choose a reason for hiding this comment

Uh oh!

t-bast Mar 25, 2025

Choose a reason for hiding this comment

Uh oh!

f321x Oct 8, 2025

Choose a reason for hiding this comment

Uh oh!

t-bast Oct 9, 2025

Choose a reason for hiding this comment

Uh oh!

SomberNight Oct 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

t-bast commented Dec 28, 2020 •

edited

Loading

ecdsa commented Jan 8, 2021 •

edited

Loading

ecdsa commented Jan 8, 2021 •

edited

Loading

t-bast commented Jan 25, 2021 •

edited

Loading

SomberNight Oct 9, 2025 •

edited

Loading