diff --git a/zip-0304.html b/zip-0304.html index ba7385be..832e2dda 100644 --- a/zip-0304.html +++ b/zip-0304.html @@ -17,7 +17,7 @@ Category: Wallet Created: 2020-06-01 License: MIT

Terminology

-

The key word "SHOULD" in this document is to be interpreted as described in RFC 2119. 1

+

The key words "MUST" and "SHOULD" in this document is to be interpreted as described in RFC 2119. 1

Abstract

This proposal describes a mechanism for creating signatures with Sapling addresses, suitable for use by the signmessage and verifymessage RPC methods in zcashd.

@@ -41,28 +41,28 @@ License: MIT \(\mathsf{MerkleCRH}^\mathsf{Sapling}\) 5
  • - \(\mathsf{DiversifyHash}(d)\) + \(\mathsf{DiversifyHash}(\mathsf{d})\) 6
  • - \(\mathsf{MixingPedersenHash}(cm, position)\) + \(\mathsf{MixingPedersenHash}(\mathsf{cm}, position)\) 7
  • - \(\mathsf{PRF}^\mathsf{nfSapling}_nk(ρ)\) + \(\mathsf{PRF}^\mathsf{nfSapling}_\mathsf{nk}(ρ)\) 8
  • - \(\mathsf{SpendAuthSig.RandomizePrivate}(α, sk)\) + \(\mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{sk})\) , - \(\mathsf{SpendAuthSig.RandomizePublic}(α, vk)\) + \(\mathsf{SpendAuthSig.RandomizePublic}(α, \mathsf{vk})\) , - \(\mathsf{SpendAuthSig.Sign}(sk, m)\) + \(\mathsf{SpendAuthSig.Sign}(\mathsf{sk}, m)\) , and - \(\mathsf{SpendAuthSig.Verify}(vk, m, σ)\) + \(\mathsf{SpendAuthSig.Verify}(\mathsf{vk}, m, σ)\) 9
  • - \(\mathsf{NoteCommit}^\mathsf{Sapling}_rcm(g_d, pk_d, value)\) + \(\mathsf{NoteCommit}^\mathsf{Sapling}_\mathsf{rcm}(\mathsf{g_d}, \mathsf{pk_d}, value)\) 10
  • - \(\mathsf{ValueCommit}_rcv(value)\) + \(\mathsf{ValueCommit}_\mathsf{rcv}(value)\) 11

    • We also reproduce some notation and functions here for convenience:

    @@ -102,17 +102,21 @@ License: MIT

    Specification

    A Sapling address signature is created by taking the process for creating a Sapling Spend description, and running it with fixed inputs:

    Signature algorithm

    The inputs to the signature algorithm are:

    • The payment address - \((d, pk_d)\) + \((\mathsf{d}, \mathsf{pk_d})\) ,
    • Its corresponding expanded spending key - \((ask, nsk, ovk)\) + \((\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk})\) ,
    • The SLIP-44 13 coin type, and
    • The message @@ -122,13 +126,13 @@ License: MIT

      The signature is created as follows:

      • Derive the full viewing key - \((ak, nk, ovk)\) + \((\mathsf{ak}, \mathsf{nk}, \mathsf{ovk})\) from the expanded spending key.
      • Let \(g_d = \mathsf{DiversifyHash}(d)\) .
      • Let - \(cm = \mathsf{NoteCommit}^\mathsf{Sapling}_0(\mathsf{repr}_\mathbb{J}(g_d), \mathsf{repr}_\mathbb{J}(pk_d), 1)\) + \(cm = \mathsf{NoteCommit}^\mathsf{Sapling}_0(\mathsf{repr}_\mathbb{J}(\mathsf{g_d}), \mathsf{repr}_\mathbb{J}(\mathsf{pk_d}), 1)\) .
      • Let \(rt\) @@ -147,30 +151,30 @@ License: MIT \(rt\) . 14
      • Let - \(cv = \mathsf{ValueCommit}_0(1)\) + \(\mathsf{cv} = \mathsf{ValueCommit}_0(1)\) .
        • This is a constant and may be pre-computed.
      • Let - \(nf = \mathsf{PRF}^\mathsf{nfSapling}_{\mathsf{repr}_\mathbb{J}(nk)}(\mathsf{repr}_\mathbb{J}(\mathsf{MixingPedersenHash}(cm, 0)))\) + \(nf = \mathsf{PRF}^\mathsf{nfSapling}_{\mathsf{repr}_\mathbb{J}(\mathsf{nk})}(\mathsf{repr}_\mathbb{J}(\mathsf{MixingPedersenHash}(\mathsf{cm}, 0)))\) .
      • Select a random \(α\) .
      • Let - \(rk = \mathsf{SpendAuthSig.RandomizePublic}(α, ak)\) + \(\mathsf{rk} = \mathsf{SpendAuthSig.RandomizePublic}(α, \mathsf{ak})\) .
      • Let \(zkproof\) be a Sapling spend proof with primary input - \((rt, cv, nf, rk)\) + \((\mathsf{rt}, \mathsf{cv}, \mathsf{nf}, \mathsf{rk})\) and auxiliary input - \((path, 0, g_d, pk_d, 1, 0, cm, 0, α, ak, nsk)\) + \((path, 0, \mathsf{g_d}, \mathsf{pk_d}, 1, 0, \mathsf{cm}, 0, α, \mathsf{ak}, \mathsf{nsk})\) . 15
      • Let - \(rsk = \mathsf{SpendAuthSig.RandomizePrivate}(α, ask)\) + \(\mathsf{rsk} = \mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{ask})\) .
      • Let \(coinType\) @@ -179,10 +183,10 @@ License: MIT \(digest = \mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{"ZIP304Signed"}\,||\,coinType, zkproof\,||\,msg)\) .
      • Let - \(spendAuthSig = \mathsf{SpendAuthSig.Sign}(rsk, digest)\) + \(spendAuthSig = \mathsf{SpendAuthSig.Sign}(\mathsf{rsk}, digest)\) .
      • Return - \((nf, rk, zkproof, spendAuthSig)\) + \((\mathsf{nf}, \mathsf{rk}, zkproof, spendAuthSig)\) .
    @@ -190,17 +194,17 @@ License: MIT

    The inputs to the verification algorithm are:

    -

    The signature is verified as follows:

    +

    The signature MUST be verified as follows:

    Signature encoding

    The raw form of a ZIP 304 signature is - \(nf\,||\,rk\,||\,zkproof\,||\,spendAuthSig\) + \(\mathsf{nf}\,||\,\mathsf{rk}\,||\,zkproof\,||\,spendAuthSig\) , for a total size of 320 bytes.

    When encoding a ZIP 304 signature in a human-readable format, implementations SHOULD use standard Base64 for compatibility with the signmessage and verifymessage RPC methods in zcashd. ZIP 304 signatures in this form are 428 bytes. The encoded form is the string 'zip304:' followed by the result of Base64-encoding 2 the raw form of the signature.

    Rationale

    We use a fake note within the signature scheme in order to reuse the Sapling Spend circuit and its parameters. It is possible to construct a signature scheme with a smaller encoded signature, but this would require a new circuit and another parameter-generation ceremony (if Groth16 were used).

    -

    We use a note value of 1 zatoshi instead of zero to ensure that the payment address is fully bound to +

    We use a note value of + \(1\) + zatoshi instead of zero to ensure that the payment address is fully bound to \(zkproof\) . Notes with zero value have certain constraints disabled inside the circuit.

    We set - \(rcm\) + \(\mathsf{rcm}\) and - \(rcv\) + \(\mathsf{rcv}\) to zero because we do not need the hiding properties of the note commitment or value commitment schemes (as we are using a fixed-value fake note), and can thus omit both - \(rcm\) + \(\mathsf{rcm}\) and - \(rcv\) + \(\mathsf{rcv}\) from the signature.

    Security and Privacy Considerations

    @@ -275,12 +281,12 @@ License: MIT

    Most of the data within a ZIP 304 signature is inherently non-malleable: