-
Notifications
You must be signed in to change notification settings - Fork 415
feat: expose channel_reserve_satoshis
via ChannelParameters
#3910
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
Open
Prabhat1308
wants to merge
1
commit into
lightningdevkit:main
Choose a base branch
from
Prabhat1308:probot/expose_csr
base: main
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.
+22
−5
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
Oops, something went wrong.
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.
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.
We can't do this, as
OpenChannelV2
doesn't have that field, see https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#the-open_channel2-messageIt's also not a 'common' field per se as per spec:
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.
The best bet would be to have a new top-level field in
OpenChannelRequest
forchannel_reserve_satoshis
and then set that inchannelmanager
like:The
get_v2_channel_reserve_satoshis
exists in thechannel
module. You'd need to make thatpub(super)
.This would be a breaking change and also would need docs and shouldn't be backported.
Uh oh!
There was an error while loading. Please reload this page.
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.
Hmm, while that would be pretty easy, I'm not super happy about exposing such a detail at the top level API, especially if we have sub-structs in-place. can't we reuse
ChannelParameters
still, but apply above rules for v2 channels? Or, maybe it would be the right time to refactorOpenChannelRequest
(orChannelParameters
) to discern between V1 and V2 channels?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.
Yeah you could reuse
ChannelParameters
and just have the field there, update the doc comment for it as it currently mentions being a subset of the common fields. It will just need to be initialised as 0 inCommonOpenChannelFields::channel_parameters
and then set like above when creating theOpenChannelRequest
event. I'm not sure anOption
is worth the effort as it'll always end up being Some() when accessed by the user.Refactoring is fine, but we'd want to still have a single
OpenChannelRequest
event.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.
I think still at the current state putting the field in
ChannelParameters
would be a violation of the spec ? Given that if we include it inChannelParameters
it would still be underCommonOpenChannelFields
and hence in bothOpenChannel
v1 and v2 even if we put a dummy value like 0 in the beginning . I think we might be looking at a refactor here if we want to useChannelParameters
.