-
Notifications
You must be signed in to change notification settings - Fork 2
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
hsmd: add explicit hsmd_revoke_commitment_tx #103
base: 2024-01-unilateral-close-info-anchors
Are you sure you want to change the base?
hsmd: add explicit hsmd_revoke_commitment_tx #103
Conversation
Changelog-Added: Added hsm_capabilities and hsm_is_capable to channeld.
ChangeLog-Added: Added hsmd_revoke_commitment_tx to protect against local commitment persistance synchronzation errors with remote signers.
@@ -1966,6 +1967,30 @@ static void send_revocation(struct peer *peer, | |||
|
|||
peer->splice_state->await_commitment_succcess = false; | |||
|
|||
/* Now that the master has persisted the new commitment advance the HSMD | |||
* and fetch the revocation secret for the old one. */ | |||
struct secret old_secret2; |
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.
consider removing these additional variables and just use old_secret
and next_point
everywhere below
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.
The problem is the originals are:
const struct secret *old_secret,
const struct pubkey *next_point,
looks good to me, just one nit |
if (HSM_MAX_VERSION < 5 || | ||
!hsm_is_capable(peer->hsm_capabilities, WIRE_HSMD_REVOKE_COMMITMENT_TX)) |
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.
Mh this is just a comment for a future improvement. Would be nice to have a method to avoid checking the version here, but with the current enum system for the hsm_capabilities
this seems hard
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.
not sure if we can hack around the hsmd_check_client_capabilities
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 just added some not relevant comments
Addresses https://gitlab.com/lightning-signer/validating-lightning-signer/-/issues/207
Advances
HSM_MAX_VERSION
to 5 and addshsmd_revoke_commitment_tx
.old_secret
from the return value ofhsmd_validate_commitment_tx
hsmd_revoke_commitment_tx
after master has syncd with validated local commitment tx to advance signer and receive theold_secret
Code is forward and backward compatible with signers that have or don't have the feature.
Setting
HSM_MAX_VERSION
manually to 4 will elicit the old behavior.