Selective disclosure looks elegant, but the more I think about it, the more it feels like “moving” trust to a different place
In Dusk’s latest whitepaper, there’s a design called Moonlight: a public transaction layer running in parallel with a privacy layer. Institutions can choose visibility depending on the scenario—use the shielded layer when privacy is needed, and the public layer when transparency is required. Sounds flexible, right?
But think carefully: the very words “selective disclosure” imply that the decision-making power is not really in your hands. Who defines the disclosure rules? Who holds the verification permissions? If the compliance keys are in the hands of a few, then the difference between this system and permissioned finance may be only that it adds one more chain.
Dusk’s entire bet is to “embed audit authority directly into the protocol.” That’s clever—but it also means it turns the compliance risks facing privacy coins into a trust issue: the trust that whoever controls the compliance keys won’t abuse their power. You don’t need to trust the project team anymore; now you need to trust the key holders not to misuse their access. Trust has just been relocated. It’s still there. @Dusk
Some comments put it bluntly: “Selective disclosure transfers the trust bottleneck to whoever controls the compliance keys.” If the key controller is bribed, attacked, or simply doesn’t act, is your privacy still truly yours? A system that can open your privacy—no matter how well it locks it most of the time—is not secure enough for me.
Dusk’s design approach is indeed one of the few stories in the privacy space that’s aimed at institutions. But as a retail user, I need to think clearly: do I want a system that is private most of the time and can be opened when necessary, or one that is never openable? The former is called Dusk; the latter is called Monero. They’re both called privacy, but they’re fundamentally different in nature.
#dusk $DUSK
In Dusk’s latest whitepaper, there’s a design called Moonlight: a public transaction layer running in parallel with a privacy layer. Institutions can choose visibility depending on the scenario—use the shielded layer when privacy is needed, and the public layer when transparency is required. Sounds flexible, right?
But think carefully: the very words “selective disclosure” imply that the decision-making power is not really in your hands. Who defines the disclosure rules? Who holds the verification permissions? If the compliance keys are in the hands of a few, then the difference between this system and permissioned finance may be only that it adds one more chain.
Dusk’s entire bet is to “embed audit authority directly into the protocol.” That’s clever—but it also means it turns the compliance risks facing privacy coins into a trust issue: the trust that whoever controls the compliance keys won’t abuse their power. You don’t need to trust the project team anymore; now you need to trust the key holders not to misuse their access. Trust has just been relocated. It’s still there. @Dusk
Some comments put it bluntly: “Selective disclosure transfers the trust bottleneck to whoever controls the compliance keys.” If the key controller is bribed, attacked, or simply doesn’t act, is your privacy still truly yours? A system that can open your privacy—no matter how well it locks it most of the time—is not secure enough for me.
Dusk’s design approach is indeed one of the few stories in the privacy space that’s aimed at institutions. But as a retail user, I need to think clearly: do I want a system that is private most of the time and can be opened when necessary, or one that is never openable? The former is called Dusk; the latter is called Monero. They’re both called privacy, but they’re fundamentally different in nature.
#dusk $DUSK
