-
Notifications
You must be signed in to change notification settings - Fork 367
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
Pass counterparty_node_id
to ChannelManager
functions
#1479
Pass counterparty_node_id
to ChannelManager
functions
#1479
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1479 +/- ##
==========================================
- Coverage 90.89% 90.88% -0.02%
==========================================
Files 76 76
Lines 42067 42073 +6
Branches 42067 42073 +6
==========================================
+ Hits 38238 38239 +1
- Misses 3829 3834 +5
Continue to review full report at Codecov.
|
Sorry for the failed checks, will address them tomorrow. |
@@ -2757,7 +2756,7 @@ impl<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelMana | |||
/// | |||
/// [`Event::FundingGenerationReady`]: crate::util::events::Event::FundingGenerationReady | |||
/// [`Event::ChannelClosed`]: crate::util::events::Event::ChannelClosed | |||
pub fn funding_transaction_generated(&self, temporary_channel_id: &[u8; 32], funding_transaction: Transaction) -> Result<(), APIError> { | |||
pub fn funding_transaction_generated(&self, temporary_channel_id: &[u8; 32], counterparty_node_id: &PublicKey, funding_transaction: Transaction) -> Result<(), APIError> { |
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.
Should we add the counterparty_node_id
to the FundingGenerationReady
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.
Yes!
@@ -1769,7 +1769,7 @@ impl<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelMana | |||
}); | |||
} | |||
|
|||
fn close_channel_internal(&self, channel_id: &[u8; 32], target_feerate_sats_per_1000_weight: Option<u32>) -> Result<(), APIError> { | |||
fn close_channel_internal(&self, channel_id: &[u8; 32], counterparty_node_id: &PublicKey, target_feerate_sats_per_1000_weight: Option<u32>) -> Result<(), APIError> { |
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.
nit: add a _ to the variable name so rustc doesn't complain its unused.
Addressed the feedback and the failed checks. Let me know if you think it's worth adding the extra |
@@ -4130,6 +4131,9 @@ impl<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelMana | |||
if !channel.get().inbound_is_awaiting_accept() { | |||
return Err(APIError::APIMisuseError { err: "The channel isn't currently awaiting to be accepted.".to_owned() }); | |||
} | |||
if *counterparty_node_id != channel.get().get_counterparty_node_id() { |
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.
Let me know if you want me to add a test case for this. Though given that it shouldn't be a thing after #105, perhaps it isn't really worth it.
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.
Yea don't worry about it, then.
Feel free to squash the fix up commits into the corresponding commits. |
e9a5407
to
ded76da
Compare
Thanks @TheBlueMatt! Squashed the commits without changes. The only one I'm not entirely sure about is ded76da. As it's an update to the docs of the |
lightning/src/ln/channelmanager.rs
Outdated
@@ -1769,7 +1769,7 @@ impl<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelMana | |||
}); | |||
} | |||
|
|||
fn close_channel_internal(&self, channel_id: &[u8; 32], target_feerate_sats_per_1000_weight: Option<u32>) -> Result<(), APIError> { | |||
fn close_channel_internal(&self, channel_id: &[u8; 32], _counterparty_node_id: &PublicKey, target_feerate_sats_per_1000_weight: Option<u32>) -> Result<(), APIError> { |
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 mean if you want to you can replace the existing counterparty_node_id
variable in the function, but of course it doesn't matter it'll come in the next PR.
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 that was my reasoning behind that choice, but changed that now just in case you'd like to merge this PR before the next PR is completed :).
As the `counterparty_node_id` is now required to be passed back to the `ChannelManager` to accept or reject an inbound channel request, the documentation is updated to reflect that.
ded76da
to
c179844
Compare
Addressed the latest feedback, and marked this as an open PR in case you think it's worth merging this before the functionality for #105 is completed :) |
After #105 and #422, channels will be stored in the
ChannelManager::per_peer_state
which requires thecounterparty_node_id
to access them. #1278 also requires this updated storage design. This will require that the user passes thecounterparty_node_id
to some of the public API functions of theChannelManager
for which only thechannel_id
is passed currently.This PR updates the parameters required in those functions, to include the
counterparty_node_id
.I figured it's probably better to separate the API changes from rest of the channel storage changes. Let me know if you're of a different opinion, and I'll close this PR.
Pushing this as a draft for now, but let me know if you think that better to merge this before the other functionality is ready (#105 and #422), which I will base on this.
Finally, when updating these functions, I also noticed that lots of other functions that has the
counterparty_node_id
as an input parameter, name thecounterparty_node_id
differently. That could be a bit confusing in my opinion. Examples that I have found are:their_node_id
,their_network_key
,peer_node_id
. Let me know if you'd like me to update the name this PR is using, or if I should update the name in the other functions to make it uniform.