Skip to content
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

Output script descriptors #1

Closed
shesek opened this issue May 18, 2020 · 4 comments
Closed

Output script descriptors #1

shesek opened this issue May 18, 2020 · 4 comments
Labels
enhancement New feature or request
Milestone

Comments

@shesek
Copy link
Collaborator

shesek commented May 18, 2020

No description provided.

@shesek shesek added the enhancement New feature or request label May 18, 2020
@justinmoon
Copy link

justinmoon commented Jun 1, 2020

bwt seems to use xpubs to represent a range of outputs (conceptually the same thing as a a ranged descriptor), and HD origin fingerprints as public identifiers for these output ranges. When trying to integrate descriptors, the problem is that HD fingerprints only map to a subset of ranged descriptors. Perhaps descriptor checksums could serve this same purpose for wallets anchored to a ranged descriptor instead of an xpub?

You are currently marking every exported address with a {origin}/{index} label. You could switch this to {ranged_descriptor_checksum}/{ranged_descriptor_index}.

You could call importmulti with a (non-ranged) descriptor argument instead of the current address argument. Just replace every * in ranged descriptor with an index. Using a non-ranged descriptor allows you to bypass this issue. In light of #2, it's a potentially superior address import method because origin information contained inside the descriptor can be included in PSBTs generated with walletcreatefundedpsbt (just set bip32derivs to true in walletcreatefundedpsbt call).

I've only spent a few hours looking at bwt so I could be totally wrong, but it seems like this approach would be strictly more capable than the current xpub-based approach.

Note: @afilini has published Rust implementations of descriptor checksums and ranged descriptors which may be useful here.

@shesek
Copy link
Collaborator Author

shesek commented Jun 1, 2020

Making the xpub/extkey a specialized case of descriptors and replacing the key fingerprint with a descriptor fingerprint is what I had in mind for supporting descriptors. The descriptors would be how things are implemented under the hood, with some conveniences for users that prefer to think in terms of xpub wallets.

(So users could specify an [xyz]pub and have it converted to a descriptor, and possibly also keep a map around for converting extkey_fingerprint -> descriptor_fingerprint to maintain compatibility with the current key-fingerprint-based endpoints, such that /hd/:fingerprint/:index would still work but internally delegate to the matching descriptor.)

You could call importmulti with a (non-ranged) descriptor argument

You're right that using non-ranged descriptor imports with a label would give best of both worlds - bwt will have its label for quick access, and bitcoind will have its descriptor/origin information for PSBT.

I've only spent a few hours looking at bwt so I could be totally wrong, but it seems like this approach would be strictly more capable than the current xpub-based approach.

You're absolutely correct; I just didn't get around to that yet. :-)

Note: @afilini has published Rust implementations of descriptor checksums and ranged descriptors which may be useful here.

That's pretty useful, thanks for the links!

@shesek
Copy link
Collaborator Author

shesek commented Nov 1, 2020

Descriptor-based tracking is nearly ready on the 202010-descriptor branch.

This is how the new API looks like: https://gist.github.com/shesek/bf357a55c968635d34adfd171d0c65b1

@shesek
Copy link
Collaborator Author

shesek commented Nov 1, 2020

Merged to master! The bulk of the changes are in d305ec9, with a bunch of followup enhancement commits.

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

No branches or pull requests

2 participants