Skip to content

Conversation

@achow101
Copy link
Member

@achow101 achow101 commented Dec 22, 2023

It is sometimes useful for the wallet to have keys that it can sign with but are not (initially) involved in any scripts, e.g. for setting up a multisig. Ryanofsky suggested A unused(KEY) descriptor which allows for a key to be specified, but produces no scripts. These can be imported into the wallet, and subsequently retrieved with gethdkeys. Additionally, listdescriptors will output these descriptors so that they can be easily backed up.

In order to make it easier for people to add HD keys to their wallet, and to generate a new one if they want to rotate their descriptors, an addhdkey RPC is also added. Without arguments, it will generate a new HD key and add it to the wallet via a unused(KEY) descriptor. If provided a private key, it will construct the descriptor and add it to the wallet.

See also: #26728 (comment)

Based on #29130 as gethdkeys is useful for testing this.

@DrahtBot
Copy link
Contributor

DrahtBot commented Dec 22, 2023

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/29136.

Reviews

See the guideline for information on the review process.

Type Reviewers
Concept ACK fjahr
Stale ACK Sjors, rkrux

If your review is incorrectly listed, please copy-paste <!--meta-tag:bot-skip--> into the comment that the bot should ignore.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #33874 (wallet: refactor ProcessDescriptorImport by naiyoma)
  • #33008 (wallet: support bip388 policy with external signer by Sjors)
  • #32861 (Have createwalletdescriptor auto-detect an unused(KEY) by Sjors)
  • #32784 (wallet: derivehdkey RPC to get xpub at arbitrary path by Sjors)
  • #32489 (wallet: Add exportwatchonlywallet RPC to export a watchonly version of a wallet by achow101)
  • #31668 (Added rescan option for import descriptors by saikiran57)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

LLM Linter (✨ experimental)

Possible places where named args for integral literals may be used (e.g. func(x, /*named_arg=*/0) in C++, and func(x, named_arg=0) in Python):

  • Parse(desc_str, keys, error, false) in src/wallet/rpc/wallet.cpp
  • WalletDescriptor(std::move(descs.at(0)), GetTime(), 0, 0, 0) in src/wallet/rpc/wallet.cpp

2026-01-05

@ryanofsky
Copy link
Contributor

ryanofsky commented Dec 23, 2023

This is great, amazed you could implement this so quickly!

I was thinking about the void(KEY) idea more today, and think it would be good to make 3 tweaks:

1 - rename "void(KEY)" to "unused(KEY)"
2 - add logic to importdescriptors and generatewalletdescriptor to delete any unused(KEY) descriptor as soon as the KEY which it references is used by an new descriptor (taking into account both public and private parts of the key)
3 - add logic to importdescriptors to disallow importing an unused(KEY) if KEY is used by another descriptor.

I think these changes would help make these descriptors easier to understand and also enhance backwards compatibility, because IIUC wallets containing unknown descriptor types can't be opened by older software. Also keeping redundant descriptors in the wallet that were only temporarily needed is confusing.

If making these tweaks isn't possible or is not a good idea. I still think probably we should rename void(KEY) to data(KEY) or something like that. I think while "void" makes a certain amount of sense as programming jargon, it's not really a familiar term and doesn't describe the purpose of these descriptors, which is just to hold an inert piece of data, and not be used for generating or matching scriptpubkeys.

I also have a number of ideas to improve the RPC interface for generating keys and descriptors, and will try to post them soon. (EDIT: now posted #29130 (comment)). But this seems like a very good start and very functional.

@achow101
Copy link
Member Author

achow101 commented Jan 4, 2024

1 - rename "void(KEY)" to "unused(KEY)"
3 - add logic to importdescriptors to disallow importing an unused(KEY) if KEY is used by another descriptor.

Done these. I've also added a further restriction that unused() cannot be import to a wallet without private keys. It isn't useful in such wallets so I think it makes sense to disallow their import.

2 - add logic to importdescriptors and generatewalletdescriptor to delete any unused(KEY) descriptor as soon as the KEY which it references is used by an new descriptor (taking into account both public and private parts of the key)

Still working and thinking on this. However we've generally held to the policy of not deleting any records from the wallet since that could result in private keys being accidentally deleted. The only exception to that was adding encryption.

@ryanofsky
Copy link
Contributor

However we've generally held to the policy of not deleting any records from the wallet since that could result in private keys being accidentally deleted. The only exception to that was adding encryption.

Oh, I didn't know that but it makes sense.

One approach you could take would just be to delete the descriptor from memory without actually deleting it from the database, and ignore it the next time the wallet is loaded. But a drawback of this would be that once addhdkey was used the wallet would be forever incompatible with older versions of the software, when one of the benefits of deleting the descriptor was to make wallets backward compatible.

Another approach that might be acceptable could be to add a DatabaseBatch::MarkErased method to call instead of DatabaseBatch::Erase. This could just prepend a serialized string like const std::string TOMBSTONE{"tombstone"} to the key and otherwise leave the record unchanged.

Or maybe just decide in this case that it is ok to delete a record after verifying all the information it contains is present in other records.

Would also want to think about it more, though.

@achow101 achow101 force-pushed the sethdseed-void-descriptor branch 2 times, most recently from 8ee55e4 to 439734e Compare July 24, 2025 21:18
@Sjors
Copy link
Member

Sjors commented Jul 25, 2025

re-ACK 439734e

(you can drop "Based on" from the PR description)

@DrahtBot DrahtBot requested a review from rkrux July 25, 2025 07:07
Copy link
Contributor

@rkrux rkrux left a comment

Choose a reason for hiding this comment

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

ACK 439734e

Thanks for incorporating suggestions; TIL about the for-else pattern in Python.

git range-diff 6100108...439734e

if len(x["descriptors"]) == 1 and x["descriptors"][0]["desc"].startswith("unused("):
break
else:
assert False, "Did not find HD key with no descriptors"
Copy link
Contributor

Choose a reason for hiding this comment

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

In 71b4900 "wallet: Add addhdkey RPC"

Nit if retouched:

- assert False, "Did not find HD key with no descriptors"
+ assert False, "Did not find any HD key with unused descriptor" 

Comment on lines +2097 to +2516
for (auto& pubkey : keys) {
if (pubkey->IsRange()) {
error = "unused(): key cannot be ranged";
return {};
}
ret.emplace_back(std::make_unique<UnusedDescriptor>(std::move(pubkey)));
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Ah right! Fine to keep it as-is in the parsing flow.

Via addhdkey RPC though, I don't suppose there is a way to get multipath keys added? (as only one hdkey can be generated or imported)

@Sjors
Copy link
Member

Sjors commented Oct 16, 2025

Needs rebase.

@achow101
Copy link
Member Author

Needs rebase.

Doesn't seem like it does?

@Sjors
Copy link
Member

Sjors commented Nov 10, 2025

I guess not. Just tried a merge with current master, which builds fine and tests pass.

@Sjors
Copy link
Member

Sjors commented Jan 5, 2026

re-utACK 6928cad

Just a rebase.

@DrahtBot DrahtBot requested a review from rkrux January 5, 2026 03:21
Copy link
Contributor

@rkrux rkrux left a comment

Choose a reason for hiding this comment

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

re-ACK 6928cad

The range diff looks fine to me - there are few function moving changes here and there that are due to rebase I suppose.

git range-diff 439734e...6928cad

Copy link
Contributor

@fjahr fjahr left a comment

Choose a reason for hiding this comment

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

Concept ACK

Looks already pretty good to me.

@achow101 achow101 force-pushed the sethdseed-void-descriptor branch from 6928cad to 23f5529 Compare January 5, 2026 22:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants