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: split revocation from validation #7010
hsmd: split revocation from validation #7010
Conversation
980ad99
to
0ba9192
Compare
0ba9192
to
846c3e0
Compare
channeld/channeld.c
Outdated
/* 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; | ||
struct pubkey next_point2; |
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.
this is not important for functionality, but this would be good to declare all of the top functions with all the parameters declaration
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.
ACK 846c3e0
Waiting just for the CI but LGMT
I think the comparisons should stay They are important for testing that version 5 signers work with version 4 CLN. |
This is needed if you want to test compatibility. You can set HSM_MAX_VERSION to 4 and the code will behave the old way even if a signer is capable. What would be really good is if we could set it differently w/o rebuilding for regression test passes ... |
if we want to test version 4 CLN, we should test with that version of the code, because we might have changed something that is not completely restored to the previous behavior via the |
The (redundant normally) comparisons allow a single line mod to force CLN to v4 despite any capabilities flag. This is useful tool for debugging in the future. I do "side-by-side" comparisons (before the feature, after the feature) a lot when debugging. I think it is really nice to be able to force downgrade the protocol simply, w/o changing everything else in the experiment (by using an old version of something) |
Added to milestone, if this is ready I can take over and shepherd it through CI :-) |
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.
Nice API improvement! Just minor cleanup advice, no significant flaws. Thanks!
common/hsm_capable.c
Outdated
|
||
/* Is this capability supported by the HSM? (So far, always a message | ||
* number) */ | ||
bool hsm_is_capable(u32 *capabilities, u32 msgtype) |
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.
Nitpick: const u32 *capabilities
.
lightningd/channel_control.c
Outdated
@@ -1631,6 +1631,9 @@ bool peer_start_channeld(struct channel *channel, | |||
initmsg = towire_channeld_init(tmpctx, | |||
chainparams, | |||
ld->our_features, | |||
/* Capabilities arg needs to be a tal array */ | |||
tal_dup_arr(tmpctx, u32, ld->hsm_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.
Weird... since you use tal_count
then ld->hsm_capabilities must be a tal array, so you shouldn't need to copy it?
channeld/channeld.c
Outdated
@@ -1923,6 +1925,7 @@ static void send_revocation(struct peer *peer, | |||
const struct failed_htlc **failed; | |||
struct added_htlc *added; | |||
const u8 *msg; | |||
const u8 *msg2; |
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.
We can just reuse msg
here, and don't need a new var I think.
channeld/channeld.c
Outdated
memcpy(&old_secret2, old_secret, sizeof(old_secret2)); | ||
memcpy(&next_point2, next_point, sizeof(next_point2)); |
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 always prefer assignment to memcpy, since it's typesafe (and compiler will do the same thing). old_secret2 = *old_secret;
and next_point2 = *next_point
.
Thanks for the feedback Rusty, I think as soon as it's been amended we can merge this PR, and close this racy behavior :-) Thanks @ksedgwic and @devrandom for finding and fixing it 👍 |
Changelog-Added: Added hsm_capabilities and hsm_is_capable to channeld.
ChangeLog-Added: Added hsmd_revoke_commitment_tx to ensure synchronization of local state with remote signers.
14a6870
to
d09b3a6
Compare
ready |
Changelog-None: fixes bug in ([ElementsProject#7010]) After HSM_VERSION 5 we explicitly revoke the commitment in case the original revoke didn't complete. The hsmd_revoke_commitment_tx call is idempotent.
Changelog-None: fixes hole in ([ElementsProject#7010]), see ([ElementsProject#7026]) Explicit hsmd_revoke_commitment_tx instead of get_per_commitment_point needed when revokes are retried. The hsmd_revoke_commitment_tx message is idempotent.
Changelog-None: fixes hole in ([ElementsProject#7010]), see ([ElementsProject#7026]) Explicit hsmd_revoke_commitment_tx instead of get_per_commitment_point needed when revokes are retried. The hsmd_revoke_commitment_tx message is idempotent.
In https://gitlab.com/lightning-signer/validating-lightning-signer/-/issues/207 we discovered that it's possible for CLN to validate a holder commitment
N
, but then forget that it did so and try to use revoked commitmentN-1
. A validating signer cannot allow that, since it can result in funds loss in general.This splits the two calls so that the action can be persisted after the validation and before the revocation.