Skip to content

Add function to check internal descriptor#528

Closed
w0xlt wants to merge 1 commit intobitcoindevkit:masterfrom
w0xlt:has_internal_descriptor
Closed

Add function to check internal descriptor#528
w0xlt wants to merge 1 commit intobitcoindevkit:masterfrom
w0xlt:has_internal_descriptor

Conversation

@w0xlt
Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
Collaborator

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?

Comment thread src/wallet/mod.rs
}

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

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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
Collaborator

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