wallet: add codex32 argument to addhdkey

roconnor-blockstream commented at 10:05 pm on May 30, 2025: contributor

WIP

This PR introduces the ability to import BIP 93/codex32 master seeds with the addhdkey command. It currently expects seeds to be provided in either as a single seed or as a list of shares which can be assembled via Shamir Secret Sharing.

descriptor: Add unused(KEY) descriptor

unused() descriptors do not have scriptPubKeys. Instead, the wallet uses
them to store keys without having any scripts to watch for.

10b677530e

test: Simple test for importing unused(KEY) 92849bdd9b

DrahtBot commented at 10:06 pm on May 30, 2025: contributor

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/32652.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept ACK	achow101

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#bitcoin-core/gui/872 (Menu action to export a watchonly wallet by achow101)
#33392 (wallet, rpc: add UTXO set check and incremental rescan to importdescriptors by musaHaruna)
#33135 (wallet: warn against accidental unsafe older() import by Sjors)
#33008 (wallet: support bip388 policy with external signer by Sjors)
#32861 (Have createwalletdescriptor auto-detect an unused(KEY) by Sjors)
#32489 (wallet: Add exportwatchonlywallet RPC to export a watchonly version of a wallet by achow101)
#30243 (descriptors: taproot partial descriptors by Eunovo)
#29136 (wallet: addhdkey RPC to add just keys to wallets via new unused(KEY) descriptor by achow101)
#28690 (build: Introduce internal kernel library by TheCharlatan)
#28333 (wallet: Construct ScriptPubKeyMans with all data rather than loaded progressively by achow101)

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 typos and grammar issues:

In codex32.cpp comment: residue (“secretshare32” or “secretshare32ex”. → residue (“secretshare32” or “secretshare32ex”) [missing closing parenthesis]

drahtbot_id_4_m

DrahtBot added the label Wallet on May 30, 2025

DrahtBot added the label CI failed on May 30, 2025

DrahtBot commented at 10:38 pm on May 30, 2025: contributor

🚧 At least one of the CI tasks failed. Task previous releases, depends DEBUG: https://github.com/bitcoin/bitcoin/runs/43216931922 LLM reason (✨ experimental): The CI failure is due to a compilation error caused by an invalid use of dynamic_cast on a non-pointer type.

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.
A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.
An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

wallet: Add addhdkey RPC 0d24f0af7a

wallet, rpc: Disallow import of unused() if key already exists cba3bcb6a7

wallet, rpc: Disallow importing unused() to wallets without privkeys 6100108594

achow101 commented at 8:48 pm on June 2, 2025: member

Concept ACK-ish

This is certainly better than the previous approach.

roconnor-blockstream force-pushed on Jun 24, 2025

Hack importdescriptors to look for private keys in the wallet dd83a96906

bech32: expose the character conversion functionality

In the next commit we will implement a new checksum, codex32, which uses
the same encoding and HRP rules as bech32 and bech32m, but has a
substantially different checksum verification procedure. To minimize
duplicated code, we expose the character conversion in a new
bech32::internals module.

1ecd034940

roconnor-blockstream force-pushed on Jul 4, 2025

codex32: implement encoding and decoding 5d504cb11b

codex32: introduce Lagrange interpolation and derived shares 139e8c15c1

codex32: provide user-readable error types 59777ef8dc

roconnor-blockstream force-pushed on Jul 5, 2025

maflcko removed the label CI failed on Sep 26, 2025

achow101 closed this on Oct 22, 2025

roconnor-blockstream commented at 3:34 pm on October 22, 2025: contributor

Can you elaborate?

achow101 commented at 4:11 pm on October 22, 2025: member

I suppose NACK is a bit too strong.

While codex32 itself is interesting, it is not interesting enough that any contributors to this project is interested in reviewing PRs including it.

Sjors commented at 10:06 am on October 24, 2025: member

I still haven’t gotten around to trying the paper booklet instructions. If and when I do that, I’ll probably review this. But no idea when that is.

BenWestgate commented at 1:21 pm on October 24, 2025: contributor

I still haven’t gotten around to trying the paper booklet instructions. If and when I do that, I’ll probably review this. But no idea when that is.

From BIP-0093:

…hand computation is optional, … and implementers do not need to be concerned with this possibility.

To encode some codex32 strings to import without the paper booklet there are libraries in Rust, Ruby and Python.

kiwihodl commented at 4:42 pm on January 27, 2026: none

@achow101 if there is renewed interest in testing these PR’s will you reopen it?

kiwihodl commented at 4:45 pm on January 27, 2026: none

I still haven’t gotten around to trying the paper booklet instructions. If and when I do that, I’ll probably review this. But no idea when that is. @Sjors if I sent you some metal codedx32 (currently awaiting to laser engrave them), would that make it easier for you to test? Don’t have to fluff about with cutting it out or piecing it together.

https://x.com/bitcoinbutlers/status/2013997324050084325

achow101 commented at 6:26 pm on January 27, 2026: member

@achow101 if there is renewed interest in testing these PR’s will you reopen it?

There needs to be interest to review the PR, not just test it. Further, current contributors must also be interested. AFAICT there is no interest from current contributors in reviewing this PR.

kiwihodl commented at 6:53 pm on January 27, 2026: none

@achow101 I appreciate the clarification. Looking at the history:

PR #27351 received Concept ACKs from @josibake, @S3RK, and you yourself gave a “Concept ACK-ish” on this PR (#32652), noting it was “better than the previous approach.” @BenWestgate is also an active contributor who’s engaged with codex32 work.

What would it take specifically to move this forward? Is the blocker:

1.	Code review bandwidth from existing contributors?
2.	Architectural concerns with the approach?
3.	Something else?

If it’s review bandwidth, I’d be happy to help coordinate interest from the codex32 community. There are real users waiting for this. I’m building metal backup products specifically for codex32 and currently the only wallet support is Bails/Bitcoin Knots.

in src/codex32.h:104 in 59777ef8dc

 99+        // Note that `ConvertBits` returns a bool indicating whether or not nonzero bits
100+        // were discarded. In BIP 93, we discard bits regardless of whether they are 0,
101+        // so this is not an error and does not need to be checked.
102+        ConvertBits<5, 8, false>([&](unsigned char c) { ret.push_back(c); }, m_data.begin() + 6, m_data.end());
103+        return ret;
104+    };

