found something almost by accident tonight, digging through Dusk's GitHub issues instead of its docs for once — a discussion thread about how Phoenix actually derives its keys, and an admitted flaw in how it's done today.
Phoenix, like most shielded protocols, splits keys into two roles:
a spend key that can move funds, and a view key that can only see them. Share the view key with an accountant or auditor, and they see your activity without ever being able to touch it. Straightforward in theory. But @Dusk Foundation own engineers flagged a real weakness in the current implementation: deriving a new key currently requires passing around the full seed phrase itself, not some intermediate value derived from it. That breaks a basic security principle, least privilege, since any code handling key derivation ends up holding more secret material than it actually needs.
Their fix, still in progress: introduce a separated master key between the seed and every derived key, so the raw seed never has to travel through derivation logic again. Small architectural change, but it's the difference between a wallet bug staying contained and a wallet bug exposing everything at once.
What got me is that they're doing this fix in public, mid-migration, alongside an EIP-2333-style overhaul for Moonlight keys too. Most chains would quietly patch this. $DUSK -secured wallets are safer once this ships — but should a privacy-first chain be running this exposed during the transition period, or is transparent iteration actually the more trustworthy path? #dusk $DUSK @Dusk
Phoenix, like most shielded protocols, splits keys into two roles:
a spend key that can move funds, and a view key that can only see them. Share the view key with an accountant or auditor, and they see your activity without ever being able to touch it. Straightforward in theory. But @Dusk Foundation own engineers flagged a real weakness in the current implementation: deriving a new key currently requires passing around the full seed phrase itself, not some intermediate value derived from it. That breaks a basic security principle, least privilege, since any code handling key derivation ends up holding more secret material than it actually needs.
Their fix, still in progress: introduce a separated master key between the seed and every derived key, so the raw seed never has to travel through derivation logic again. Small architectural change, but it's the difference between a wallet bug staying contained and a wallet bug exposing everything at once.
What got me is that they're doing this fix in public, mid-migration, alongside an EIP-2333-style overhaul for Moonlight keys too. Most chains would quietly patch this. $DUSK -secured wallets are safer once this ships — but should a privacy-first chain be running this exposed during the transition period, or is transparent iteration actually the more trustworthy path? #dusk $DUSK @Dusk
