mirror of
https://github.com/logos-blockchain/logos-blockchain-specs.git
synced 2026-01-08 16:13:10 +00:00
95 lines
2.7 KiB
Org Mode
95 lines
2.7 KiB
Org Mode
* Open Issues
|
|
|
|
** provided commitment to zero may removing the blinding of the pederson commitment
|
|
|
|
Since you can subtract the randomness from the commitment to get just the binding part.
|
|
|
|
Ok, lets deal with these zero commitments.
|
|
|
|
In place of zero commitments, we can have the solver prove that the value part of a pederson
|
|
commitment is zero.
|
|
|
|
|
|
|
|
** Rename transaction randonmness to tx_rand and commitment randomness to cm_rand
|
|
|
|
Currently they are both called "rand" and it's confusing.
|
|
|
|
** 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.
|
|
|
|
- I tried the other large curve where the params are already generated and it is still slow. Need to dig into this.
|
|
|
|
** 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
|
|
** Note.verify() should take a proof
|
|
|
|
We should have two variants, verifyDeath(deathProof) verifyBirth(birthProof)
|
|
|
|
|
|
** 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
|