Been sitting with a question Dusk's documentation doesn't directly answer with hard numbers: can two different Phoenix notes ever produce the same nullifier.
What I can confirm precisely: Dusk's own Phoenix repository states the nullifier is computed specifically so an external observer can't link it back to which note it came from. Each note gets hashed into leaves of a Merkle tree of notes, and spending one produces a deterministic nullifier value tied to that specific note's data.
The hashing underneath this — across Dusk's Merkle tree structure and broader cryptographic operations — runs on Poseidon, a SNARK-friendly hash function designed by Dusk's own team specifically for collision-resistant hashing inside zero-knowledge circuits. That's not a generic hash borrowed off the shelf; it's purpose-built for exactly this kind of ZK-native commitment work.
But collision-resistant isn't the same as collision-proof. Any hash function, Poseidon included, carries a theoretical (astronomically small) chance of two different inputs producing the same output — that's the nature of hashing itself, not a Dusk-specific weakness.
What I haven't found in Dusk's own materials is any published collision-probability figure specific to their exact Poseidon parameters, or documentation of dedicated collision-testing beyond the general security properties Poseidon inherits by design.
If anyone's seen an audit report covering this specific property for Dusk's implementation, I'd like to compare it against what's publicly documented.
#dusk $DUSK @Dusk
What I can confirm precisely: Dusk's own Phoenix repository states the nullifier is computed specifically so an external observer can't link it back to which note it came from. Each note gets hashed into leaves of a Merkle tree of notes, and spending one produces a deterministic nullifier value tied to that specific note's data.
The hashing underneath this — across Dusk's Merkle tree structure and broader cryptographic operations — runs on Poseidon, a SNARK-friendly hash function designed by Dusk's own team specifically for collision-resistant hashing inside zero-knowledge circuits. That's not a generic hash borrowed off the shelf; it's purpose-built for exactly this kind of ZK-native commitment work.
But collision-resistant isn't the same as collision-proof. Any hash function, Poseidon included, carries a theoretical (astronomically small) chance of two different inputs producing the same output — that's the nature of hashing itself, not a Dusk-specific weakness.
What I haven't found in Dusk's own materials is any published collision-probability figure specific to their exact Poseidon parameters, or documentation of dedicated collision-testing beyond the general security properties Poseidon inherits by design.
If anyone's seen an audit report covering this specific property for Dusk's implementation, I'd like to compare it against what's publicly documented.
#dusk $DUSK @Dusk