Add Taproot feature selector to wallet selection

[devdavidejesus]

Closes #4773

Adds a taproot feature selector so users can filter wallets by Taproot (bc1p) support, alongside the existing bech32 and legacy_addresses address-format selectors, and tags every currently-listed wallet whose Taproot support is verified.

What this does

Taproot wallets use bc1p addresses (bech32m encoding), distinct from the bc1q (bech32) addresses already covered by the bech32 selector. This adds the selector across the wizard, the sidebar, and the feature documentation, and applies the taproot tag to the wallets that support sending and receiving Taproot.

Changes

• Wizard step (helper-step-4.html): adds the Taproot checkbox.
• Wallet selector sidebar (wallets-selector.html): adds the Taproot checkbox with tooltip.
• Strings (en.yml): adds wizard-feature-taproot and wizard-feature-taproot-description.
• Documentation (managing-wallets.md): adds the taproot token, its description, and the qualification criterion. Per the output-type vs address-type distinction, the feature is named "Taproot" while the criterion refers to the Bech32m address format.
• Wallet tags: taproot added to the 20 listed wallets with verified support (see verification comment below).

Verification method

Each wallet's Taproot support was checked directly against the project's own source — P2TR receive-address generation and Schnorr/BIP-340 signing — rather than relying on release notes or third-party trackers (which proved inaccurate in several cases). Wallets that recognize/​send-to bc1p but cannot generate or sign their own Taproot (e.g. Coldcard stable, Electrum software-only, KeepKey) were deliberately left untagged. Full per-wallet evidence is in the comment below.

Wallets tagged

• Software: Sparrow, Wasabi, Bitcoin Safe, Ginger, Green, Mycelium, Unstoppable
• Signing devices: Passport, BitBox, Jade, SeedSigner, Krux, OneKey, Cypherock
• Full nodes: Bitcoin Core, Bitcoin Knots, Specter
• Currently listed, removal pending (Remove discontinued Trezor One and Trezor Model T #4664/Remove discontinued Ledger Nano S #4665): Trezor One, Trezor Model T, Ledger Nano S

Notes

• Feature/address-format wording (Taproot vs Bech32m) and the "Bitcoin" capitalization were refined following review by @crwatkins.
• Full nodes were included after discussion with @crwatkins (they already carry bech32; tagging taproot is consistent).
• en.yml (English) only; other locale strings to follow via the usual translation workflow.

cc @crwatkins

[crwatkins]

I would recommend that the Taproot description be more consistent with the other wizard descriptions, in particular SegWit, for consistency reasons. For example:

wizard-feature-taproot-description: "Some wallets support Taproot, which can increase privacy and use block chain space more efficiently for complex transactions such as multisig. Some bitcoin wallets and services do not yet support sending or receiving to the Bech32m addresses (which begin with 'bc1p') which Taproot uses."

[devdavidejesus]

I would recommend that the Taproot description be more consistent with the other wizard descriptions, in particular SegWit, for consistency reasons. For example:

wizard-feature-taproot-description: "Some wallets support Taproot, which can increase privacy and use block chain space more efficiently for complex transactions such as multisig. Some bitcoin wallets and services do not yet support sending or receiving to the Bech32m addresses (which begin with 'bc1p') which Taproot uses."

Good call...consistency with the SegWit/Bech32 descriptions makes sense. Updated to match your wording. Thanks.

[devdavidejesus]

Thanks Craig. These changes come out of our email exchange about whether "Taproot" or "Bech32m" is the right term when describing the address format, and whether full nodes (Core, Knots, Specter) should carry the feature.

Summary of what we landed on, for the record:

• The feature stays named "Taproot" (users identify with it more than "bech32m", and it distinguishes Taproot from future output types that may also use bech32m).
• When the text refers to the address format specifically, it should say Bech32m, since Taproot is an output type, not an address type.

Applied here:

1. The "To qualify…" criterion now says "send and receive Bech32m (bc1p) format addresses" instead of Taproot.
2. The feature description is reworded closer to the selector tooltip (privacy, efficiency, scripting flexibility, Schnorr), keeping the bech32m reference the criterion relies on.
3. Dropped the "bech32 doesn't imply Taproot" sentence.

[crwatkins]

There was a typo in my suggestion above. Bitcoin should have been capitalized. I had copied that from the SegWit description, so you might want to fix that also.

[devdavidejesus]

There was a typo in my suggestion above. Bitcoin should have been capitalized. I had copied that from the SegWit description, so you might want to fix that also.

Done....capitalized "Bitcoin" in that sentence. Since it came from the bech32 description, I fixed it in both the bech32 and taproot descriptions (in managing-wallets.md and en.yml), so they stay consistent.

[crwatkins]

utACK. Shall we hold off merging until we add the other currently listed wallets that support Taproot to this PR?

[devdavidejesus]

utACK. Shall we hold off merging until we add the other currently listed wallets that support Taproot to this PR?

Thanks! On holding off to add the others, I'd actually lean toward merging this one as-is (selector + Sparrow) and adding the remaining wallets in follow-up PRs, for a couple of reasons:

Reviewability: I've verified Taproot support for ~16 more wallets by checking each project's source directly (P2TR receive + Schnorr signing), and a few overturned what the release notes claimed. Batching them in small per-type PRs (software / signing devices / full nodes) keeps each set easy to review and verify, rather than one large diff.

So my suggestion: merge this as the infrastructure + one verified wallet, then I open the attribution PRs right after (I already have the per-wallet source evidence ready).

Either way, none of the follow-ups can land until this one creates the taproot token, so merging this first unblocks the rest.

[crwatkins]

It doesn't seem wise to me to merge this before the evaluation of the other wallets is ready. That would be publishing information that implies that Bitcoin Core (along with a number of other wallets) don't support Taproot when in fact they do. I don't see any compelling reason to rush this.

[devdavidejesus]

Added the taproot tag to all currently-listed wallets I could verify support Taproot. Each was checked directly against the project's own current source (P2TR receive-address generation + Schnorr/BIP-340 signing), not only release notes — in a few cases the source overturned what public notes implied.

Software wallets

• Wasabi — WalletWasabi/Blockchain/Keys/KeyManager.cs (BIP86/TaprootBIP86 account path), TransactionFactory.cs (P2TR), HdPubKey.cs (TaprootBIP86 scriptPubKey).
• Bitcoin Safe — bitcoin_safe/descriptors.py is_taproot → AddressTypes.p2tr; BDK signing.
• Ginger — fork of Wasabi; WalletWasabi/Blockchain/Keys/KeyManager.cs GetNextReceiveTaprootKey, Wallets/Wallet.cs GetNextReceiveAddress, Extensions/KeyManagerExtension.cs P2TR signature.
• Green — data/gdk/data/AccountType.kt BIP86_TAPROOT("p2tr"), enabled and offered in the account-type UI.
• Mycelium — bitlib/.../crypto/BipDerivationType.kt BIP86(86, P2TR); InMemoryPrivateKey.kt BIP341 tweak + SchnorrSign.
• Unstoppable — lib bitcoin-kit-android: SchnorrInputSigner.kt + TransactionSigner.kt (send); Bech32AddressConverter.kt BECH32M→Taproot (receive).

Signing devices

• Passport — ports/stm32/boards/Passport/modules/tasks/sign_psbt_task.py taproot_sign_key; own taproot.py module.
• BitBox — own Rust bitbox02-rust/src/hww/api/bitcoin.rs mod bip341; params.rs taproot_support: true (Bitcoin).
• Jade — own C main/wallet.c (P2TR variant, WALLY_SCRIPT_TYPE_P2TR, "segwit v1 p2tr keyspend").
• SeedSigner — models/psbt_parser.py script.p2tr(...) + taproot_bip32_derivations.
• Krux — psbt.py taproot_key_sig / taproot_sigs; key.py P2TR.
• OneKey — core/src/apps/bitcoin/sign_tx/bitcoin.py sign_taproot_input + SPENDTAPROOT (production, not just tests).
• Cypherock — apps/btc_family/btc_txn_helpers.c schnorrsig_sign32_taproot; btc_helpers.c taproot address.

Full nodes

These generate bech32m receive addresses and sign Taproot inputs; they already carry bech32, so tagging taproot is consistent (the address is generated via descriptor/RPC rather than a typical UI button).

• Bitcoin Core — src/wallet/scriptpubkeyman.cpp WITNESS_V1_TAPROOT; auto tr() descriptor since v23.0.
• Bitcoin Knots — fork of Core; same scriptpubkeyman.cpp WITNESS_V1_TAPROOT.
• Specter — util/psbt.py taproot_internal_key + taproot_bip32_derivations; wallet_importer.py descriptor.is_taproot.

Currently listed, removal pending (#4664 / #4665)

Tagging since they're still published and verifiably support Taproot; if the removal PRs land, the tags go with them.

• Trezor One — legacy/firmware/signing.c SPENDTAPROOT input + PAYTOTAPROOT output.
• Trezor Model T — core/src/apps/bitcoin/sign_tx/bitcoin.py sign_taproot_input + SPENDTAPROOT.
• Ledger Nano S — dedicated nanos branch of app-bitcoin-new: sign_psbt.c cx_ecschnorr BIP0340 + BIP-86 P2TR.

Not tagged — verified they do not qualify

Each was checked against its own source; they fail the send-and-receive criterion for different reasons:

• Coldcard / Coldcard Q — stable firmware recognizes and can receive to P2TR, but refuses to sign it: shared/psbt.py:780-781 raises FatalPSBTIssue("Install EDGE firmware to spend taproot."). Signing exists only in the Edge developer firmware. (Both share one firmware; the Q differs only in UI/keyboard.)
• Electrum — as a software wallet it can send to bc1p and parse tr() descriptors, but does not generate or sign its own Taproot: keystore.py:316 implements only p2pkh/p2wpkh/p2wpkh-p2sh txin types and derives p2wpkh (never p2tr); bitcoin.py:713 has only is_taproot_address (validation/send-to). It can drive a connected hardware wallet's Taproot — that's the device signing, not Electrum.
• KeepKey — recognizes P2TR but does not sign it: transaction.c:188-189 else if (script_type == InputScriptType_SPENDTAPROOT) { // we don't handle spendtaproot input types.
• Bither — no Taproot anywhere (grep for taproot/p2tr/bech32m/schnorr is empty); supports only up to native SegWit.
• Armory — no taproot/p2tr/bech32m/schnorr in the source; address types stop at SegWit.
• BitPay — no P2TR/bech32m/bip86. The only schnorr in the source is in the zce (Bitcoin Cash) provider, not Taproot.
• Edge — its engine recognizes P2TR, but Bitcoin is configured formats: ['bip49','bip84','bip44','bip32'] and bip86 appears nowhere in the source, so it cannot derive its own Taproot receive address.
• Phoenix — a Lightning wallet whose only Taproot use is swap-in (SwapInSignerView.kt, SwapAddressFormat.TAPROOT_ROTATE, MuSig2 with the ACINQ server); no on-chain custody of arbitrary bc1p.
• Bitcoin Wallet (Schildbach) — generates P2PKH/bech32 receive addresses (RequestCoinsFragment freshReceiveAddress); no taproot/p2tr/bech32m in the app.

All paths above were re-verified against current source.

[crwatkins]

Wow! Great. LGTM. (still utACK)