2024-05-27 18:58:45 +04:00

74 lines
2.0 KiB
Org Mode

* Open Issues
** Why does PartialTransaction have a "blinding"?
I believe it should only have a derived balance field.
** Poseidon Constants for Grumpkin Field
Generating the poseidon constants for the Grumpkin curve is very slow, like takes 1 minute.
I need to pre-generate these to make the curve work.
** Solvers need the value of a note in order to solve it
- do users provide a merkle proof showing the value is legit?
- merkle proofs also reveal positional information.
- if we are to reveal partial information to solvers
we will need to blind the other leaf nodes of the tree:
Note = VALUE || UNIT || ....
com = ..root..
/ \
h(h(V), h(U)) ...
/ \
h(VALUE) h(UNIT)
| |
VALUE UNIT
Revealing the value's merkle path would reveal h(UNIT) and since UNIT is well known, h(UNIT) is also easily computable.
Thus each component of the Note should have a blinding factor
Note = (r1, VALUE) || (r1, UNIT) || ....
** Transferring requires recipients sk
We need to be able to create a partial transaction where we don't know the output note's nullifier.
What we need: A public note + balance commitment
balance commitment is computed as
```
value <- known by transaction builder
unit <- known by transaction builder
blinding <- PRF_r(nullifier) !!!! <-- this is where the issue is
funge <- hash_to_curve(Unit)
balance_commit <- pedersen_commit(value, blinding, funge)
```
Why is the blinding a PRF of the nullifier? Can't we simply use the randomness of the transaction to derive a blinding factor?
*** How does zcash solve this?
They provide specific randomness for this when building the transaction.
** Note Unit should be a string hashed to curve point when needed.
We want human readable units (i.e. "ETH" "NMO")
I've gone and denoted it as bytes.
* Solved
** Do we need note.randomness?
It's currently used in the note commitment. But perhaps it's not really necessary?
- it allows you to get away form content based addressing, this may be necessary for total privacy.
Yes, we need this