Closed wanseob closed 3 years ago
The solution described above increases the complexity of the system because the sender also requires the jubjub point of the recipient for the DH key exchange(the shared key is used to encrypt leaf data.) Furthermore, the wallet should manage the nullifier_seed
together which means if a user only has the private key without the nullifier seed, the user loses UTXOs.
Therefore we can only modify the nullifier computation logic using the EdDSA signature just like
nullifier = hash(EdDSA, leaf_index)
This makes sense because
But currently, this is not sure that the current circom circuit supports the non-malleability of the EdDSA. This feature will be part of the Burrito version.
We've decided to change the UTXO & nullifier's detail structure to follow ZCash's viewing key & spending key structure.
p = random() // spending key
n = ff(sha3(p)) // nullifier seed, viewing key
N = n*G // public nullifier seed, public viewing key
s = random() // tx sender's ephemeral key
K = s*N // shared secret key for chacha20 encryption/decryption
P = poseidon(p*G, n) // public spending key
utxo = poseidon(P, data, salt)
nullifier = poseidon(n, index)
Account shares (P, N) and store (p, n) For the effective account restoration protocol, we can derive nullifier seed n from p for example (n = ff(sha3(p))
closed by #44
Is your feature request related to a problem? Please describe. The sender creates a UTXO for the recipient, and therefore the sender can track the 1st transaction after the recipient receives the UTXO.
In version(0.7.0), Zkopru computes the hash of the UTXO with
Describe the solution you'd like
The recipient create a zk-tx public key with the following logic and share to others.
We can generate the UTXO with following steps:
Then finally the nullifier becomes
Describe alternatives you've considered MPC protocol can help this, but non-interactive way preferred.
Additional context N/A