Uh oh!
There was an error while loading. Please reload this page.
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.
|
ViktorT-11
commented
May 12, 2022
Sorry for the failed checks, will address them tomorrow. |
| /// [`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.
Should we add the counterparty_node_id to the FundingGenerationReady event?
| } | ||
| 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.
nit: add a _ to the variable name so rustc doesn't complain its unused.
ViktorT-11
commented
May 13, 2022
Addressed the feedback and the failed checks. Let me know if you think it's worth adding the extra |
| 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.
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.
Yea don't worry about it, then.
TheBlueMatt
commented
May 13, 2022
Feel free to squash the fix up commits into the corresponding commits. |
e9a5407 to
ded76daCompareThanks @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 |
| } | ||
| 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.
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.
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
c179844CompareViktorT-11
commented
May 14, 2022
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_statewhich requires thecounterparty_node_idto access them. #1278 also requires this updated storage design. This will require that the user passes thecounterparty_node_idto some of the public API functions of theChannelManagerfor which only thechannel_idis 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_idas an input parameter, name thecounterparty_node_iddifferently. 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.