Make payment_key derivation deterministic
#3391
Open
+127
−111
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tnull
force-pushed
the
2024-09-deterministic-payment-point
branch
10 times, most recently
from
b8c5f77
to
5b17762
Compare
... which we haven't been using since 0.0.119 / commit 7a951b1.
.. as it doesn't use the actual signer's `payment_key`, but the associated public key.
.. to make the name more clear and since before we `clone` it in `derive_channel_keys` anyways.
.. to align the field everywhere.
.. to align the field naming with the spec for clarity.
Previously, `KeysManager::derive_channel_keys` would derive the channel's `payment_key` uniquely on a per-channel basis which would disallow users losing their `channel_keys_id` to recover funds. As it's no real necessity to have `payment_key` derivation depend on `channel_keys_id` we can allow for easier recovery of any non-HTLC encumbered funds if we make `payment_key` derivation deterministic. To this end, we use the first byte of `channel_keys_id` as a versioning byte indicating the version of the used channel keys derivation scheme. Note that Previously `KeysManager::generate_channel_keys_id` would with very high likelyhood never have generated a `channel_keys_id` with a non-null first byte, which makes this a backwards-compatible change for any users that didn't run custom implementations of `SignerProvider::generate_channel_keys_id` conflicting with this assumption.
Some test cases have hard-coded values which we change here (to be squashed in after review).
tnull
force-pushed
the
2024-09-deterministic-payment-point
branch
from
5b17762
to
a7db955
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously,
KeysManager::derive_channel_keyswould derive the channel'spayment_keyuniquely on a per-channel basis which would disallow users losing theirchannel_keys_idto recover funds. As there is no necessity to havepayment_keyderivation depend onchannel_keys_idwe can allow for easier recovery of any non-HTLC encumbered funds if we makepayment_keyderivation deterministic.Here we do just this but also include a larger refactor introducing aChannelKeysDerivationParametersstruct holding a versioning field to be able to express this change in the derivation scheme. To this end we ensure that legacy channels will continue to use the old derivation scheme after upgrade, while new channels will derive thepayment_keydeterministicly.
To this end, we use the first byte of
channel_keys_idas a versioning byte indicating the version of the used channel keys derivation scheme. Note that PreviouslyKeysManager::generate_channel_keys_idwould withvery high likelyhood never have generated a
channel_keys_idwith a non-null first byte, which makes this a backwards-compatible change for any users that didn't run custom implementations ofSignerProvider::generate_channel_keys_idconflicting with this assumption.Apart from this, we add some refactoring commits that drop unused logic (
WriteableforInMemorySigner) and rename fields to align them with the BOLTs for clarity.We previously also discussed abusing the first byte of
channel_keys_idas a version byte, which wouldn't require the overhead of introducingChannelKeysDerivationParametersand serializing thechannel_keys_derivation_versionfield independently everywhere. However, as discussed I now chose to go with the latter approach as it seems cleaner and more future-proof.That said, looking for an approach ACK here before continuing. Will be draft until then.
TODO:
ChannelKeyDerivationParametersargument toget_shutdown_scriptpubkey, just as for the destination case. (cc @alecchendev)