Watch-only Wallet

Alice keeps her keys in a hardware wallet and wants to check a payment from her phone. She transfers the wallet’s public configuration to the phone, not her backup words. The app can then recognize the relevant addresses and find their payments on the network. Alice sees an incoming 20,000 sat, the smallest units of bitcoin, and its confirmations even though the signing device is switched off at home. The phone has not gained permission to spend it. A merchant can likewise give an accountant a view of payments without handing over the keys. What matters is what was actually imported: entering a Seed Phrase, the backup words that recover the keys, would remove that separation. [12]

You can add someone else’s public address to a watching app. A balance on screen therefore does not prove that its user can spend the money, let alone cover all their debts. The app adds up the UTXOs it finds: outputs of earlier payments that remain unspent. It can only find what matches the imported information and available history. Missing addresses, an unfinished scan or an unreliable server can leave that picture incomplete. A zero on screen does not by itself mean lost bitcoin; first check the scope of monitoring and the data source. [8] [9]

When Alice wants to pay, the watching app selects available UTXOs and prepares the recipient, amount and fee. It may return the unused portion of an input to her own wallet, called change. These details can travel in a PSBT, the Partially Signed Bitcoin Transaction format defined by BIP174. A separate device then has the information needed to sign without its own UTXO database. On that device’s trusted display, Alice must check the actual recipient, amount, fee and change. A compromised app could prepare a different payment from the one she intended. The sighash setting also matters: it determines which parts of the transaction the signature covers. Only after checking and signing should the final transaction, matching the approved proposal and wallet rules, be broadcast. [2] [10]

An extended public key, or xpub, derives further public keys in a particular wallet branch; it cannot sign a payment by itself. Someone who obtains it together with the wallet rules can nevertheless link reachable addresses, past and future payments, and balances. That reveals much more than one address for one payment. A third-party server can learn a similar picture from repeated app queries. Running your own Full Node, which verifies the blockchain itself, limits that disclosure; an encrypted or otherwise private connection does not hide queries from the destination server. Export only the account needed, limit copies, and protect labels that associate addresses with names or payment purposes. [1] [13] [14]

The following sections are technical references for setup and recovery. A script sets spending conditions; an Output Descriptor records those rules and the information needed to derive addresses. An HD Wallet builds a tree of keys from a seed: secret starting data used to derive those keys. Non-hardened derivation can generate further public keys from an xpub, whereas hardened derivation requires a private key. Multisig adds a specified number of required signatures. Importing one address watches exactly that script, not future receiving or change addresses. A public key covers different script types only if the software explicitly derives them. An account xpub derives non-hardened descendants but does not specify P2PKH, SegWit, Taproot, the internal branch or a Multisig signing threshold. A descriptor supplies this context. Export it from the right signer account with the correct network and script type; do not guess the derivation path, the sequence of steps from the starting key. [1] [4] [7]

HD wallets usually separate external receive addresses from internal change, often using /0/* and /1/*. Without the internal branch, funds can appear to disappear after spending. A small range, the span of derived addresses, can hide new receipts. next_index determines the next address to generate; a mismatch between two programs can cause address reuse. Keep active descriptors, ranges and indices aligned. Verify receiving addresses on the signer’s display: malware can substitute an address while showing a plausible balance. [6] [9]

Bitcoin Core’s importdescriptors uses timestamp to set the start of rescanning: “now” skips old history, while 0 requests a scan from genesis. The range and availability of old blocks also matter. The active setting determines whether the descriptor is used to generate new addresses; internal marks outputs within the wallet, such as change. A pruned node, which has deleted old blocks to save space, may lack the required history. Rescanning only discovers existing transactions. Record the first-use date or height and compare restoration with known addresses and transactions, not just a zero on the screen. [9] [10]

BIP380 describes a language for sets of output scripts. The illustrative expression wpkh([d34db33f/84h/0h/0h]xpub…/0/*)#checksum records the script type, master fingerprint, origin path, account public key, branch, variable index and checksum. It is not valid import data. Taproot uses tr() under BIP386; BIP389 supports multiple paths in one expression. The checksum detects transcription errors, not the author’s identity. A descriptor containing xprv holds a secret key and does not belong in a watching coordinator. [4] [5] [6] [7]

BIP32 describes a critical exception: a parent extended public key plus any descendant non-hardened private key allows recovery of the parent private key, provided the entire intervening path is non-hardened. The xpub alone is insufficient; this combination is dangerous. A hardened step above the exported account prevents the attack from crossing that boundary. Never put an xprv, seed or private keys into a watching wallet, its database or accompanying PSBT files. [1]

Multisig monitoring requires the threshold, script type, every cosigner xpub, key origins, key order and both address branches. One xpub is insufficient. Losing the descriptor can complicate recovery even with intact seeds; different ordering or script wrappers can produce different addresses. Verify the policy and a sample address on every signer. Back up a checksummed descriptor or standard configuration, remembering that it reveals relationships among cosigners. [4] [11]

Separately from private keys, retain both branch descriptors, key origins, network, creation date or height, ranges, indices, labels and Multisig rules. BIP329 transfers labels, not a replacement for descriptors or history. Test recovery in a separate profile or on a test network: import the public configuration, rescan, compare old addresses on both branches and expected UTXOs, prepare a PSBT and sign it with the designated device. Verify the result before broadcasting. Watch-only supports observation and preparation; it is not the ultimate source of spend authority. [3] [9] [12]