-
Notifications
You must be signed in to change notification settings - Fork 421
Introduce EnforcementState, validate release of revocation secret #1039
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
Introduce EnforcementState, validate release of revocation secret #1039
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1039 +/- ##
==========================================
- Coverage 90.82% 90.80% -0.03%
==========================================
Files 65 65
Lines 32890 32917 +27
==========================================
+ Hits 29872 29889 +17
- Misses 3018 3028 +10
Continue to review full report at Codecov.
|
f7f300e to
3f1c6bb
Compare
3f1c6bb to
4525790
Compare
|
I'm a bit confused by the security model here is - its kinda cool to have the signer receive proof that the latest counterparty commitment transaction exists, but it presumably can't broadcast it by itself (mostly cause the signer doesn't have external network access). If a tree falls in the forest.... |
|
If the node is compromised, but the signer is intact, then the signer can be attached to a clean machine. The clean machine would have software that can broadcast the saved holder transaction. This would be a disaster recovery scenario. |
Yep, this.
Also this. I'm fine with this as a reasonable belt-and-suspenders, even if its not exactly within the trust model we have to assume. Sadly needs rebase cause of large things landing for 0.0.100. |
4525790 to
f738350
Compare
|
Updated PR description to call out the policy checks this would support in the signer. Also rebased. |
To be clear, I assume we are talking about I don't think the watchtower helps for all attacks related to this - it just helps with breaches. If the signer doesn't implement these policies, and allows revocation of the only valid holder tx, then we can no longer force-close. If also the balance is mostly on our side, and the attacker controls the counterparty, then they can just withhold the funds indefinitely or ask for a ransom. So we have to ensure that we have a valid holder tx at all times. And we have to connect the signer to a clean fallback node, or have a high-availability signer setup and publish that holder tx to mitigate this scenario. |
7698988 to
e7ab8c8
Compare
valentinewallace
left a comment
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 have a few questions/suggestions but basically ACK
f74bb3a to
f1b556a
Compare
valentinewallace
left a comment
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.
LGTM given Matt's brief that EnforcingSigner is pretty much just for testing
TheBlueMatt
left a comment
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.
A few easy fixes but I think this is good.
| fn validate_holder_commitment(&self, holder_tx: &HolderCommitmentTransaction) { | ||
| let mut state = self.state.lock().unwrap(); | ||
| let idx = holder_tx.commitment_number(); | ||
| assert!(idx == state.last_holder_commitment || idx == state.last_holder_commitment - 1, "expecting to validate the current or next holder commitment - trying {}, current {}", idx, state.last_holder_commitment); |
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.
You can drop the == check and only keep the -1 check here (and make it an assert_eq!()).
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.
In general, it seems advisable to allow replay of the last action, in case the signer is remote and the connection dropped during the call. However, could remove it here if we don't really care about illustrating that considering that this is mostly for internal tests.
e1e69e0 to
ba96aa8
Compare
lightning/src/ln/channel.rs
Outdated
| self.holder_signer.validate_counterparty_revocation( | ||
| self.cur_counterparty_commitment_transaction_number + 1, | ||
| &secret | ||
| ).map_err(|_| ChannelError::Close("Failed to validate your revocation".to_owned()))?; |
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.
s/your/counterparty
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'm not sure about this one. This is a message we are sending to the counterparty, so wouldn't it be confusing to them that we are referring to them as "counterparty" instead of "you"?
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.
Actually, elsewhere the term "Peer" is used, so I'll use that.
as we add more enforcement state variables, we want to keep track of them under a single structure
152d8a6 to
608ed12
Compare
This helps the signer implement the following policies (from https://gitlab.com/lightning-signer/docs/-/blob/master/policy-controls.md)
policy-v2-revoke-new-commitment-signedandpolicy-v2-revoke-new-commitment-valid)policy-v2-commitment-previous-revoked)