Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update trampoline to use the official spec version #688

Draft
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

t-bast
Copy link
Member

@t-bast t-bast commented Jul 16, 2024

We update our trampoline code to use the official values from the BOLTs. Note that we don't maintain backwards-compatibility with the experimental trampoline feature bit and types, which means that:

  • when paying to nodes that use the experimental version, we won't use trampoline and will fallback to trampoline-to-legacy
  • nodes that use the experimental version will not understand the official feature bit, so they will pay us with trampoline-to-legacy

I think this is a good trade-off to avoid the technical debt and risks associated with maintaining two versions of trampoline in parallel.

Builds on top of #685

The v4 serialization format was released in July 2023 with better
support for backwards-compatibility: the v2 and v3 formats used
kotlin's serialization, which prevents us from removing legacy
classes and requires additional code whenever we change something
in the channel state.

Users who haven't migrated their data to the v4 format will not be
able to deserialize their channel data: they will need to use a
previous version of the app to read their old channel data, write
it to the v4 format and then upgrade to the latest version.

We also remove a bunch of fields/options that were deprecated a
while ago:

- legacy channel funding states
- unused legacy features
- legacy private key generation
- legacy node events
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.
Add support for the trampoline failure messages added to the BOLTs.
We also add support for encrypting failures e2e using the trampoline
shared secrets on top of the outer onion shared secrets.
When the recipient supports blinded trampoline payments and uses the
same introduction node as our trampoline node, we mustn't add a hop
from our trampoline node to itself: we can directly use them as the
blinded path's trampoline introduction node.

This is what payments between mobile wallets using the same trampoline
node will look like.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant