Add Taproot (P2TR / bc1p) address support

[jamespepper81]

Summary

Add full Taproot (P2TR — bc1p) address support to the wallet so users can generate receive addresses, send to Taproot addresses, and create and sign Taproot transactions.

Why

• Taproot improves privacy and efficiency (smaller scripts in many cases) and enables Schnorr signatures (BIP-340) which reduce tx size and fees.
• Many wallets and services are adopting Taproot; adding support keeps compatibility and provides cost savings for users.
• Future Taproot-based features (e.g., more compact multisig, advanced scripts) require this foundation.

Scope / Goals

• Generate Taproot receive addresses (native P2TR — bech32m, bc1p).
• Send to Taproot addresses (create, sign, and broadcast valid P2TR transactions).
• Sign Taproot inputs locally using Schnorr signatures (BIP-340).
• PSBT support for Taproot (PSBT v2 where needed) — creation, export/import, and signing flows.
• UI: show Taproot addresses clearly (example: “Receive — Taproot (bc1p...)”) and indicate when an address is Taproot.
• Testing: unit tests, integration tests, and end-to-end send/receive flows on testnet/regtest.

Acceptance criteria (done when all are met)

• Wallet can derive and display native P2TR addresses from user keys/xpubs (bech32m prefix).
• Signing workflow produces valid Schnorr signatures and transactions accepted by Bitcoin nodes (testnet).
• PSBT flows that include Taproot inputs/outputs can be exported, imported, and signed by the wallet.
• Transactions spending P2TR UTXOs are accepted and broadcast successfully (testnet).
• UI updates present Taproot addresses and explain compatibility implications.
• Automated tests exercising address generation, tx building, signing, and broadcast are added and pass in CI.
• Documentation updated (README / release notes) describing Taproot support and any migration notes for users.

Implementation notes / checklist

• Address derivation
  • Support BIP86 (single-key Taproot derivation) and/or standard derivation used by existing wallets. Decide whether to implement BIP86-only or support multiple Taproot derivation schemes; document choice.
  • Ensure xpub/derivation path handling for Taproot-compatible keypaths (m/86'/0'/... or custom).
• Libraries
  • Evaluate and adopt a bitcoin library with Taproot/Schnorr and PSBT v2 support for TypeScript/React Native (e.g., the latest bitcoinjs-lib if adequate, or use a wasm/rust library such as rust-bitcoin compiled to WASM if necessary).
• PSBT / Signing
  • Support PSBT v2 fields required for Taproot signing, or implement an internal signing flow compatible with PSBT v2 consumers.
  • Ensure Schnorr signing (BIP-340) and Taproot control block handling for script-path spends if needed.
• Transaction construction
  • Update coin selection/fee estimation logic for Taproot outputs (tx weight differences).
  • Update input/output script templates and witness handling for P2TR.
• Backward compatibility & migration
  • Existing wallets should continue to work; new Taproot addresses should not change legacy flows.
  • Document how imported xpubs behave and whether previously-generated xpubs can derive Taproot addresses.
• UI/UX
  • Add label/selector for address type on Receive screen and allow copying/displaying bc1p addresses.
  • Add user-facing note about Taproot compatibility (e.g., not all services may support Taproot yet).
• Security
  • All keys remain on-device; signing must continue to work with existing biometric flows.
  • Add tests ensuring private key material never leaves the secure enclave/keychain.
• Testing
  • Unit tests for address derivation and validation.
  • Integration tests to build, sign, and broadcast tx on testnet/regtest.
  • Add sample test vectors and known-good PSBTs for tests.
• CI
  • Ensure CI includes tests that validate Taproot flows (testnet/regtest or fixture-based).
• Documentation
  • Add docs for Taproot support, including derivation paths, compatibility, and troubleshooting.

Suggested labels

• enhancement
• bitcoin-protocol / protocol-bitcoin
• priority: medium (or choose high if you prefer)

Estimated effort

• Engineering estimate: ~5–10 developer days depending on choice of library and existing PSBT/signing infra.

Questions / decisions needed from maintainers

• Preferred derivation approach: BIP86-only or support multiple Taproot derivation variants?
• Library choice: prefer bitcoinjs-lib (JS) or rust-bitcoin + WASM?
• Priority and whether to gate behind a feature flag.