BenWestgate commented at 7:23 pm on January 27, 2026:

We’ve noticed that accessing the binary payload for non-“s” strings is 1) useless, 2) can’t round trip back to a share without passing the padding, 3) isn’t enough information to recover the secret unambiguously.

We don’t define how to decode shares to bytes in BIP93 so unless we do, perhaps gate this for “s” only.

achow101 commented at 6:08 pm on January 28, 2026: member

PR #27351 received Concept ACKs from @josibake, @S3RK

My understanding is that they are currently unable to dedicate time to the project in general.

Furthermore, just because something has Concept ACKs does not mean that it has reviewer buy in. If those Concept ACKs don’t convert into actual code review after some time, that indicates that while the Concept ACKer was interested, they weren’t interested enough to put in the work to actually review the PR.

and you yourself gave a “Concept ACK-ish” on this PR (#32652), noting it was “better than the previous approach.”

Which was effectively rescinded by my closure of this PR. I also refer to my previous point - I thought this was interesting, but it is not interesting enough to put review effort into it.

@BenWestgate is also an active contributor who’s engaged with codex32 work.

They are still new to the Bitcoin Core project and are not yet a regular contributor.

Code review bandwidth from existing contributors?

Primarily this. Actual code review may lead to concerns with the approach, but no one has actually done that yet.

If it’s review bandwidth, I’d be happy to help coordinate interest from the codex32 community.

We generally are not interested in a PR that is reviewed solely by people new to Bitcoin Core. Such reviews are not very valuable as there are many intricacies of this codebase which are difficult to understand. New reviewers will have not yet demonstrated competency or knowledge of this codebase, and as such their reviews are given less weight than a regular contributor.

wallet: add codex32 argument to addhdkey #32652

Code Coverage & Benchmarks

Reviews

Conflicts

LLM Linter (✨ experimental)