When a wallet is imported via extended public key, blockd derives a bounded set of addresses from the xpub and monitors their corresponding script hashes for activity. This page covers the privacy and security implications of that model.

For the mechanics of xpub import — key encoding, scanspec variants, and how derived addresses relate to script types — see Wallets & ScriptPubKeys.

What blockd stores

blockd does not persist extended public keys. During import, blockd derives the address set according to the scanspec — up to the gap limit, or an explicit count or range — then stores the resulting addresses and script hashes in RocksDB. The xpub itself is never written to disk.

This bounds the privacy exposure in two ways. First, only the addresses actually derived are stored — addresses beyond the scanspec boundary are never generated and never recorded. A wallet imported with a gap limit of 20 exposes only those derived addresses, not the entire future derivation path. Second, deletion is complete — when a pubkeys_set is deleted, every record associated with it is removed. Nothing lingers in the database or on disk.

Privacy implications

The primary privacy concern with xpub-derived addresses is linkage. All addresses derived from the same extended public key are cryptographically connected. If any single address becomes associated with an identity — through exchange KYC, public donation addresses, or blockchain analysis — every other address in that derivation path is linked as well.

blockd consolidates this information by design. Transaction queries for a pubkeys_set return a unified view across all derived addresses. This consolidated view is what makes blockd useful for wallet tracking, balance computation, and UTXO management. It is also what creates privacy exposure: any party with API access and a pubkeys_set name has visibility into the complete transaction history and balance for that address set.

LAN deployment model

The typical blockd deployment runs within a private LAN — bitcoind, Fulcrum, and blockd co-located on a node, with desktop or mobile applications connecting over the local network. In this model, privacy concerns are primarily about data persistence and credential management within a controlled network perimeter.

Applications connecting to blockd over the LAN require API credentials. Those credentials grant access to query any pubkeys_set the application knows the name of. For applications that query wallet data periodically without requiring ongoing monitoring, the recommended pattern is to import, query, and immediately delete the pubkeys_set. See ScriptPubKeys Set Lifecycle for the correct deletion sequence.

SSL termination via reverse proxy or Tor hidden service is recommended for any deployment where blockd’s API is exposed beyond the local host, even within a private network.

Security boundary

Extended public keys and derived addresses cannot authorize spending. Access to blockd’s cache or API provides visibility into transaction history and balances but does not enable transaction signing. blockd never handles private keys.

However, complete financial transparency creates non-cryptographic risk vectors. Visibility into bitcoin holdings can inform targeted social engineering, physical coercion, or other attacks that exploit knowledge of an individual’s or organization’s financial position.

There is also a cryptographic edge case in non-hardened derivation paths: possession of both an extended public key and any single child private key enables computation of the parent private key. Hardened derivation (indicated by an apostrophe in paths such as m/84'/0'/0') prevents this attack. Most modern wallets use hardened derivation for account-level keys, but verify that imported xpubs follow this pattern before deployment.

Best practices

Use discrete address sets when full wallet tracking is unnecessary. Specifying individual addresses rather than importing an xpub eliminates the linkage problem while maintaining monitoring capability.

Delete cached data when ongoing monitoring is not required. Applications that query wallet data periodically should delete the pubkeys_set after retrieving results to minimize the exposure window.

Verify hardened derivation for imported xpubs. Non-hardened paths create a cryptographic vulnerability if any child private key is compromised.

Understand the exposure timeline. A pubkeys_set with active script hash subscriptions remains queryable by any authenticated party that knows its name. Deletion ends that exposure completely.