Trampoline

[valentinewallace]

• Serialization
  • [AP] Outbound
    • Support sending an HTLC with a trampoline onion packet (Serialize Trampoline payloads in outbound onions. #2756)
    • Support constructing a nested trampoline onion packet (Trampoline onion construction vectors #2906)
    • Support serializing blinded path hops (Serialize blinded Trampoline hops #3007)
    • Allow variable length nested onions? (Consensus with @t-bast is probably not in the immediate future, due to privacy concerns)
      • Variable-length onion packet (Serialize Trampoline payloads in outbound onions. #2756)
  • [AP] Inbound
    • Support deserializing Trampoline packets (Trampoline Onion Deserialization #3006)
    • Support receiving a payment containing a trampoline onion packet (Handle receiving payments via Trampoline #3670)
    • Support encoding+parsing trampoline onion errors (Decrypt Trampoline error onions #3657)
• Wire Communication
  • Feature flag (Serialize Trampoline payloads in outbound onions. #2756)
• Routing
  • Support pathfinding for a trampoline payment
    • [AP] Trampoline packet assembly from Path (Trampoline Payload Construction Method #3386)
    • Flag-aware hop selection for packet construction (WIP: https://github.com/arik-so/rust-lightning/tree/arik/trampoline/pathfinding)
    • Calculate onion length dynamically (Calculate Trampoline onion packet sizes 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
      • 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
  • [AP] Expose method for sending to Trampoline node (covered implicitly by Trampoline Payload Construction Method #3386, which modifies the call stack originating from send_payment_for_verified_bolt12_invoice)
  • Support reading and creating invoices with trampoline route hints, in BOLT11 + BOLT12 (Support Trampoline flag in BOLT12 invoices #3446)
  • Interaction with blinded paths: resolved to be mandatory.
• Bindings Support

AP: Prerequisite for async payments MVP.

[TheBlueMatt]

Also update the anchor reserves re: #3487 (comment) once that PR lands

[joostjager]

Is it necessary to implement all of this? The question came up after reading lightning/bolts#836 (comment). 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 - lightning/bolts#836 (comment)