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

Remove KeysInterface #1930

Merged

Conversation

arik-so
Copy link
Contributor

@arik-so arik-so commented Dec 20, 2022

No description provided.

@arik-so arik-so force-pushed the 2022-12-remove-keysinterface branch 2 times, most recently from c8fd161 to 74a5712 Compare December 21, 2022 00:48
@codecov-commenter
Copy link

codecov-commenter commented Dec 21, 2022

Codecov Report

Base: 90.73% // Head: 90.76% // Increases project coverage by +0.02% 🎉

Coverage data is based on head (22d7a0b) compared to base (5221e4a).
Patch coverage: 97.60% of modified lines in pull request are covered.

❗ Current head 22d7a0b differs from pull request most recent head 49c1f30. Consider uploading reports for the commit 49c1f30 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1930      +/-   ##
==========================================
+ Coverage   90.73%   90.76%   +0.02%     
==========================================
  Files          97       96       -1     
  Lines       50539    50088     -451     
  Branches    50539    50088     -451     
==========================================
- Hits        45859    45461     -398     
+ Misses       4680     4627      -53     
Impacted Files Coverage Δ
lightning-block-sync/src/init.rs 91.11% <ø> (ø)
lightning/src/chain/keysinterface.rs 83.78% <ø> (-0.04%) ⬇️
lightning/src/ln/chan_utils.rs 93.56% <ø> (ø)
lightning/src/ln/onion_route_tests.rs 97.64% <ø> (-0.01%) ⬇️
lightning/src/ln/payment_tests.rs 98.73% <ø> (+<0.01%) ⬆️
lightning/src/ln/peer_handler.rs 55.82% <ø> (ø)
lightning/src/ln/priv_short_conf_tests.rs 96.54% <ø> (ø)
lightning/src/ln/reorg_tests.rs 100.00% <ø> (ø)
lightning/src/ln/shutdown_tests.rs 96.51% <ø> (ø)
lightning/src/routing/router.rs 90.90% <ø> (+0.03%) ⬆️
... and 53 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@arik-so arik-so changed the title WIP: Remove KeysInterface Remove KeysInterface Dec 21, 2022
@arik-so arik-so marked this pull request as ready for review December 21, 2022 03:37
lightning/src/util/persist.rs Outdated Show resolved Hide resolved
lightning/src/util/persist.rs Outdated Show resolved Hide resolved
@@ -372,7 +372,7 @@ where
CF::Target: 'static + chain::Filter,
CW::Target: 'static + chain::Watch<<K::Target as SignerProvider>::Signer>,
T::Target: 'static + BroadcasterInterface,
K::Target: 'static + KeysInterface,
K::Target: 'static + EntropySource + NodeSigner + SignerProvider,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I imagine we can probably start to split each of these out into their own generic constraint (yay more generics). EntropySource seems like a good candidate since it's somewhat standalone. NodeSigner and SignerProvider really depends on the underlying deployment, since they will likely be backed by the same HSM/secure element.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, if we're splitting the traits I have to assume we expect people to have different structs that implement different parts of the traits (otherwise why are we doing this to begin with :) ), in which case we need to break up the generics as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree we should split things up, but I would lean against doing all the splitting in this PR, maybe with the exception of some very shallow-level API examples, like BackgroundProcessor. BackgroundProcessor definitely lacks generics.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it will be less effort to do it in one PR? As-is is just more diff and intermediate state, it would be less total diff to review doing it all at once.

Copy link
Contributor Author

@arik-so arik-so Dec 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, one benefit of splitting it up into two is that it would allow @wpaulino to open his node_secret removal PR against the commit that's currently in this one, while I work on the follow-up in parallel. But I'll work on the parameter split tonight; maybe I can get it in fast enough and it's less trouble than I'm anticipating.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that would conflict, now that we split the traits and moved those functions around. This PR doesn't really heavily touch the keysinterface.rs file.

lightning/src/ln/inbound_payment.rs Outdated Show resolved Hide resolved
@arik-so
Copy link
Contributor Author

arik-so commented Dec 22, 2022

Wilmer just made the point that instead of removing KeysInterface entirely, we could simply make it be comprised of NodeSigner and SignerProvider, removing its EntropySource component.

@TheBlueMatt
Copy link
Collaborator

I'm still not sure why its worth doing that as a separate PR, but, sure, if you want to do that to make forward progress, sounds fine. We'll ultimately need to do it for all of them anyway.

@arik-so arik-so force-pushed the 2022-12-remove-keysinterface branch 6 times, most recently from eafdaa2 to 22d7a0b Compare December 25, 2022 19:51
@TheBlueMatt
Copy link
Collaborator

This commit separation makes the PR really hard to review (ie generates more total lines of diff to look at) - can you instead break it up as individual commits which change different structs to use individual traits (including the lifetime changes) and then only as the very last commit remove the (at that point unused) KeysInterface trait? That should lead to a series of relatively small commits.

@arik-so
Copy link
Contributor Author

arik-so commented Jan 5, 2023

I'll try

@TheBlueMatt
Copy link
Collaborator

Needs rebase after #1812, sorry. Should be mechanical but may be a bit annoying.

@arik-so
Copy link
Contributor Author

arik-so commented Jan 11, 2023

There are only like two files that are letting their KeysInterface arguments be split up atomically, inbound_payment.rs and blinded_path.rs. Everything else percolates down to the Channel and ChannelManager struct, resulting in an all-or-nothing scenario.

@TheBlueMatt
Copy link
Collaborator

Can't OnionMessenger go separately as well? Also probably ChannelMonitor, no?

@arik-so
Copy link
Contributor Author

arik-so commented Jan 12, 2023

Funny you say that, because those two are exactly the types I've been trying to make separate. But no, they both have dependency chains that suck in all of Channel and ChannelManager.

@arik-so arik-so force-pushed the 2022-12-remove-keysinterface branch from 22d7a0b to a65fa82 Compare January 12, 2023 23:58
@arik-so arik-so force-pushed the 2022-12-remove-keysinterface branch from a65fa82 to 49c1f30 Compare January 13, 2023 00:11
@TheBlueMatt
Copy link
Collaborator

If you remove the KeysInterface last, rather than first, I think it should work? Which dependency chain are you referring to?

@arik-so
Copy link
Contributor Author

arik-so commented Jan 13, 2023

I'm talking about splitting up the keys_interface argument into implementations of its comprising traits. Once you have two or three arguments of different traits, that dependency chain sneaks through pretty much everything. That is unrelated to removing KeysInterface.

@@ -317,7 +317,7 @@ pub struct Node<'a, 'b: 'a, 'c: 'b> {
pub router: &'b test_utils::TestRouter<'c>,
pub chain_monitor: &'b test_utils::TestChainMonitor<'c>,
pub keys_manager: &'b test_utils::TestKeysInterface,
pub node: &'a ChannelManager<&'b TestChainMonitor<'c>, &'c test_utils::TestBroadcaster, &'b test_utils::TestKeysInterface, &'c test_utils::TestFeeEstimator, &'b test_utils::TestRouter<'c>, &'c test_utils::TestLogger>,
pub node: &'a ChannelManager<&'b TestChainMonitor<'c>, &'c test_utils::TestBroadcaster, &'b test_utils::TestKeysInterface, &'b test_utils::TestKeysInterface, &'b test_utils::TestKeysInterface, &'c test_utils::TestFeeEstimator, &'b test_utils::TestRouter<'c>, &'c test_utils::TestLogger>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pre-existing, but we really need a type alias for this test ChannelManager...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true that

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

Successfully merging this pull request may close these issues.

None yet

4 participants