the Phoenix detail is easy to miss:
spent notes stay in the Merkle tree.
I first treated that tree like a private UTXO set. once a note was spent, I assumed it would disappear.
the whitepaper says otherwise.
when a Phoenix note is spent, its owner derives a nullifier from the note’s secret key. the network records that nullifier so the note cannot be spent again.
but it does not learn which note the nullifier belongs to.
so the note stays. the tree keeps growing.
that creates a distinction I hadn’t thought about:
recorded is not the same as spendable.
a recent Merkle root lets the network verify that an input note belongs to the tree. membership alone does not mean the value is still live.
that answer sits in the nullifier list.
and Phoenix keeps the public link between the two hidden.
in Moonlight, Dusk maps an account to a public balance.
Phoenix works differently. the network verifies a ZK proof that input notes are correctly nullified and hold enough value for new notes, deposit and maximum gas, without exposing the amounts.
so a Phoenix note can remain recorded after its economic usefulness is gone.
the record survives.
the spending right does not.
then there is another split.
a view key can be given to a trusted party to scan the network and identify transactions addressed to the user. but it still cannot spend those notes, because the note secret key requires the user’s whole secret key.
so “can see my private state” and “can control my private state” are different permissions.
two boundaries appear:
recorded / spendable
visible / controllable
the edge case I keep coming back to is an application reconstructing what a user has right now.
the note being present is insufficient.
being able to recognize it is insufficient too.
you need history, nullification state and the right secret material.
which makes me wonder:
in a private ledger, is “current state” one object at all, or the intersection of records intentionally incomplete when read alone?
@Dusk_Foundation #dusk $DUSK $VELVET $APR
spent notes stay in the Merkle tree.
I first treated that tree like a private UTXO set. once a note was spent, I assumed it would disappear.
the whitepaper says otherwise.
when a Phoenix note is spent, its owner derives a nullifier from the note’s secret key. the network records that nullifier so the note cannot be spent again.
but it does not learn which note the nullifier belongs to.
so the note stays. the tree keeps growing.
that creates a distinction I hadn’t thought about:
recorded is not the same as spendable.
a recent Merkle root lets the network verify that an input note belongs to the tree. membership alone does not mean the value is still live.
that answer sits in the nullifier list.
and Phoenix keeps the public link between the two hidden.
in Moonlight, Dusk maps an account to a public balance.
Phoenix works differently. the network verifies a ZK proof that input notes are correctly nullified and hold enough value for new notes, deposit and maximum gas, without exposing the amounts.
so a Phoenix note can remain recorded after its economic usefulness is gone.
the record survives.
the spending right does not.
then there is another split.
a view key can be given to a trusted party to scan the network and identify transactions addressed to the user. but it still cannot spend those notes, because the note secret key requires the user’s whole secret key.
so “can see my private state” and “can control my private state” are different permissions.
two boundaries appear:
recorded / spendable
visible / controllable
the edge case I keep coming back to is an application reconstructing what a user has right now.
the note being present is insufficient.
being able to recognize it is insufficient too.
you need history, nullification state and the right secret material.
which makes me wonder:
in a private ledger, is “current state” one object at all, or the intersection of records intentionally incomplete when read alone?
@Dusk_Foundation #dusk $DUSK $VELVET $APR