-
Notifications
You must be signed in to change notification settings - Fork 24
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
t-bast
wants to merge
6
commits into
master
Choose a base branch
from
trampoline-spec-version
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
t-bast
force-pushed
the
trampoline-spec-version
branch
from
July 18, 2024 13:52
c7a69c3
to
3e8b0dc
Compare
t-bast
force-pushed
the
trampoline-spec-version
branch
from
August 9, 2024 10:02
3e8b0dc
to
a5e3e16
Compare
t-bast
force-pushed
the
trampoline-spec-version
branch
from
September 18, 2024 21:02
2a1e84d
to
b5764b0
Compare
t-bast
force-pushed
the
trampoline-spec-version
branch
from
October 22, 2024 02:32
b5764b0
to
6aeb170
Compare
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.
t-bast
force-pushed
the
trampoline-spec-version
branch
from
October 23, 2024 05:34
6aeb170
to
c43d447
Compare
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
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