Privacy vulnerability detection for BDK wallets

[LORDBABUINO]

Describe the enhancement

Today, a developer building a wallet with bdk_wallet has no way to detect or surface privacy leaks in a user's transaction history — address reuse, common input ownership (CIOH), identifiable change outputs, dust attacks, script type mixing, and more. Users accumulate privacy debt silently, and by the time they notice, the damage is on-chain and permanent.

BDK already ships preventive measures — shuffled ordering, anti-fee-sniping, signature grinding (#28) — but prevention alone isn't enough. Users need to see what's already exposed.

We've built Stealth, a Rust privacy analysis engine that detects these leaks. We'd like to discuss making it available to bdk_wallet users — either as a crate under bitcoindevkit/ or as an external crate that depends on bdk_wallet.

Stealth currently implements 12 detectors:

Detector	What it catches
ADDRESS_REUSE	Addresses receiving multiple transactions
CIOH	Multiple wallet inputs spent together, revealing common ownership
CHANGE_DETECTION	Change outputs identifiable via round amounts, script type, or BIP-44 path
DUST / DUST_SPENDING	Tiny UTXOs used to track spending behavior
SCRIPT_TYPE_MIXING	Transactions mixing P2PKH, P2WPKH, P2TR, etc.
CONSOLIDATION	Multi-input consolidations that link UTXOs
CLUSTER_MERGE	Merging UTXOs from unrelated funding chains
UTXO_AGE_SPREAD	Spending old and new coins together (timing correlation)
EXCHANGE_ORIGIN	Outputs from exchange batch withdrawals
TAINTED_UTXO_MERGE	Mixing risky and clean inputs
BEHAVIORAL_FINGERPRINT	Repeated patterns in amounts, fees, RBF, locktime

Each finding includes severity (Low/Medium/High/Critical), description, contextual details, and a correction suggestion. All thresholds are configurable and detectors can be individually toggled.

Use case

A wallet developer using bdk_wallet wants to show users a privacy health score, flag risky UTXOs before spending, or warn "this transaction will reveal you own these 3 addresses." Today they'd have to build all of this from scratch.

With a privacy analysis crate, it could look like:

use bdk_privacy::PrivacyAnalyzer;

let analyzer = PrivacyAnalyzer::default();
let report = analyzer.analyze(&wallet);

// "You have 3 critical findings, 5 warnings"
show_privacy_score(&report.summary);

// "Address bc1q...xyz has been reused 4 times"
// "Transaction abc...def merged UTXOs from unrelated sources"
for finding in &report.findings {
    show_finding(finding);
}

No extra infrastructure. No RPC calls. Just pass a &Wallet and get a structured report. Every BDK-based wallet gets privacy analysis for free.

We've looked at bdk_wallet's public API and the data needed is already there:

• wallet.transactions() — full transaction history with inputs/outputs
• LocalOutput.keychain — change vs receive classification (critical for change detection)
• wallet.is_mine() / wallet.derivation_of_spk() — script ownership
• wallet.list_output() — spent + unspent UTXOs
• wallet.tx_graph().walk_ancestors() — transaction graph traversal
• wallet.calculate_fee_rate() — fee analysis

The only gap is counterparty transactions — detecting things like cluster merge or exchange origin requires transactions beyond the wallet's own scripts. We currently fetch these via Bitcoin Core RPC. We'd like to discuss the best pattern for this within BDK's architecture.

Impact

• Nice-to-have / UX improvement

Are you using BDK in a production project?

• Not yet, but planning to

Which backend(s) are relevant (if any)?

• Bitcoin Core RPC
• None / not backend-related (e.g. bdk_chain, bdk_core)

Project or organization (optional)

Stealth — open source Bitcoin privacy analysis tool (MIT licensed).

Additional context

This proposal follows a conversation with @oleonardolima who suggested opening this issue to discuss whether it fits best under bitcoindevkit/ or as an external crate.

We're also exploring how a privacy-aware BnbMetric for coin-select could complement detection with prevention — penalizing coin selections that create CIOH or change detection vulnerabilities.

We're ready to do the work — we just want to align on the right home for it.

[tnull]

While doing such analysis might be somewhat useful to improve users' awareness on their privacy situation, I'm not sure it should be considered central to BDK's functionalities, i.e., not sure if it would make sense to put it directly in the workspace or org? An independently maintained crate depending on bdk_wallet is likely able to achieve the same goals, AFAIU?

Apart from the more general question on where this should live, I have to say I'm a bit doubtful on the approach in general:

With a privacy analysis crate, it could look like:

use bdk_privacy::PrivacyAnalyzer;

let analyzer = PrivacyAnalyzer::default();
let report = analyzer.analyze(&wallet);

// "You have 3 critical findings, 5 warnings"
show_privacy_score(&report.summary);

// "Address bc1q...xyz has been reused 4 times"
// "Transaction abc...def merged UTXOs from unrelated sources"
for finding in &report.findings {
show_finding(finding);
}

What does 'privacy score' even mean, and how should users interpret it? In this concrete example: what action should Alice take now that her wallet told her she has 3 critical findings and 5 warnings? Would she revert back to manual UTXO management to resolve the situation? Would she switch wallets to make the warning go away?

For research and informational purposes, such tooling seems useful, but I'm not sure how it would actually be applied in a wallet's context?

[LORDBABUINO]

Thanks for the thoughtful response. The questions about actionability are fair — a vague "privacy score" without clear next steps would indeed be unhelpful. Let me address both points.

Where it lives

An independently maintained crate depending on bdk_wallet works for us. We'll build it as an external crate that accepts a &Wallet and returns findings.

What users actually do with the information

The "3 critical findings, 5 warnings" example was too abstract. In practice, the value splits into two layers:

1. The wallet acts automatically on detection results

This is where detection feeds directly into coin selection. Instead of just reporting problems, the wallet avoids creating new ones:

• CIOH risk → coin selection avoids co-spending UTXOs from different funding sources. A privacy-aware BnbMetric could penalize selections that would link previously unlinked clusters.
• Change detection → coin selection picks inputs where the change amount is less distinguishable from the payment amount.
• Script type mixing → coin selection avoids mixing P2WPKH and P2TR inputs in the same transaction.
• Dust UTXOs → wallet marks them as unspendable via TxBuilder::unspendable(), preventing them from being used as tracking vectors.

The user doesn't see a warning — the wallet just makes better decisions. This is the main value for wallet developers integrating with BDK.

2. Findings the user can act on

Some findings require user decisions that the wallet can't automate:

• Address reuse detected → the address is now a permanent identity anchor linking all its transactions. The wallet flags it, avoids sending change to it, and warns if someone tries to send to it again.
• Tainted UTXOs → user decides whether to isolate, spend via payjoin, or accept the risk.
• Cluster merge → user learns that two "identities" are now linked on-chain. Can't be undone, but prevents further damage (e.g., stop consolidating across those clusters).
• Exchange origin → user knows chain surveillance firms can link their withdrawal to the exchange. Might choose to coinjoin before spending.

Some damage is permanent — it's already on-chain. But knowing about it prevents making it worse, which is the most common way users degrade their privacy: unknowingly repeating the same patterns.

Concrete example

Alice opens her wallet. Behind the scenes, the privacy crate has flagged that UTXOs A and B come from different funding sources (one from an exchange, one from a friend). When Alice builds a transaction, the coin selection avoids picking A and B together — no CIOH leak, no user interaction needed.

If Alice manually selects both UTXOs (coin control), the wallet warns: "Spending these together will link your exchange account to this other funding source." Alice decides.

That's the kind of integration we're aiming for — not a dashboard of warnings, but a wallet that's privacy-aware by default.

[notmandatory]

It's great to see new tools that help users identify privacy issues in their BDK wallet. But I agree with @tnull this can easily be a side project that only depends on the bdk_wallet or bdk_chain crates.

For fixing privacy issues directly in bdk_wallet the ones listed in #28 are clearer improvements, but first we need #188.

[LORDBABUINO]

Thanks @notmandatory. We'll build it as an external crate depending on bdk_wallet/bdk_chain. We'll keep an eye on #188 — multi-descriptor support will make per-descriptor analysis much easier from an external crate.

[notmandatory]

@LORDBABUINO I also recommend taking a look at verso, it appears to have similar goals. And at least it's an example of how a wallet privacy tool based on bdk_wallet might look.