Skip to content
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

Conversation

ViktorTigerstrom
Copy link
Contributor

After #105 and #422, channels will be stored in the ChannelManager::per_peer_state which requires the counterparty_node_id to access them. #1278 also requires this updated storage design. This will require that the user passes the counterparty_node_id to some of the public API functions of the ChannelManager for which only the channel_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 the counterparty_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.

@codecov-commenter
Copy link

codecov-commenter commented May 12, 2022

Codecov Report

Merging #1479 (e9a5407) into main (b5a6307) will decrease coverage by 0.01%.
The diff coverage is 98.03%.

❗ Current head e9a5407 differs from pull request most recent head c179844. Consider uploading reports for the commit c179844 to get more accurate results

@@            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     
Impacted Files Coverage Δ
lightning/src/ln/channelmanager.rs 84.75% <91.30%> (-0.03%) ⬇️
lightning-background-processor/src/lib.rs 94.37% <100.00%> (ø)
lightning-persister/src/lib.rs 93.45% <100.00%> (ø)
lightning/src/ln/chanmon_update_fail_tests.rs 97.76% <100.00%> (ø)
lightning/src/ln/functional_test_utils.rs 95.54% <100.00%> (+<0.01%) ⬆️
lightning/src/ln/functional_tests.rs 97.09% <100.00%> (-0.08%) ⬇️
lightning/src/ln/monitor_tests.rs 100.00% <100.00%> (ø)
lightning/src/ln/payment_tests.rs 99.23% <100.00%> (ø)
lightning/src/ln/priv_short_conf_tests.rs 97.95% <100.00%> (ø)
lightning/src/ln/shutdown_tests.rs 96.50% <100.00%> (ø)
... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b5a6307...c179844. Read the comment docs.

@ViktorTigerstrom
Copy link
Contributor Author

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> {
Copy link
Contributor Author

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?

Copy link
Collaborator

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> {
Copy link
Collaborator

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.

@ViktorTigerstrom
Copy link
Contributor Author

Addressed the feedback and the failed checks. Let me know if you think it's worth adding the extra counterparty_node_id check to create_funding_transaction (commit a85a63e), and I'll squash it with the FundingGenerationReady commit! Else I will drop that specific commit.

@@ -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() {
Copy link
Contributor Author

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.

Copy link
Collaborator

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.

@TheBlueMatt
Copy link
Collaborator

Feel free to squash the fix up commits into the corresponding commits.

@ViktorTigerstrom ViktorTigerstrom force-pushed the 2022-05-pass-counterparty-id-to-functions branch from e9a5407 to ded76da Compare May 14, 2022 00:17
@ViktorTigerstrom
Copy link
Contributor Author

ViktorTigerstrom commented May 14, 2022

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 OpenChannelRequest, do you prefer it to be a separate commit, or should I squash it with the Pass counterparty_node_id to accept_inbound_channel commit as that's the reason for the doc update?

TheBlueMatt
TheBlueMatt previously approved these changes May 14, 2022
@@ -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> {
Copy link
Collaborator

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.

Copy link
Contributor Author

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 :).

@ViktorTigerstrom ViktorTigerstrom force-pushed the 2022-05-pass-counterparty-id-to-functions branch from ded76da to c179844 Compare May 14, 2022 18:35
@ViktorTigerstrom ViktorTigerstrom marked this pull request as ready for review May 14, 2022 18:38
@ViktorTigerstrom
Copy link
Contributor Author

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants