-
Notifications
You must be signed in to change notification settings - Fork 168
Define a new type for derived DescriptorPublicKeys
#345
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
Define a new type for derived DescriptorPublicKeys
#345
Conversation
9f888ec to
878c000
Compare
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.
concept ACK. I think we need to also revisit the APIs in impl Descriptor<DescriptorPublicKey> in descriptor/mod.rs to use this type.
src/descriptor/key.rs
Outdated
|
|
||
| impl<'secp, C: Verification> ToPublicKey for DerivedDescriptorKey<'secp, C> { | ||
| fn to_public_key(&self) -> bitcoin::PublicKey { | ||
| self.key.derive_public_key(&self.secp).unwrap() |
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.
Let us not derive ToPublicKey at all. Users can also use the
rust-miniscript/src/descriptor/mod.rs
Line 684 in d8cc633
| pub fn derived_descriptor<C: secp256k1::Verification>( |
translate_pk2 APIs.
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.
derived_descriptor() is only available on Descriptor<DescriptorPublicKey>, so if I did a first derive() and now I have a Descriptor<DerivedDescriptorKey> then I can't use this directly and I have to go back to the "un-derived" descriptor.
Should I implement something similar for Descriptor<DerivedDescriptorKey>? Ideally with a different name, otherwise it can get confusing. Something that internally translates the keys
Indeed this is super useful. After we have private key derivations, we can add support for this. But for now, this would have to do. Also, creating new verification contexts is now cheap(not exactly free still takes 50 micros seconds) as these contexts are now static in the underlying secp library. We are waiting on some cleanups from upstream secp after which creating verification contexts would be free! |
src/descriptor/key.rs
Outdated
| /// A derived [`DescriptorPublicKey`] | ||
| /// | ||
| /// Derived keys are guaranteed to never contain wildcards | ||
| pub struct DerivedDescriptorKey<'secp, C: 'secp + Verification> { |
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 think a much better name here would be DefiniteDescriptorKey. "Derivation" is the process of going from an extended key to a child key not from going from a key with wildcards to a key at a particular index of a wildcard.
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 am not thrilled with either names, but can't come up with a better name myself. I don't have any preference between both options, both are not ideal.
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 think definite vs indefinite is the correct way of distinguishing between this property linguistically. For example in English it shows up as:
- Definite: I'm taking my cat to the vet
- Indefinite: I'm taking a cat to the vet (we don't know which cat)
In miniscript you have:
- Definite: A descriptor where all derivation indexes are known
- Indefinite: A descriptor that could be instantiated at a particular index (like "a cat" could be instantiated with any particular cat but "my cat" could not).
It might be useful to apply this naming logic to other parts of the code. There is a function named derive that doesn't actually derive but just sets the derivation index. Then there is a function that actually does derivation called derive_public_key.
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 was confused by the current function naming you describe recently, +1 for 'definite'.
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 think renaming derive to set_derivation_index would probably be better than make_definite or something. But I do think definite and indefinite in the type names make sense.
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.
Maybe Concrete/Abstract?
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'll let you guys discuss this, let me know when you've settled with one and I'll update my PR.
I personally don't have any preference.
e37a3cb to
90c1cdd
Compare
|
Addressed most comments |
90c1cdd to
e619be4
Compare
|
Needs rebase, and does not compile currently I think because of rust-bitcoin updates. but ACK e619be4 -- this is much smaller/cleaner than I feared. |
cbf5403 to
28615fd
Compare
|
Rebased and fixed everything! |
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!
ACK 28615fd
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 28615fd
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 28615fd. Was going to merge this, but this would need to be rebased because of conflicts.
Might be good to address the nit as well
src/descriptor/key.rs
Outdated
| } | ||
|
|
||
| /// Return the derivation index of this key | ||
| pub fn get_index(&self) -> u32 { |
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.
nit: We usually don't use the get prefix for accessor methods.
28615fd to
9cf065b
Compare
|
Rebased and fixed your last nit! |
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 9cf065b
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 9cf065b
2ad6555 Rename "derive" things that are not doing derivation (LLFourn) 6dc6aca Make DerivedDescriptorKey first-class citizen (LLFourn) Pull request description: This PR further develops the idea introduced in #345. It has two commits both with relatively detailed commit messages that can be reviewed separately. In summary: 1. Develop the `DerivedDescriptorKey` (a key that is guaranteed not to have wildcard in it) idea more by adding missing functionality and refining the API. In addition, I removed the error cases from `ConversionError` which seems to have been omitted from #345. 2. Since the introduction of `DerivedDescriptorKey`, the overlapping usage of the term "derive" has become quite confusing. In addition to the usual definition of "derive" we have also used it to mean "replace a wildcard with a particular derivation index". I deprecated and renamed everything that uses the latter definition. ACKs for top commit: apoelstra: ACK 2ad6555 sanket1729: ACK 2ad6555. Thanks for the clean changes. Tree-SHA512: 0198404a1bfecab2324a8785117248fc566cfbb53decbd234928e378f102bdc5c5de6d31b437b8f1b0ba90ef524a362a46150028f80a4b029589406233abd2fe
… `DescriptorPublicKey`s
9cf065b7fafc41a0681374df8aa83baf0b9d3425 Define a new type for derived `DescriptorPublicKey`s (Alekos Filini)
Pull request description:
After a brief chat on IRC and in PR #339, here's a quick draft for a new type specific to derived `DescriptorPublicKey`s.
This is the same design we use in BDK, where we wrap a normal `DescriptorPublicKey` and a secp context in a new struct. This has the drawback that the struct carries a lifetime and generic for the ctx, but I couldn't think of any other way to get this to work unless we drop the implementation of `ToPublicKey` for `DerivedDescriptorKey` which in my opinion can be very useful.
ACKs for top commit:
apoelstra:
ACK 9cf065b7fafc41a0681374df8aa83baf0b9d3425
sanket1729:
ACK 9cf065b7fafc41a0681374df8aa83baf0b9d3425
Tree-SHA512: 3dd486d52c589d104da9611c65229988825cc79115a1ff45d1a39aa63e49d2d2a76b40b21a278a58d0b8566b2b37682ffc5efbbb78779ef4e5dadeaf14bbcc6c
After a brief chat on IRC and in PR #339, here's a quick draft for a new type specific to derived
DescriptorPublicKeys.This is the same design we use in BDK, where we wrap a normal
DescriptorPublicKeyand a secp context in a new struct. This has the drawback that the struct carries a lifetime and generic for the ctx, but I couldn't think of any other way to get this to work unless we drop the implementation ofToPublicKeyforDerivedDescriptorKeywhich in my opinion can be very useful.