-
Notifications
You must be signed in to change notification settings - Fork 385
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
Support ZeroConf
channel type.
#1505
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -397,7 +397,8 @@ pub enum Event { | |
/// transaction. | ||
claim_from_onchain_tx: bool, | ||
}, | ||
/// Used to indicate that a channel with the given `channel_id` is in the process of closure. | ||
/// Used to indicate that a previously opened channel with the given `channel_id` is in the | ||
/// process of closure. | ||
ChannelClosed { | ||
/// The channel_id of the channel which has been closed. Note that on-chain transactions | ||
/// resolving the channel are likely still awaiting confirmation. | ||
|
@@ -466,6 +467,12 @@ pub enum Event { | |
/// the resulting [`ChannelManager`] will not be readable by versions of LDK prior to | ||
/// 0.0.106. | ||
/// | ||
/// Furthermore, note that if [`ChannelTypeFeatures::supports_zero_conf`] returns true on this type, | ||
/// the resulting [`ChannelManager`] will not be readable by versions of LDK prior to | ||
/// 0.0.107. Channels setting this type also need to get manually accepted via | ||
/// [`crate::ln::channelmanager::ChannelManager::accept_inbound_channel_from_trusted_peer_0conf`], | ||
/// or will be rejected otherwise. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, so its not technically "rejected otherwise" the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. AFAICT, if the user calls the wrong method and the channel keeps 'lingering' in our Also not entirely sure what 'force-close' would mean in this context? We'd probably just send an error over the wire and remove the channel from There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Correct, though its pretty different in that the user handled the We can (generally) assume that users will try to handle
Agreed - in general we should eventually time-out requests, but such requests may take some time to process (external API calls to third-party providers are not unlikely, I believe), so we have to be kinda conservative here, likely even too conservative for moving the
Yep, that. I generally use "force-close" to mean "send error message and close channel", though, indeed, there's no broadcast associated here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Alright, I now reject the channel in |
||
/// | ||
/// [`ChannelManager`]: crate::ln::channelmanager::ChannelManager | ||
channel_type: ChannelTypeFeatures, | ||
}, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wont this change imply we accept a channel_type that has some other unknown bit set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Argh, right. Fixed this with 7f8bab5.