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

Drop ChannelKeys Private Key Methods #632

Merged

Conversation

TheBlueMatt
Copy link
Collaborator

This isn't quite sufficient for a secure external signer, as we still expose commitment_seed(), but its a nice cleanup after #610 did all the heavy lifting and its a good step.

As we drop the requirement that all ChannelKeys expose the private
keys used, we should have a way to access the private keys in use
when using InMemoryChannelKeys.
@codecov
Copy link

codecov bot commented May 28, 2020

Codecov Report

Merging #632 into master will decrease coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #632      +/-   ##
==========================================
- Coverage   91.26%   91.26%   -0.01%     
==========================================
  Files          35       35              
  Lines       20929    20918      -11     
==========================================
- Hits        19101    19090      -11     
  Misses       1828     1828              
Impacted Files Coverage Δ
lightning/src/ln/functional_tests.rs 97.11% <ø> (ø)
lightning/src/chain/keysinterface.rs 94.78% <100.00%> (-0.08%) ⬇️
lightning/src/ln/channel.rs 86.62% <100.00%> (-0.01%) ⬇️
lightning/src/ln/channelmonitor.rs 95.71% <100.00%> (ø)
lightning/src/util/enforcing_trait_impls.rs 100.00% <100.00%> (ø)

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 2087032...e5a7422. Read the comment docs.

Copy link

@ariard ariard left a comment

Choose a reason for hiding this comment

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

ACK 09a6ce4

/// Gets the local secret key used in HTLC-Success/HTLC-Timeout txn and to_local output
fn delayed_payment_base_key<'a>(&'a self) -> &'a SecretKey;
/// Gets the local htlc secret key used in commitment tx htlc outputs
fn htlc_base_key<'a>(&'a self) -> &'a SecretKey;
/// Gets the commitment seed
fn commitment_seed<'a>(&'a self) -> &'a [u8; 32];
Copy link

Choose a reason for hiding this comment

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

Future work, should we move commitment_seed out-of-memory and behind the interface by moving inside chan_utils::build_commitment_secret ? In case of undetected node compromise, access to the commitment seed let you derive revocation secret for future non-yet-existent local commitment transactions ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yea, I think we have to. If you want an external signer to prevent the host from burning all the coins, you need some kind of exchange here, but we'd also need to get the ordering right, like, to call get_commitment_revocation_secret we'd have to first provide a copy of the new commitment transaction.

@@ -345,17 +333,17 @@ pub trait KeysInterface: Send + Sync {
/// A simple implementation of ChannelKeys that just keeps the private keys in memory.
pub struct InMemoryChannelKeys {
/// Private key of anchor tx
funding_key: SecretKey,
pub funding_key: SecretKey,
Copy link
Contributor

Choose a reason for hiding this comment

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

I think even for this concrete implementation, it would be better to not make the private key properties public. Perhaps add a test config constraint?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

You need them to be able to sign transactions when handling SpendableOutput events, so there needs to be some way to get at them.

Copy link
Contributor

Choose a reason for hiding this comment

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

Don't know the full context, but might it be better to expose a way to use them (e.g. expose a sign_tx method) rather than exposing the keys themselves?

Copy link
Contributor

Choose a reason for hiding this comment

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

If the signing only handles in impl for InMemoryChannelKeys, they may not have to be pub, right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

No, we dont require signing functions for SpendableOutputs events as those are purely external and can happen a month later. eg the use in the tests at https://github.com/rust-bitcoin/rust-lightning/blob/master/lightning/src/ln/functional_tests.rs#L4299

Copy link
Contributor

@arik-so arik-so left a comment

Choose a reason for hiding this comment

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

Very simple and elegant PR!

Copy link
Contributor

@valentinewallace valentinewallace left a comment

Choose a reason for hiding this comment

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

lgtm 🥇

@TheBlueMatt TheBlueMatt force-pushed the 2020-05-drop-chankeys-privs branch from 09a6ce4 to e5a7422 Compare June 6, 2020 19:59
@TheBlueMatt TheBlueMatt merged commit f08d610 into lightningdevkit:master Jun 6, 2020
@lightningdevkit lightningdevkit deleted a comment Jul 2, 2020
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.

4 participants