Trampoline

[valentinewallace]

• [x] Serialization
  • [x] [AP] Outbound
    • [x] Support sending an HTLC with a trampoline onion packet (#2756)
    • [x] Support constructing a nested trampoline onion packet (#2906)
    • [x] Support serializing blinded path hops (#3007)
    • [x] Allow variable length nested onions? (Consensus with @t-bast is probably not in the immediate future, due to privacy concerns)
      • [x] Variable-length onion packet (#2756)
  • [ ] [AP] Inbound
    • [x] Support deserializing Trampoline packets (#3006)
    • [x] Support receiving a payment containing a trampoline onion packet (#3670)
    • [x] Support encoding+parsing trampoline onion errors (#3657)
    • [ ] Correctly wrap error packet twice if failing back a received phantom + trampoline HTLC
• [x] Wire Communication
  • [x] Feature flag (#2756)
• [ ] Routing
  • [ ] Support pathfinding for a trampoline payment
    • [x] [AP] Trampoline packet assembly from Path (#3386)
    • [ ] Flag-aware hop selection for packet construction (WIP: https://github.com/arik-so/rust-lightning/tree/arik/trampoline/pathfinding)
    • [x] Calculate onion length dynamically (#3333)
    • [ ] [AP] Router for LSP clients to return a single-hop route using Trampoline
  • [ ] Forwarding payments as Trampoline node
    • [ ] [AP] Support forwarding a trampoline payment to the next trampoline hop
      • [ ] Pathfind and forward payments between Trampoline nodes (#3711)
      • [ ] Shorten CLTV (ensure it's relative)
      • [ ] Support retrying a trampoline payment as an intermediate trampoline node
    • [ ] Support aggregating MPP payments at intermediate trampoline hops
  • [ ] Advertise Trampoline support
• [ ] Interaction
  • [x] [AP] Expose method for sending to Trampoline node (covered implicitly by #3386, which modifies the call stack originating from send_payment_for_verified_bolt12_invoice)
  • [x] Support reading and creating invoices with trampoline route hints, in BOLT11 + BOLT12 (#3446)
  • [x] Interaction with blinded paths: resolved to be mandatory.
• [ ] Bindings Support

AP: Prerequisite for async payments MVP.

[TheBlueMatt]

Also update the anchor reserves re: https://github.com/lightningdevkit/rust-lightning/pull/3487#discussion_r1951591121 once that PR lands

[joostjager]

Is it necessary to implement all of this? The question came up after reading https://github.com/lightning/bolts/pull/836#discussion_r1986963231. If it's just mobile wallets connected to their LSP, maybe some of the items on this list can be postponed?

[TheBlueMatt]

In theory we can just do the end-user bits first, but when we ship that there won't be any LSPs for the users, so we really need to implement the LSP end as well (not to mention its really hard to test unless we can do end-to-end logic in a test).

[joostjager]

Ah, I wasn't completely clear. I was suggesting to still implement end-user + LSP, but just for single hop, single trampoline payments.

But it appears that that doesn't make the amount of code that much less - https://github.com/lightning/bolts/pull/836#discussion_r1989589007