Independence-proof recovery is too technical for non-technical heirs (Sparrow can't open vaults; only Core/Liana do)

[Jolah1]

Problem

GhostKey vaults are Taproot timelock miniscript wallets: tr(NUMS, or_d(pk(owner), and_v(v:pk(heir), older(N)))).

The independence proof (the cornerstone non-custodial guarantee) originally told users to recover in Sparrow — but Sparrow has no miniscript support (sparrowwallet/sparrow#1700) and physically cannot import the descriptor. Fixed the wording in #83 to point at Bitcoin Core / Liana, but the underlying UX gap remains.

Why it matters

• The only guaranteed spend-recovery path is Bitcoin Core (importdescriptors with the xprv-bearing descriptor). That requires a synced/pruned node and the console — far beyond a "random farmer" heir (see farmer-friendly UX constraint).
• Liana is GUI and purpose-built for timelocked inheritance, but unverified end-to-end for our exact descriptor:
  • Does Liana import this arbitrary external descriptor (NUMS internal key, or_d/and_v/older structure), or only descriptors it generated?
  • The proof hands out an xprv, not a BIP39 mnemonic. Can Liana sign from a raw xprv, or does its hot signer require a seed phrase? If the latter, Liana can watch but not spend our vaults.

Asks

1. Verify Liana e2e on signet/testnet: import the watch-only descriptor (see balance) AND attempt a spend using the GhostKey xprv. Document exactly what works.
2. If Liana can't spend from the xprv, decide: (a) export a mnemonic-based path, (b) ship a guided Core recipe, or (c) build a minimal in-browser spend tool in the proof file itself (we already decrypt the xprv there).
3. Pick a recovery story a non-technical heir can follow without a full node.

Context

• Recovery wording fix: fix(web): proof recovery points at miniscript-aware wallets (not Sparrow) #83
• Found during mainnet dry-run, 2026-06-13.