mirror of https://github.com/zcash/zips.git
Apply suggestions from code review
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
115f2caac8
commit
564642f1ff
12
zip-0312.rst
12
zip-0312.rst
|
@ -82,7 +82,7 @@ shielded transaction:
|
|||
|
||||
When employing re-randomizable FROST as specified in this ZIP, the goal is to
|
||||
split the spend authorization private key :math:`\mathsf{ask}` among multiple
|
||||
possible signers. This means that the proof generation will still be generated
|
||||
possible signers. This means that the proof generation will still be performed
|
||||
by a single participant, likely the one that created the transaction in the first
|
||||
place. Note that this user already controls the privacy of the transaction since
|
||||
they are responsible for creating the proof.
|
||||
|
@ -97,7 +97,7 @@ With those considerations in mind, the threat model considered in this ZIP is:
|
|||
the unlinkability property). A rogue Coordinator will be able to break
|
||||
unlinkability and privacy, but should not be able to create signed transactions
|
||||
without the approval of `MIN_SIGNERS` participants, as specified in FROST.
|
||||
- All key share holders are also trusted with the privacy and of the transaction,
|
||||
- All key share holders are also trusted with the privacy of the transaction,
|
||||
thus a rogue key share holder will be able to break its privacy and unlinkability.
|
||||
A future specification may support a scenario where individual key share
|
||||
holders are not trusted with it.
|
||||
|
@ -165,7 +165,7 @@ A new helper function is defined, which computes :math:`\mathsf{RedDSA.GenRandom
|
|||
Binding Factor Computation
|
||||
''''''''''''''''''''''''''
|
||||
|
||||
The `compute_binding_factor` function is changed to receive the `randomizer_point`
|
||||
The `compute_binding_factors` function is changed to receive the `randomizer_point`
|
||||
as follows: ::
|
||||
|
||||
Inputs:
|
||||
|
@ -361,7 +361,7 @@ Ciphersuites
|
|||
------------
|
||||
|
||||
FROST(Jubjub, BLAKE2b-512)
|
||||
'''''''''''''''''''''''''''''
|
||||
''''''''''''''''''''''''''
|
||||
|
||||
This ciphersuite uses Jubjub for the Group and BLAKE2b-512 for the Hash function `H`
|
||||
meant to produce signatures indistinguishable from RedJubjub Sapling Spend
|
||||
|
@ -388,7 +388,7 @@ Authorization Signatures as specified in [#protocol-concretespendauthsig]_.
|
|||
|
||||
- H1(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubR", m), interpreting
|
||||
the 64 bytes as a little-endian integer, and reducing the resulting integer
|
||||
modulo L = 6554484396890773809930967563523245729705921265872317281365359162392183254199.
|
||||
modulo `G.Order()`.
|
||||
- H2(m): Implemented by computing BLAKE2b-512("Zcash_RedJubjubH", m), interpreting
|
||||
the 64 bytes as a little-endian integer, and reducing the resulting integer
|
||||
modulo L = 6554484396890773809930967563523245729705921265872317281365359162392183254199.
|
||||
|
@ -402,7 +402,7 @@ Authorization Signatures as specified in [#protocol-concretespendauthsig]_.
|
|||
|
||||
|
||||
FROST(Pallas, BLAKE2b-512)
|
||||
'''''''''''''''''''''''''''''
|
||||
''''''''''''''''''''''''''
|
||||
|
||||
This ciphersuite uses Pallas for the Group and BLAKE2b-512 for the Hash function `H`
|
||||
meant to produce signatures indistinguishable from RedPallas Orchard Spend
|
||||
|
|
Loading…
Reference in New Issue