Add feature bits for experimental wallet features #237
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
|
Seems like a good idea 👍 we could add the swap-in bit now as well Also why not use a even higher feature bit? 60 does not seem very high to me. |
True, we could. At the rate at which features get adopted in the spec, I think 60 and above still let us enjoy these for at least 10 years, but we can be more prudent 😆 |
dpad85
previously approved these changes
Mar 31, 2021
t-bast
force-pushed
the
pay-to-open-feature-bit
branch
2 times, most recently
from
e71e93b
to
d8e90c4
Compare
t-bast
force-pushed
the
pay-to-open-feature-bit
branch
from
d8e90c4
to
a5dbdd6
Compare
t-bast
changed the title
t-bast
force-pushed
the
pay-to-open-feature-bit
branch
from
a5dbdd6
to
cc4b360
Compare
SomberNight
added a commit
to spesmilo/electrum
that referenced
this pull request
Jul 2, 2021
It is the last Trampoline Forwarder that should be checked, not the first one. Consider route (of Trampolines only): Alice-electrum -> T_ACINQ -> T_Hodlister -> Bob-electrum Even if Bob has a transport open with ACINQ or even if Bob has a channel open with ACINQ, Alice can safely use end-to-end trampoline for this route: ACINQ will not know who the recipient is, so they will not try to do pay-to-open (and hold up the payment for minutes...). related: ACINQ/lightning-kmp#237
t-bast
force-pushed
the
pay-to-open-feature-bit
branch
2 times, most recently
from
179346b
to
886e6f1
Compare
Wallets should explicitly advertise support for pay-to-open, trusted swaps and wake-up notifications in their `init` message, to allow the LSPs they connect to to know what they're allowed to do. This lets LSPs know for example whether they can open a channel on-the-fly when liquidity is missing to receive a payment.
t-bast
force-pushed
the
pay-to-open-feature-bit
branch
from
886e6f1
to
6f144d1
Compare
t-bast
changed the title
t-bast
added a commit
that referenced
this pull request
Jul 13, 2021
This feature was introduced by lightning/bolts#880 We also clean up the channel state machine to leverage the feature bits added in #237
sstone
approved these changes
Jul 15, 2021
t-bast
added a commit
that referenced
this pull request
Jul 16, 2021
This feature was introduced by lightning/bolts#880 We also clean up the channel state machine to leverage the feature bits added in #237
t-bast
added a commit
that referenced
this pull request
Aug 17, 2021
This feature was introduced by lightning/bolts#880 We also clean up the channel state machine to leverage the feature bits added in #237
t-bast
added a commit
that referenced
this pull request
Aug 24, 2021
This feature was introduced by lightning/bolts#880 We also clean up the channel state machine to leverage the feature bits added in #237
t-bast
added a commit
that referenced
this pull request
Sep 23, 2021
This feature was introduced by lightning/bolts#880 We also clean up the channel state machine to leverage the feature bits added in #237
t-bast
added a commit
that referenced
this pull request
Sep 24, 2021
This feature was introduced by lightning/bolts#880 We also clean up the channel state machine to leverage the feature bits added in #237
t-bast
added a commit
that referenced
this pull request
Sep 27, 2021
This feature was introduced by lightning/bolts#880 We also clean up the channel state machine to leverage the feature bits added in #237
t-bast
added a commit
that referenced
this pull request
Sep 27, 2021
This feature was introduced by lightning/bolts#880 We also clean up the channel state machine to leverage the feature bits added in #237
t-bast
added a commit
that referenced
this pull request
Dec 9, 2021
This feature was introduced by lightning/bolts#880 and the feature bit was added in lightning/bolts#906 We also clean up the channel state machine to leverage the feature bits added in #237
t-bast
added a commit
that referenced
this pull request
Feb 4, 2022
This feature was introduced by lightning/bolts#880 and the feature bit was added in lightning/bolts#906 We also clean up the channel state machine to leverage the feature bits added in #237
t-bast
added a commit
that referenced
this pull request
Feb 4, 2022
* Rename ChannelTypes -> ChannelData And move commands to a new ChannelCommands file. This commit doesn't contain any logic changes. * Require explicit channel type negotiation This feature was introduced by lightning/bolts#880 and the feature bit was added in lightning/bolts#906 We also clean up the channel state machine to leverage the feature bits added in #237
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.
Wallets should explicitly advertise support for experimental features (e.g. pay-to-open, swaps, wake-up notifications, etc) in their
initmessage, to allow the LSPs they connect to to know whether they should use these experimental features (e.g. open a channel on-the-fly when liquidity is missing to receive a payment).Otherwise the LSP must use heuristics that may be incorrect and initiate experimental protocols with nodes/wallets that don't support them (this is happening with electrum).
I used two feature bits for asymmetric features, as explored here: lightning/bolts#885
A later PR should introduce support for actually disabling these features (and turning off the corresponding code branches).
NB: this can be merged after the initial release, no rush.