privacy is a question about information, observers and transaction paths. Ordinary transparent transactions expose outputs, values and spending relationships. MWEB changes that public information, but neither a privacy feature nor a pseudonymous establishes anonymity against every observer.
Correction · 22 October 2026. The unsupported 85% single-output statistic, an undated balance comparison and categorical tracing claims are withdrawn. This revision separates public evidence, clustering heuristics, network metadata and counterparty records. It does not measure current usage or test a chain-analysis product.
Pseudonymous is not anonymous
An ordinary address does not contain a person's name. A transparent output does contain a value and spending condition, and a later transaction can reference it. The versioned transaction structures distinguish these objects. The address is a useful encoding, not a complete identity or .
A counterparty may know who supplied an address. An can retain its withdrawal records; a merchant can connect an invoice to an order. What that organization actually knows depends on its records, implementation and access. A public explorer alone does not prove it possesses all those identities.
A link to one address also does not automatically reveal every account or output belonging to a person. Some links are explicit; others require assumptions. Explain which observation supports which inference rather than declaring that one identified payment makes “your whole history” known.
How transparent-chain analysis works, and where inference enters
Spending several transparent outputs together creates a visible common-input relationship. Analysts can interpret it as evidence of common control, but collaborative transactions and arrangements complicate that interpretation. Change identification is another inference; not every output that resembles change is proven to belong to the sender.
exposes repeated receipts to the same destination. Fresh receiving addresses can avoid that simple reuse link, while later common-input spending can create another link. The UTXO and coin-control guide explains why consolidating everything can expose relationships rather than improve privacy.
The old article claimed that about 85% of LTC transactions had one output and inferred easy tracing from that number. No preserved window, dataset, counting method or special-transaction treatment supported it. That statistic is removed. Even a measured output-count distribution would not establish a chain-analysis success rate.
| Observation | Supported statement | Not established by itself |
|---|---|---|
| Two inputs spent together | The transaction references both outputs | One named person controlled both |
| Repeated address use | Receipts share a destination encoding | Every receipt belongs economically to the same customer |
| Exchange withdrawal record | The service recorded that withdrawal request | All later spending belongs to the account holder |
| Broadcast seen from a peer | The observer received it through that connection | That peer originated the payment or identifies a person |
What MWEB changes
Extension-block design and the MimbleWimble proposal describe an optional format with confidential amounts and different transaction representation. These design documents need to be read alongside deployed software; their repository status labels do not establish every current implementation detail.
MWEB is more than a transparent payment with a hidden amount label. Aggregation, commitments and its receiving-address model change what a public observer sees. Conversely, confidentiality does not erase information held by sender, receiver, wallet provider or a network observer. State the actual threat being assessed.
Movement into and out of MWEB has observable transparent-chain boundaries. Timing and amounts at those boundaries can support correlation hypotheses. Whether a particular pair can be linked depends on available observations, competing explanations and the observer's capabilities. A similar amount is evidence to evaluate, not automatic proof of a unique path.
The old claim that a small fraction of total supply made MWEB trivially traceable is withdrawn. A balance stock is not a count of plausible transaction counterparts, nor a quantified anonymity set for a particular payment. This revision provides no replacement success probability or current adoption estimate.
MWEB also has route and availability rules. In Core 0.21.5.8, peg-out maturity is six blocks, with the actual height-difference check in input validation. That rule is different from an exchange's credit policy. The maturity guide explains the distinction.
Compare privacy mechanisms, not slogans
| System or path | Relevant design | What still needs assessment |
|---|---|---|
| Transparent Litecoin or Bitcoin | Public transaction values and input/output links | Identity records, collaborative spending, change assumptions and network metadata |
| Litecoin through MWEB | Optional confidential format with transparent entry/exit boundaries | Observer capabilities, endpoint records, wallet behavior and boundary correlation |
| Monero | Privacy mechanisms integrated into its normal transaction path | Specific input-set construction, metadata, implementation and counterparty knowledge |
Monero's ring-signature explanation describes ambiguity among keys in a signature construction. It does not say that every person using the network becomes equally plausible for each transaction. A comparison must not substitute total network usage for a particular payment's anonymity set. See the corrected Litecoin/Monero comparison.
Practical checks for a defined privacy objective
Begin with the information you want to limit: public balance linkage, disclosure to a remote wallet server, a merchant connecting purchases, or exposure of a 's network address. Different controls address different layers.
- Use fresh receiving requests when supported, authenticate the complete destination and keep private labels.
- Inspect common-input spending and consolidation before combining receipts from separate activities.
- Treat an as sensitive account information. The xpub guide explains what it can reveal.
- Check the exact wallet's MWEB workflow and receiver support before relying on it.
- If using Tor or your own node, verify the actual connection configuration and consider other application traffic.
- Retain realistic expectations about information already disclosed to counterparties.
Core's Tor documentation describes proxy and onion settings. Routing some traffic through Tor does not prove that every wallet request uses it or eliminate application-level disclosures. Running a node also does not erase the public transaction graph.
Changing amounts, delaying transfers or splitting outputs should not be advertised as a guaranteed way to defeat tracing. Such actions add transactions, costs and potentially more observable patterns. Evaluate a specific objective rather than applying a ritual.
Implementation security and privacy are separate questions
The Foundation's 2026 postmortem describes validation and recovery incidents. These are relevant to software maintenance and operational risk. They do not directly measure a privacy mechanism's resistance to a particular tracing attack. The versioned release notes are the starting point for update decisions.
This guide does not promise to hide activity from a named investigator or conclude that one asset makes every user anonymous. It also avoids current exchange-support claims without checking that provider's exact deposit route and date.
Record the threat model before choosing a control
Download the observer and disclosure worksheet. Record the observer, information already exposed, proposed control, what it changes and what remains observable. The worksheet needs no wallet secrets and supplies no numerical privacy score.
A useful privacy claim is narrow enough to test: “this server no longer receives my account query” is different from “nobody can identify me”. Keep source-backed properties separate from assumptions about the observer.
Frequently asked questions
Is an LTC address a verified identity?
No. It encodes a destination. Identity links come from other evidence, including counterparty records or additional inferences.
Does common-input spending prove one person owns everything?
No. It creates a public relationship, but ownership clustering is a heuristic with exceptions.
Does MWEB's supply balance measure my anonymity set?
No. A balance stock alone does not describe a particular transaction's plausible counterparts or an observer's tracing capabilities.
Does Tor erase my on-chain history?
No. It addresses particular network connections. Transparent transaction history and information disclosed elsewhere remain separate concerns.
Is Monero's anonymity set the whole network?
Not as a general description of every transaction. Evaluate its specific constructions and metadata instead of substituting total user count.
Does this article test commercial tracing software?
No. It explains evidence boundaries and source-backed mechanisms. No current tracing success rate or network-wide privacy score is claimed.
