Skip to content

Add function to check internal descriptor #528

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

Closed
wants to merge 1 commit into from

Conversation

w0xlt
Copy link
Contributor

@w0xlt w0xlt commented Jan 13, 2022

As discussed in #522 (comment) and suggested in #525 (comment), there is no way of knowing whether the descriptor returned in get_descriptor_for_keychain is external or internal.

According to the first comment, this is a deliberate decision. So this PR adds a new function to check if internal descriptor exists.

This information can be important when showing a list of addresses and indicating which descriptor the address comes from, for example.

Copy link
Contributor

@rajarshimaitra rajarshimaitra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though I am still unsure why would a lib user won't know if his wallet has a change_desc or not, but I think its no harm to explicitly have an API to determine that.

ACK 64acb93

@LLFourn
Copy link
Contributor

LLFourn commented Jan 25, 2022

@w0xlt we discussed about this in the meeting today. Can you give us an idea what you would use this for?

@@ -1059,6 +1059,11 @@ where
&self.secp
}

/// Checks if the wallet has internal descriptor
pub fn has_internal_descriptor(&self) -> bool {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think has_descriptor_for_keychain(&self, keychain: KeychainKind) would be better. I have in my mind to add other KeychainKinds later on and this would be helpful to that end.

@w0xlt
Copy link
Contributor Author

w0xlt commented Feb 10, 2022

Can you give us an idea what you would use this for?

Sure. This PR is related to how descriptors are implemented in the BDK. This behavior is described in #522 (review) and #522 (comment).

There is currently no way to retrieve internal (change) addresses.

With #522, this will be possible, but if there's no internal descriptor, get_internal_address will return the same addresses as get_address. That is, if there is no internal descriptor, there is still no way to know this.

This PR adds the ability to know if there is an internal descriptor and how to better process the results of get_internal_address.

The use case is: building an Electrum wallet using BDK. As the image below shows, it is necessary to distinguish between internal and external addresses.

image

@notmandatory
Copy link
Member

What if we add the KeychainKind to the AddressInfo struct returned by get_internal_address (and other functions that return AddressInfo) ? then there's be no need to do a has_internal_descriptor check and will help support other KeychainKind values going forward.

@w0xlt
Copy link
Contributor Author

w0xlt commented Feb 10, 2022

I agree.

I think there is no need for a new function (get_internal_address).
The current function get_address can receive the AddressIndex and the KeychainKind as parameters. And bdk::KeychainKind::External can be the default value for this new parameter.

This way, it maintains backwards compatibility and still adds this new functionality.

I also don't see a problem if the BDK throws an exception if the user requires a KeychainKind that doesn't exist. This would make it easier to distinguish the addresses.

@LLFourn
Copy link
Contributor

LLFourn commented Feb 11, 2022

It turns out we already have a method that gives you this anyway: Wallet::public_descriptor will return the descriptor for either keychain and None when there is no internal descriptor. What @notmandatory suggested seems like a reasonable improvement regardless.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants