You are preparing a privacy proof and thinking about whether to exclude some "suspicious" addresses from the association set. This idea is dangerous: in Privacy Pools' proving mechanism, some addresses absolutely cannot be casually excluded. If you exclude the wrong one, your proof may simply fail.
The core issue is that when you generate a proof, you are not choosing arbitrary addresses. You are using a specific set maintained by an "Association Set Provider" (ASP). This is a compliance-layer tool. The ASP continuously monitors, records, and classifies on-chain activity, and regularly updates the "association set."
Why can't you casually exclude addresses from the association set?
Privacy Pools withdrawal proof requires two zero-knowledge proofs: one proves that you own an unspent deposit (a commitment in the state tree), and the other proves that your deposit belongs to the association set defined by the ASP.
Simply put, the system asks you to prove "my deposit is in this set," not "my deposit is not in that set." At withdrawal, the logic chain of the zero-knowledge proof is fixed. It must verify that your deposit commitment overlaps in both the "state tree" and the "association set tree." This fundamentally means you cannot casually exclude addresses from the set.
The address you really cannot touch: your own deposit
What you really cannot "exclude" is the association set linked to your own deposit.
When you deposit into Privacy Pools, the protocol reviews the source of funds. If it passes, the funds are accepted into the association set. After the transaction is confirmed, the deposited funds become part of the anonymous set. This means your deposit has been tagged as "ASP approved" (an inclusion-style set). At withdrawal, you must prove to the system that your deposit belongs to this approved set, not try to avoid it.
Practical advice
- Do not filter manually: In the Privacy Pools dApp interface, you do not need to manually pick the association set. The system automatically matches and generates the proof according to the current ASP rules.
- Watch ASP rule changes: The ASP continuously monitors on-chain transactions and regularly updates the "association set." If updated rules later consider your deposit source suspicious, the approval you once had may be removed, and you may be unable to withdraw normally.
How to verify after completing the operation
At withdrawal, on the dApp interface that generates the zero-knowledge proof, confirm that the "association set root" (ASP Root) verified by the proof is the latest one. If it shows an old association set that has already been updated or retired, proof generation will most likely fail. In that case, you need to sync the latest ASP state first.
