2016-02-02 07:04:18 -08:00
\documentclass { article}
2015-12-14 09:03:59 -08:00
\RequirePackage { amsmath}
\RequirePackage { bytefield}
\RequirePackage { graphicx}
2015-12-21 10:46:33 -08:00
\RequirePackage { newtxmath}
2016-01-26 15:15:17 -08:00
\RequirePackage { mathtools}
\RequirePackage { xspace}
2016-01-26 16:32:57 -08:00
\RequirePackage { url}
2016-02-01 14:11:36 -08:00
\RequirePackage { changepage}
2016-02-02 07:04:18 -08:00
\RequirePackage { lmodern}
2016-03-05 13:45:11 -08:00
\RequirePackage [unicode,bookmarksnumbered,bookmarksopen,pdfview=Fit] { hyperref}
2016-03-05 12:20:11 -08:00
\RequirePackage { nameref}
2016-03-07 13:05:45 -08:00
\RequirePackage { enumitem}
2016-03-17 18:20:44 -07:00
\RequirePackage { tabularx}
\RequirePackage { hhline}
2016-03-30 06:27:43 -07:00
\RequirePackage { comment}
2015-12-14 09:03:59 -08:00
\setlength { \oddsidemargin } { -0.25in} % Left margin of 1 in + 0 in = 1 in
\setlength { \textwidth } { 7in} % Right margin of 8.5 in - 1 in - 6.5 in = 1 in
\setlength { \topmargin } { -.75in} % Top margin of 2 in -0.75 in = 1 in
\setlength { \textheight } { 9.2in} % Lower margin of 11 in - 9 in - 1 in = 1 in
2016-01-28 16:00:21 -08:00
\setlength { \parskip } { 1.5ex}
\setlength { \parindent } { 0ex}
2016-03-17 18:20:44 -07:00
\renewcommand { \arraystretch } { 1.4}
2016-03-05 13:02:46 -08:00
\overfullrule =2cm
2015-12-14 09:03:59 -08:00
2016-03-07 13:05:45 -08:00
\setlist [itemize] { itemsep=0.5ex,topsep=0.2ex,after=\vspace { 1.5ex} }
2016-03-05 13:45:11 -08:00
\newcommand { \doctitle } { Zcash Protocol Specification}
2016-03-30 07:42:07 -07:00
\newcommand { \docversion } { Version 2.0-alpha-1}
2016-03-08 16:40:08 -08:00
\newcommand { \authors } { Sean Bowe | Daira Hopwood | Taylor Hornby | Nathan Wilcox}
2016-03-05 13:45:11 -08:00
\hypersetup {
pdfborderstyle={ /S/U/W 0.7} ,
pdfinfo={
Title={ \doctitle , \docversion } ,
Author={ \authors }
}
}
2016-03-05 12:20:11 -08:00
\renewcommand { \sectionautorefname } { \S \! }
\renewcommand { \subsectionautorefname } { \S \! }
\renewcommand { \subsubsectionautorefname } { \S \! }
2016-03-05 13:02:46 -08:00
\newcommand { \crossref } [1]{ \autoref { #1} \emph { `\nameref * { #1} \kern -0.1em'} on p.\, \pageref * { #1} }
2016-03-05 12:20:11 -08:00
2015-12-22 18:14:05 -08:00
\mathchardef \mhyphen ="2D
2016-02-11 07:04:56 -08:00
\RequirePackage [usenames,dvipsnames] { xcolor}
% https://en.wikibooks.org/wiki/LaTeX/Colors#The_68_standard_colors_known_to_dvips
\newcommand { \eli } [1]{ { \color { JungleGreen} \sf { Eli: #1} } }
\newcommand { \sean } [1]{ { \color { blue} \sf { Sean: #1} } }
\newcommand { \taylor } [1]{ { \color { red} \sf { Taylor: #1} } }
\newcommand { \daira } [1]{ { \color { RedOrange} \sf { Daira: #1} } }
\newcommand { \nathan } [1]{ { \color { ForestGreen} \sf { Nathan: #1} } }
\newcommand { \todo } [1]{ { \color { Sepia} \sf { TODO: #1} } }
\newcommand { \changedcolor } { magenta}
\newcommand { \setchanged } { \color { \changedcolor } }
2016-03-05 12:20:11 -08:00
\newcommand { \changed } [1]{ \texorpdfstring { { \setchanged { #1} } } { #1} }
2016-02-11 07:04:56 -08:00
2015-12-14 09:03:59 -08:00
% terminology
2016-01-26 15:15:17 -08:00
\newcommand { \term } [1]{ \textsl { #1} \xspace }
2016-03-18 14:09:24 -07:00
\newcommand { \titleterm } [1]{ #1\xspace }
2016-01-26 15:15:17 -08:00
\newcommand { \termbf } [1]{ \textbf { #1} \xspace }
2016-02-16 11:49:37 -08:00
\newcommand { \conformance } [1]{ \textmd { #1} \xspace }
2016-01-26 15:15:17 -08:00
\newcommand { \Zcash } { \termbf { Zcash} }
\newcommand { \Zerocash } { \termbf { Zerocash} }
2016-01-26 15:36:29 -08:00
\newcommand { \Bitcoin } { \termbf { Bitcoin} }
2016-01-26 15:15:17 -08:00
\newcommand { \ZEC } { \termbf { ZEC} }
\newcommand { \zatoshi } { \term { zatoshi} }
2016-02-16 11:49:37 -08:00
\newcommand { \MUST } { \conformance { MUST} }
\newcommand { \MUSTNOT } { \conformance { MUST NOT} }
\newcommand { \SHOULD } { \conformance { SHOULD} }
\newcommand { \SHOULDNOT } { \conformance { SHOULD NOT} }
\newcommand { \MAY } { \conformance { MAY} }
2016-03-28 18:28:07 -07:00
\newcommand { \note } { \term { note} }
\newcommand { \notes } { \term { notes} }
\newcommand { \Note } { Note}
\newcommand { \Notes } { Notes}
\newcommand { \noteCommitment } { \term { note commitment} }
\newcommand { \noteCommitments } { \term { note commitments} }
\newcommand { \NoteCommitment } { \titleterm { Note Commitment} }
\newcommand { \NoteCommitments } { \titleterm { Note Commitments} }
\newcommand { \noteCommitmentTree } { \term { note commitment tree} }
2016-03-28 18:28:50 -07:00
\newcommand { \joinSplitDescription } { \term { JoinSplit description} }
\newcommand { \joinSplitDescriptions } { \term { JoinSplit descriptions} }
\newcommand { \sequenceOfJoinSplitDescriptions } { \changed { sequence of} \joinSplitDescription \changed { \term { s} } \xspace }
\newcommand { \joinSplitTransfer } { \term { JoinSplit operation} }
\newcommand { \joinSplitTransfers } { \term { JoinSplit operations} }
\newcommand { \JoinSplitTransfer } { \titleterm { JoinSplit Operation} }
\newcommand { \JoinSplitTransfers } { \titleterm { JoinSplit Operations} }
2016-03-30 07:18:50 -07:00
\newcommand { \joinSplitSignature } { \term { JoinSplit signature} }
2016-01-26 15:15:17 -08:00
\newcommand { \fullnode } { \term { full node} }
\newcommand { \fullnodes } { \term { full nodes} }
\newcommand { \anchor } { \term { anchor} }
\newcommand { \anchors } { \term { anchors} }
\newcommand { \block } { \term { block} }
\newcommand { \blocks } { \term { blocks} }
\newcommand { \transaction } { \term { transaction} }
\newcommand { \transactions } { \term { transactions} }
\newcommand { \blockchainview } { \term { blockchain view} }
\newcommand { \mempool } { \term { mempool} }
\newcommand { \treestate } { \term { treestate} }
\newcommand { \treestates } { \term { treestates} }
2016-03-29 17:36:34 -07:00
\newcommand { \nullifier } { \term { nullifier} }
\newcommand { \nullifiers } { \term { nullifiers} }
\newcommand { \Nullifier } { \titleterm { Nullifier} }
\newcommand { \Nullifiers } { \titleterm { Nullifiers} }
\newcommand { \nullifierSet } { \term { nullifier set} }
\newcommand { \NullifierSet } { \titleterm { Nullifier Set} }
2016-02-16 12:07:31 -08:00
% Daira: This doesn't adequately distinguish between zk stuff and transparent stuff
\newcommand { \paymentAddress } { \term { payment address} }
\newcommand { \paymentAddresses } { \term { payment addresses} }
\newcommand { \viewingKey } { \term { viewing key} }
\newcommand { \viewingKeys } { \term { viewing keys} }
\newcommand { \spendingKey } { \term { spending key} }
\newcommand { \spendingKeys } { \term { spending keys} }
\newcommand { \keyTuple } { \term { key tuple} }
2016-03-28 18:28:07 -07:00
\newcommand { \notePlaintext } { \term { note plaintext} }
\newcommand { \notePlaintexts } { \term { note plaintexts} }
\newcommand { \NotePlaintexts } { \titleterm { Note Plaintexts} }
\newcommand { \notesCiphertext } { \term { transmitted notes ciphertext} }
2016-02-16 12:07:31 -08:00
\newcommand { \authKeypair } { \term { authorization} }
\newcommand { \transmitKeypair } { \term { transmission} }
2016-02-16 17:57:21 -08:00
\newcommand { \discloseKey } { \term { disclosure key} }
2016-01-26 15:15:17 -08:00
\newcommand { \incrementalMerkleTree } { \term { incremental merkle tree} }
2016-01-26 16:34:42 -08:00
\newcommand { \zkSNARK } { \term { zk-SNARK} }
\newcommand { \zkSNARKs } { \term { zk-SNARKs} }
2016-02-01 14:11:36 -08:00
\newcommand { \memo } { \term { memo field} }
2016-03-18 14:09:24 -07:00
\newcommand { \Memos } { \titleterm { Memo Fields} }
2016-01-26 15:15:17 -08:00
2016-03-06 19:38:00 -08:00
% conventions
\newcommand { \bytes } [1]{ \underline { \raisebox { -0.22ex} { } \smash { #1} } }
\newcommand { \zeros } [1]{ [0]^ { #1} }
\newcommand { \hexint } [1]{ \mathbf { 0x{ #1} } }
\newcommand { \dontcare } { \kern -0.06em\raisebox { 0.1ex} { \footnotesize { $ \times $ } } }
2016-03-29 19:28:01 -07:00
\newcommand { \ascii } [1]{ \mathbf { ``{ #1} "} }
2016-03-06 19:38:00 -08:00
\newcommand { \CRH } { \mathsf { CRH} }
\newcommand { \CRHbox } [1]{ \CRH \left (\; \raisebox { -1.3ex} { \usebox { #1} } \; \right )}
2016-03-22 10:41:57 -07:00
\newcommand { \SHA } { \mathtt { SHA256Compress} }
\newcommand { \SHAName } { \term { SHA-256 compression} }
2016-03-06 19:38:00 -08:00
\newcommand { \FullHash } { \mathtt { SHA256} }
2016-03-22 10:41:57 -07:00
\newcommand { \FullHashName } { \term { SHA-256} }
2016-03-29 19:28:01 -07:00
\newcommand { \BlakeHash } { \mathtt { BLAKE2b} }
\newcommand { \BlakeHashName } { \term { BLAKE2b} }
2016-03-06 19:38:00 -08:00
\newcommand { \FullHashbox } [1]{ \FullHash \left (\; \raisebox { -1.3ex} { \usebox { #1} } \; \right )}
2016-03-29 19:28:01 -07:00
\newcommand { \BlakeHashbox } [2]{ \BlakeHash \left ({ #1} ,\; \raisebox { -1.3ex} { \usebox { #2} } \; \right )}
2016-03-06 19:38:00 -08:00
\newcommand { \Justthebox } [2]{ \; \raisebox { #2} { \usebox { #1} } \; }
2016-03-06 20:36:29 -08:00
\newcommand { \setof } [1]{ \{ { #1} \} }
2016-03-28 17:16:06 -07:00
\newcommand { \minimum } { \mathsf { min} }
2016-03-06 19:38:00 -08:00
2015-12-22 15:24:24 -08:00
% key pairs:
2016-02-16 12:07:31 -08:00
\newcommand { \PaymentAddress } { \mathsf { addr_ { pk} } }
\newcommand { \SpendingKey } { \mathsf { addr_ { sk} } }
2016-03-06 19:38:00 -08:00
\newcommand { \PaymentAddressLeadByte } { \hexint { 92} }
\newcommand { \SpendingKeyLeadByte } { \hexint { ??} }
2016-03-29 19:47:57 -07:00
\newcommand { \NotePlaintextLeadByte } { \hexint { 00} }
2016-02-16 12:07:31 -08:00
\newcommand { \AuthPublic } { \mathsf { a_ { pk} } }
2016-02-25 13:42:00 -08:00
\newcommand { \AuthPrivate } { \mathsf { a_ { sk} } }
2016-02-16 12:07:31 -08:00
\newcommand { \AuthPublicOld } [1]{ \mathsf { a^ { old} _ { pk,\mathnormal { #1} } } }
\newcommand { \AuthPrivateOld } [1]{ \mathsf { a^ { old} _ { sk,\mathnormal { #1} } } }
\newcommand { \AuthPublicNew } [1]{ \mathsf { a^ { new} _ { pk,\mathnormal { #1} } } }
\newcommand { \AuthPrivateNew } [1]{ \mathsf { a^ { new} _ { sk,\mathnormal { #1} } } }
\newcommand { \AddressPublicNew } [1]{ \mathsf { addr^ { new} _ { pk,\mathnormal { #1} } } }
\newcommand { \enc } { \mathsf { enc} }
\newcommand { \disclose } { \mathsf { disclose} }
2016-02-25 09:13:31 -08:00
\newcommand { \shared } { \mathsf { shared} }
\newcommand { \DHSecret } [1]{ \mathsf { dhsecret} _ { #1} }
2016-03-06 02:34:34 -08:00
\newcommand { \DHSecretCompare } [1]{ \mathsf { dhsecret} ^ *_ { #1} }
2016-02-16 17:57:21 -08:00
\newcommand { \EphemeralPublic } { \mathsf { epk} }
2016-02-27 13:14:39 -08:00
\newcommand { \EphemeralPublicCompare } { \mathsf { epk} ^ *}
2016-02-16 17:57:21 -08:00
\newcommand { \EphemeralPrivate } { \mathsf { esk} }
2016-03-06 02:34:34 -08:00
\newcommand { \EphemeralPrivateClamped } { \mathsf { esk_ { clamped} } }
2016-02-16 17:57:21 -08:00
\newcommand { \TransmitPublic } { \mathsf { pk_ { enc} } }
2016-02-16 12:07:31 -08:00
\newcommand { \TransmitPublicNew } [1]{ \mathsf { pk^ { new} _ { \enc ,\mathnormal { #1} } } }
2016-02-16 17:57:21 -08:00
\newcommand { \TransmitPrivate } { \mathsf { sk_ { enc} } }
2015-12-14 09:03:59 -08:00
\newcommand { \Value } { \mathsf { v} }
2016-02-25 13:42:00 -08:00
\newcommand { \ValueNew } [1]{ \mathsf { v^ { new} _ \mathnormal { #1} } }
2016-01-26 15:15:17 -08:00
2016-03-30 07:18:50 -07:00
% Notes
2016-03-28 18:28:07 -07:00
\newcommand { \NoteTuple } [1]{ \mathbf { n} _ { #1} }
\newcommand { \NotePlaintext } [1]{ \mathbf { np} _ { #1} }
\newcommand { \NoteCommitRand } { \mathsf { r} }
\newcommand { \NoteCommitRandOld } [1]{ \mathsf { r^ { old} _ \mathnormal { #1} } }
\newcommand { \NoteCommitRandNew } [1]{ \mathsf { r^ { new} _ \mathnormal { #1} } }
\newcommand { \NoteAddressRand } { \mathsf { \uprho } }
\newcommand { \NoteAddressRandOld } [1]{ \mathsf { \uprho ^ { old} _ \mathnormal { #1} } }
\newcommand { \NoteAddressRandNew } [1]{ \mathsf { \uprho ^ { new} _ \mathnormal { #1} } }
\newcommand { \NoteAddressPreRand } { \mathsf { \upvarphi } }
\newcommand { \NoteCommitS } { \mathsf { s} }
2016-03-29 17:36:34 -07:00
\newcommand { \nf } { \mathsf { nf} }
\newcommand { \nfOld } [1]{ \nf ^ \mathsf { old} _ \mathnormal { #1} }
2016-03-29 19:28:01 -07:00
\newcommand { \hSigtag } { \mathsf { hSigtag} }
2016-02-01 14:11:36 -08:00
\newcommand { \Memo } { \mathsf { memo} }
2016-02-25 09:13:31 -08:00
\newcommand { \CurveMultiply } { \mathsf { Curve25519} }
2016-03-06 15:26:40 -08:00
\newcommand { \CurveBase } { \bytes { 9} }
2016-03-20 13:37:43 -07:00
\newcommand { \DecryptNote } { \mathtt { DecryptNote} }
2016-02-25 09:13:31 -08:00
\newcommand { \Plaintext } { \mathbf { P} }
\newcommand { \Ciphertext } { \mathbf { C} }
\newcommand { \Key } { \mathsf { K} }
\newcommand { \TransmitPlaintext } [1]{ \Plaintext ^ \enc _ { #1} }
\newcommand { \TransmitCiphertext } [1]{ \Ciphertext ^ \enc _ { #1} }
\newcommand { \TransmitKey } [1]{ \Key ^ \enc _ { #1} }
2016-02-25 13:42:00 -08:00
\newcommand { \TransmitKeyCompare } [1]{ \Key ^ *_ { #1} }
2016-02-25 17:56:04 -08:00
\newcommand { \DerivedKey } [1]{ \Key ^ \disclose _ { #1} }
2016-02-29 06:19:35 -08:00
\newcommand { \DisclosePlaintext } [1]{ \Plaintext ^ \disclose _ { #1} }
2016-02-25 09:13:31 -08:00
\newcommand { \DiscloseCiphertext } [1]{ \Ciphertext ^ \disclose _ { #1} }
2016-03-02 08:09:52 -08:00
\newcommand { \SharedPlaintext } { \Plaintext ^ \shared }
2016-02-25 09:13:31 -08:00
\newcommand { \KDF } { \mathsf { KDF} }
2016-03-29 19:28:01 -07:00
\newcommand { \kdftag } { \mathsf { kdftag} }
\newcommand { \kdfinput } { \mathsf { kdfinput} }
2016-02-25 09:13:31 -08:00
\newcommand { \SymEncrypt } [1]{ \mathsf { SymEncrypt} _ { #1} }
\newcommand { \SymDecrypt } [1]{ \mathsf { SymDecrypt} _ { #1} }
\newcommand { \SymSpecific } { \mathsf { AEAD\_ CHACHA20\_ POLY1305} }
2016-02-27 12:58:39 -08:00
\newcommand { \SymCipher } { \mathsf { ChaCha20} }
\newcommand { \SymAuth } { \mathsf { Poly1305} }
2016-02-25 09:13:31 -08:00
\newcommand { \Clamp } { \mathsf { clamp_ { Curve25519} } }
2016-01-26 15:15:17 -08:00
\newcommand { \PRF } [2]{ \mathsf { { PRF} ^ { #2} _ \mathnormal { #1} } }
2015-12-14 09:03:59 -08:00
\newcommand { \PRFaddr } [1]{ \PRF { #1} { addr} }
2016-03-29 17:36:34 -07:00
\newcommand { \PRFnf } [1]{ \PRF { #1} { \nf } }
2016-01-27 05:21:11 -08:00
\newcommand { \PRFpk } [1]{ \PRF { #1} { pk} }
2016-03-28 18:28:07 -07:00
\newcommand { \PRFrho } [1]{ \PRF { #1} { \NoteAddressRand } }
2016-02-25 17:56:04 -08:00
\newcommand { \PRFdk } [1]{ \PRF { #1} { dk} }
2016-01-26 15:15:17 -08:00
\newcommand { \cm } { \mathsf { cm} }
\newcommand { \cmNew } [1]{ \mathsf { { cm} ^ { new} _ \mathnormal { #1} } }
2016-03-30 06:27:43 -07:00
\newcommand { \LeadingBytes } [1]{ \mathtt { LeadingBytes} _ { #1} }
2016-02-01 14:11:36 -08:00
\newcommand { \ReplacementCharacter } { \textsf { U+FFFD} }
2016-02-25 13:42:00 -08:00
\newcommand { \CryptoBoxSeal } { \mathsf { crypto\_ box\_ seal} }
2016-03-15 16:20:17 -07:00
\newcommand { \ECDSAr } { \mathsf { r} }
\newcommand { \ECDSAs } { \mathsf { s} }
2016-01-26 15:15:17 -08:00
2015-12-14 09:03:59 -08:00
% merkle tree
\newcommand { \MerkleDepth } { \mathsf { d} }
2016-01-26 15:15:17 -08:00
2015-12-14 09:03:59 -08:00
% bitcoin
\newcommand { \vin } { \mathtt { vin} }
\newcommand { \vout } { \mathtt { vout} }
2016-03-28 18:28:50 -07:00
\newcommand { \nJoinSplit } { \mathtt { nJoinSplit} }
\newcommand { \vJoinSplit } { \mathtt { vJoinSplit} }
2016-01-26 15:15:17 -08:00
\newcommand { \vpubOldField } { \mathtt { vpub\_ old} }
\newcommand { \vpubNewField } { \mathtt { vpub\_ new} }
\newcommand { \vsum } [2]{ \smashoperator [r] { \sum _ { #1} ^ { #2} } }
\newcommand { \anchorField } { \mathtt { anchor} }
2016-03-28 18:28:50 -07:00
\newcommand { \joinSplitSig } { \mathtt { joinSplitSig} }
\newcommand { \joinSplitPubKey } { \mathtt { joinSplitPubKey} }
2016-03-15 18:36:37 -07:00
\newcommand { \dataToBeSigned } { \mathtt { dataToBeSigned} }
2016-03-29 17:36:34 -07:00
\newcommand { \nullifiersField } { \mathtt { nullifiers} }
2015-12-14 09:03:59 -08:00
\newcommand { \commitments } { \mathtt { commitments} }
2016-02-16 17:57:21 -08:00
\newcommand { \ephemeralKey } { \mathtt { ephemeralKey} }
2016-02-16 12:07:31 -08:00
\newcommand { \encCiphertexts } { \mathtt { encCiphertexts} }
2016-02-25 15:38:31 -08:00
\newcommand { \randomSeed } { \mathtt { randomSeed} }
2015-12-14 09:03:59 -08:00
\newcommand { \rt } { \mathsf { rt} }
2016-03-17 18:20:44 -07:00
\newcommand { \Varies } { \textit { Varies} }
\newcommand { \heading } [1]{ \multicolumn { 1} { c|} { #1} }
\newcommand { \type } [1]{ \texttt { #1} }
2016-01-26 15:15:17 -08:00
2016-03-30 07:18:50 -07:00
\newcommand { \sighashType } { \term { SIGHASH type} }
\newcommand { \sighashTypes } { \term { SIGHASH types} }
\newcommand { \SIGHASHALL } { \mathsf { SIGHASH\_ ALL} }
\newcommand { \scriptSig } { \mathtt { scriptSig} }
2016-03-28 18:28:50 -07:00
% JoinSplit
2015-12-14 09:03:59 -08:00
\newcommand { \hSig } { \mathsf { h_ { Sig} } }
2016-03-15 16:23:05 -07:00
\newcommand { \hSigText } { \texorpdfstring { $ \hSig $ } { hSig} }
2016-01-26 15:15:17 -08:00
\newcommand { \h } [1]{ \mathsf { h_ { \mathnormal { #1} } } }
\newcommand { \NOld } { \mathrm { N} ^ \mathsf { old} }
\newcommand { \NNew } { \mathrm { N} ^ \mathsf { new} }
2016-03-06 20:36:29 -08:00
\newcommand { \allN } [1]{ \mathrm { 1} ..\mathrm { N} ^ \mathsf { #1} }
\newcommand { \allOld } { \allN { old} }
\newcommand { \allNew } { \allN { new} }
\newcommand { \setofOld } { \setof { \allOld } }
\newcommand { \setofNew } { \setof { \allNew } }
2015-12-14 09:03:59 -08:00
\newcommand { \vmacs } { \mathtt { vmacs} }
2016-03-17 18:20:44 -07:00
\newcommand { \zkproofSize } { \mathtt { zkproofSize} }
2015-12-14 09:03:59 -08:00
\newcommand { \zkproof } { \mathtt { zkproof} }
2016-03-28 18:28:50 -07:00
\newcommand { \JoinSplitCircuit } { \term { \texttt { JoinSplit} circuit} }
\newcommand { \JoinSplitStatement } { \texttt { JoinSplit} }
\newcommand { \JoinSplitProof } { \pi _ { \JoinSplitStatement } }
2016-01-26 15:15:17 -08:00
\newcommand { \vpubOld } { \mathsf { v_ { pub} ^ { old} } }
\newcommand { \vpubNew } { \mathsf { v_ { pub} ^ { new} } }
2016-03-18 14:09:24 -07:00
\newcommand { \cOld } [1]{ \mathbf { n} _ { #1} ^ \mathsf { old} }
\newcommand { \cNew } [1]{ \mathbf { n} _ { #1} ^ \mathsf { new} }
\newcommand { \cpNew } [1]{ \mathbf { np} _ { #1} ^ \mathsf { new} }
2016-01-26 15:15:17 -08:00
\newcommand { \vOld } [1]{ \mathsf { v} _ { #1} ^ \mathsf { old} }
\newcommand { \vNew } [1]{ \mathsf { v} _ { #1} ^ \mathsf { new} }
2015-12-14 09:03:59 -08:00
\newcommand { \NP } { \mathsf { NP} }
2016-01-26 16:32:57 -08:00
\newcommand { \treepath } [1]{ \mathsf { path} _ { #1} }
2016-01-26 15:15:17 -08:00
\newcommand { \COMM } [1]{ \mathsf { COMM} _ { #1} }
2016-01-26 16:34:42 -08:00
\newcommand { \COMMtrapdoor } { \term { \textsf { COMM} trapdoor} }
2016-03-18 14:09:24 -07:00
\newcommand { \Commitment } { \mathtt { NoteCommitment} }
2016-02-25 09:13:31 -08:00
\newcommand { \Receive } { \mathsf { Receive} }
2015-12-14 09:03:59 -08:00
2015-12-16 14:17:28 -08:00
2015-12-14 09:03:59 -08:00
\begin { document}
2016-03-05 13:45:11 -08:00
\title { \doctitle \\
\Large \docversion }
\author { \authors }
2015-12-14 09:03:59 -08:00
\date { \today }
\maketitle
2016-02-11 10:54:23 -08:00
\tableofcontents
\newpage
2015-12-14 09:03:59 -08:00
\section { Introduction}
2016-03-31 01:00:04 -07:00
\eli { A few general comments that will re-appear numerous times:
\begin { itemize}
\item The ``intended usage'' explanations are confusing: What happens if some player does not play as intended? Suggest using standard Crypto terminology: the algorithms specified in the paper refer to the \emph { honest} player(s). Any deviation is treated non-honest. Some
deviations harm only their perpetrator, and we should state this;
other deviations threaten other honest players
and we should explain how these are mitigated.
\item Suggest having two separate parts: first (i) an abstract functionality, stated in terms
of crypto primitives with a paramaterized security parameter, and (ii)
concrete instantiations. I'll call these ``abstract'' and ``instantiation'' later on.
\end { itemize}
}
2016-01-26 16:49:13 -08:00
\Zcash is an implementation of the \term { Decentralized Anonymous Payment}
scheme \Zerocash \cite { ZerocashOakland} with some adjustments to terminology,
2016-01-26 15:15:17 -08:00
functionality and performance. It bridges the existing \emph { transparent}
2016-01-26 16:49:13 -08:00
payment scheme used by \Bitcoin with a \emph { confidential} payment scheme
2016-01-26 15:15:17 -08:00
protected by zero-knowledge succinct non-interactive arguments of knowledge
2016-01-26 16:34:42 -08:00
(\zkSNARKs ).
2015-12-14 09:03:59 -08:00
2016-03-12 18:16:30 -08:00
Changes from the original \Zerocash are highlighted in \changed { \changedcolor } .
2016-02-11 07:04:56 -08:00
2016-02-25 10:32:18 -08:00
2016-02-16 11:49:37 -08:00
\section { Caution}
2016-03-31 01:00:04 -07:00
\eli { Should this section appear in this paper? This paper describes \emph { our implementation} so what does divergence mean? Perhaps this refers to non-honest players?}
2016-02-16 11:49:37 -08:00
\Zcash security depends on consensus. Should your program diverge from
consensus, its security is weakened or destroyed. The cause of the divergence
doesn't matter: it could be a bug in your program, it could be an error in
this documentation which you implemented as described, or it could be you do
everything right but other software on the network behaves unexpectedly. The
specific cause will not matter to the users of your software whose wealth is
lost.
2016-03-31 01:00:04 -07:00
\eli { I don't understand what indended behavior means?
This paper specifies how an \emph { honest player} should act, and whenever
there's deviation we should have something that mitigates it.}
2016-02-16 11:49:37 -08:00
Having said that, a specification of \emph { intended} behaviour is essential
for security analysis, understanding of the protocol, and maintenance of
Zcash Core and related software. If you find any mistake in this specification,
2016-02-25 15:41:47 -08:00
please contact \texttt { <security@z.cash>} . While the production \Zcash network
has yet to be launched, please feel free to do so in public even if you believe
the mistake may indicate a security weakness.
2016-02-16 11:49:37 -08:00
2016-02-25 10:32:18 -08:00
2016-02-25 09:13:31 -08:00
\section { Conventions}
2015-12-14 09:03:59 -08:00
2016-01-28 16:10:30 -08:00
\subsection { Integers, Bit Sequences, and Endianness}
2016-03-31 01:00:04 -07:00
\eli { Suggest this subsection be moved to ``instantiation''}
2015-12-14 09:03:59 -08:00
2016-03-06 14:19:12 -08:00
All integers in \emph { \Zcash -specific} encodings are unsigned, have a fixed
2016-03-30 06:27:43 -07:00
bit length, and are encoded in little-endian byte order. \changed { The definition of
2016-03-06 14:19:12 -08:00
the encryption scheme based on $ \SymSpecific $ \cite { rfc7539} in \crossref { inband}
uses length fields encoded as little-endian. Also, Curve25519 public and
2016-03-06 19:38:00 -08:00
private keys are defined as byte sequences, which are converted from integers
2016-03-06 14:19:12 -08:00
using little-endian encoding.}
2015-12-14 09:03:59 -08:00
2016-03-06 19:38:00 -08:00
The notation $ \hexint { } $ followed by a string of \textbf { boldface} hexadecimal
digits represents the corresponding integer converted from hexadecimal.
2016-03-29 19:28:01 -07:00
The notation $ \ascii { ... } $ represents the given string represented as a
sequence of bytes in US-ASCII. For example, $ \ascii { abc } $ represents the
byte sequence $ [ \hexint { 61 } , \hexint { 62 } , \hexint { 63 } ] $ .
2016-01-28 14:33:13 -08:00
In bit layout diagrams, each box of the diagram represents a sequence of bits.
2016-03-06 19:38:00 -08:00
The bit length is given explicitly in each box, except for the case of a single
bit, or for the notation $ \zeros { n } $ which represents the sequence of $ n $ zero bits.
2016-03-30 06:27:43 -07:00
2016-03-30 18:21:43 -07:00
The entire diagram represents the sequence of \emph { bytes} formed by first
concatenating these bit sequences, and then treating each subsequence of 8 bits
as a byte with the bits ordered from \emph { most significant} to
\emph { least significant} . Thus the \emph { most significant} bit in each byte
is toward the left of a diagram. Where bit fields are used, the text will
clarify their position in each case.
2016-03-30 06:27:43 -07:00
\begin { comment}
\todo { Update example for big-bit-endian order.}
2016-01-28 14:33:13 -08:00
2016-03-20 16:19:38 -07:00
\newsavebox { \exampleabox }
\begin { lrbox} { \exampleabox }
2016-03-06 19:38:00 -08:00
\setchanged
2016-03-20 16:19:38 -07:00
\begin { bytefield} [bitwidth=1.3em]{ 32}
\bitbox { 1} { 0} &
\bitbox { 1} { 1} &
\bitbox { 1} { 0} &
\bitbox { 1} { 0} &
2016-03-06 19:38:00 -08:00
\bitbox { 16} { 16 bit $ \hexint { ABCD } $ } &
2016-03-20 16:19:38 -07:00
\bitbox { 12} { 12 bit $ \hexint { 123 } $ } &
2016-03-06 19:38:00 -08:00
\end { bytefield}
\end { lrbox}
2016-03-20 16:19:38 -07:00
\newsavebox { \examplebbox }
\begin { lrbox} { \examplebbox }
\setchanged
\begin { bytefield} [bitwidth=1.3em]{ 32}
\bitbox { 4} { 4 bit $ \hexint { 2 } $ } &
\bitbox { 4} { 4 bit $ \hexint { D } $ } &
\bitbox { 4} { 4 bit $ \hexint { C } $ } &
\bitbox { 4} { 4 bit $ \hexint { B } $ } &
\bitbox { 4} { 4 bit $ \hexint { A } $ } &
\bitbox { 4} { 4 bit $ \hexint { 3 } $ } &
\bitbox { 4} { 4 bit $ \hexint { 2 } $ } &
\bitbox { 4} { 4 bit $ \hexint { 1 } $ } &
\end { bytefield}
\end { lrbox}
\newsavebox { \examplecbox }
\begin { lrbox} { \examplecbox }
\setchanged
\begin { bytefield} [bitwidth=1.3em]{ 32}
\bitbox { 8} { 8 bit $ \hexint { D 2 } $ } &
\bitbox { 8} { 8 bit $ \hexint { BC } $ } &
2016-03-23 06:28:17 -07:00
\bitbox { 8} { 8 bit $ \hexint { 3 A } $ } &
2016-03-20 16:19:38 -07:00
\bitbox { 8} { 8 bit $ \hexint { 12 } $ } &
\end { bytefield}
\end { lrbox}
For example, the following diagrams are all equivalent:
2016-03-06 19:38:00 -08:00
\begin { itemize}
2016-03-20 16:19:38 -07:00
\item [] $ \Justthebox { \exampleabox } { - 1 . 3 ex } $
\item [] $ \Justthebox { \examplebbox } { - 1 . 3 ex } $
\item [] $ \Justthebox { \examplecbox } { - 1 . 3 ex } $
2016-03-06 19:38:00 -08:00
\end { itemize}
2016-03-23 06:28:17 -07:00
and represent the byte sequence $ [ \hexint { D 2 } , \hexint { BC } , \hexint { 3 A } , \hexint { 12 } ] $ .
2016-03-30 06:27:43 -07:00
\end { comment}
2016-01-28 16:10:30 -08:00
2016-03-30 06:27:43 -07:00
$ \LeadingBytes { k } ( x ) $ , where $ k $ is an integer, returns the leading (initial)
$ k $ bytes of $ x $ .
2016-03-22 10:41:57 -07:00
2016-03-06 20:36:29 -08:00
The notation $ \allN { } $ , used as a subscript, means the sequence of values
2016-02-25 09:12:28 -08:00
with indices $ 1 $ through $ \mathrm { N } $ inclusive. For example,
2016-03-06 20:36:29 -08:00
$ \AuthPublicNew { \allNew } $ means the sequence $ [ \AuthPublicNew { \mathrm { 1 } } ,
2016-02-25 09:12:28 -08:00
\AuthPublicNew { \mathrm { 2} } , ...\; \AuthPublicNew { \NNew } ]$ .
2016-03-03 06:01:39 -08:00
The symbol $ \bot $ is used to indicate unavailable information or a failed decryption.
2015-12-14 09:03:59 -08:00
\subsection { Cryptographic Functions}
2016-03-31 01:00:04 -07:00
\eli { Would be good to start with ``abstract'', using only a single security parameter $ \lambda $ and multiples of it, and then in ``instantiations'' have
the specific details. In more detail, in ``abstract'' we'll have
only $ \CRH $ with security $ \lambda $ , and multiple $ \PRF { a } { b } $ 's all with same (?) security $ \lambda $ , and we demand that the PRFs are ``computationally pairwise independent'', i.e.,
$ \PRF { a } { b } $ is pseudorandom given $ \PRF { a' } { b' } $ whenever
$ ( a,b ) \neq ( a',b' ) $ .}
2016-01-26 15:15:17 -08:00
$ \CRH $ is a collision-resistant hash function. In \Zcash , the $ \SHAName $ function
is used which takes a 512-bit block and produces a 256-bit hash. This is
2016-03-22 10:41:57 -07:00
different from the $ \FullHashName $ function, which hashes arbitrary-length sequences.
\cite { sha2}
2015-12-14 09:03:59 -08:00
2016-03-12 18:16:30 -08:00
$ \PRF { x } { } $ is a pseudo-random function seeded by $ x $ . \changed { Four} \emph { independent}
2016-03-29 17:36:34 -07:00
$ \PRF { x } { } $ are needed in our scheme: $ \PRFaddr { x } $ , $ \PRFnf { x } $ , $ \PRFpk { x } $ \changed { ,
2016-03-12 18:16:30 -08:00
and $ \PRFrho { x } $ } .
2016-02-25 17:56:04 -08:00
2016-03-29 17:36:34 -07:00
It is required that $ \PRFnf { x } $ \changed { and $ \PRFrho { x } $ } be collision-resistant
2016-02-25 17:56:04 -08:00
across all $ x $ --- i.e. it should not be feasible to find $ ( x, y ) \neq ( x', y' ) $
2016-03-31 01:00:04 -07:00
such that $ \PRFnf { x } ( y ) = \PRFnf { x' } ( y' ) $ \changed { , and similarly for $ \PRFrho { } $ } . \eli { we likely need more than just not having a collision. Likely
various bad things would happen if $ \PRF { x } { y } $ can be predicted given
$ \PRF { x' } { y' } $ . So we really need them to be pairwise distinct pseudorandom
functions.}
2016-01-26 16:33:48 -08:00
2016-03-03 10:43:10 -08:00
In \Zcash , the $ \SHAName $ function is used to construct all of these
2016-03-29 19:28:01 -07:00
functions.
2016-02-25 17:56:04 -08:00
2016-02-16 11:47:27 -08:00
\newcommand { \iminusone } { \hspace { 0.3pt} \scriptsize { $ i $ \hspace { 0.6pt} -1} }
2016-02-25 13:42:00 -08:00
\newsavebox { \addrbox }
\begin { lrbox} { \addrbox }
2016-02-25 09:13:31 -08:00
\setchanged
2016-02-26 08:36:59 -08:00
\begin { bytefield} [bitwidth=0.06em]{ 512}
2016-03-20 16:19:38 -07:00
\bitbox { 18} { 1} &
\bitbox { 18} { 1} &
2016-02-25 09:13:31 -08:00
\bitbox { 18} { 0} &
2016-02-26 08:36:59 -08:00
\bitbox { 18} { 0} &
2016-02-26 09:22:59 -08:00
\bitbox { 224} { 252 bit $ x $ } &
2016-03-28 17:18:53 -07:00
\bitbox { 56} { 8 bit $ t $ } &
\bitbox { 200} { $ \zeros { 248 } $ }
2015-12-14 09:03:59 -08:00
\end { bytefield}
2016-01-28 14:33:43 -08:00
\end { lrbox}
2016-03-29 17:36:34 -07:00
\newsavebox { \nfbox }
\begin { lrbox} { \nfbox }
2016-02-26 09:22:59 -08:00
\setchanged
2016-02-26 08:36:59 -08:00
\begin { bytefield} [bitwidth=0.06em]{ 512}
2016-03-06 14:21:48 -08:00
\bitbox { 18} { 1} &
2016-03-20 16:19:38 -07:00
\bitbox { 18} { 1} &
\bitbox { 18} { 1} &
2016-02-16 11:47:27 -08:00
\bitbox { 18} { 0} &
2016-02-26 09:22:59 -08:00
\bitbox { 224} { 252 bit $ \AuthPrivate $ } &
2016-03-28 18:28:07 -07:00
\bitbox { 256} { 256 bit $ \NoteAddressRand $ }
2015-12-14 09:03:59 -08:00
\end { bytefield}
2016-01-28 14:33:43 -08:00
\end { lrbox}
\newsavebox { \pkbox }
\begin { lrbox} { \pkbox }
2016-02-26 09:22:59 -08:00
\setchanged
2016-02-26 08:36:59 -08:00
\begin { bytefield} [bitwidth=0.06em]{ 512}
\bitbox { 18} { 0} &
2016-03-30 06:27:43 -07:00
\bitbox { 18} { \iminusone } &
2016-03-20 16:19:38 -07:00
\bitbox { 18} { 0} &
\bitbox { 18} { 0} &
2016-02-26 09:22:59 -08:00
\bitbox { 224} { 252 bit $ \AuthPrivate $ } &
2016-02-26 08:36:59 -08:00
\bitbox { 256} { 256 bit $ \hSig $ }
2016-01-28 14:33:43 -08:00
\end { bytefield}
\end { lrbox}
2015-12-14 09:03:59 -08:00
2016-02-07 14:37:36 -08:00
\newsavebox { \rhobox }
\begin { lrbox} { \rhobox }
2016-02-11 10:21:39 -08:00
\setchanged
2016-02-26 08:36:59 -08:00
\begin { bytefield} [bitwidth=0.06em]{ 512}
2016-03-20 16:19:38 -07:00
\bitbox { 18} { 0} &
2016-03-30 06:27:43 -07:00
\bitbox { 18} { \iminusone } &
2016-02-16 11:47:27 -08:00
\bitbox { 18} { 1} &
2016-02-26 08:36:59 -08:00
\bitbox { 18} { 0} &
2016-03-28 18:28:07 -07:00
\bitbox { 224} { 252 bit $ \NoteAddressPreRand $ } &
2016-02-26 08:36:59 -08:00
\bitbox { 256} { 256 bit $ \hSig $ }
2016-02-07 14:37:36 -08:00
\end { bytefield}
\end { lrbox}
2015-12-14 09:03:59 -08:00
\begin { equation*}
2016-01-28 14:33:43 -08:00
\begin { aligned}
2016-02-25 13:42:00 -08:00
& \setchanged \PRFaddr { x} (t) & \setchanged := \CRHbox { \addrbox } \\
2016-03-29 17:36:34 -07:00
\nf =\; & \PRFnf { \AuthPrivate } (\NoteAddressRand ) & := \CRHbox { \nfbox } \\
2016-02-25 13:42:00 -08:00
\h { i} =\; & \PRFpk { \AuthPrivate } (i, \hSig ) & := \CRHbox { \pkbox } \\
2016-03-28 18:28:07 -07:00
\setchanged \NoteAddressRandNew { i} =\; & \setchanged \PRFrho { \NoteAddressPreRand } (i, \hSig )
2016-03-12 18:16:30 -08:00
& \setchanged := \CRHbox { \rhobox }
2016-01-28 14:33:43 -08:00
\end { aligned}
2015-12-14 09:03:59 -08:00
\end { equation*}
2016-03-06 14:21:48 -08:00
\changed {
\subparagraph { Note:}
2016-03-30 06:27:43 -07:00
The first four bits --i.e. the most significant four bits of the first byte--
2016-03-20 16:19:38 -07:00
are used to distinguish different uses of $ \CRH $ , ensuring that the functions
2016-03-30 06:27:43 -07:00
are independent. In addition to the inputs shown here, the bits $ \mathtt { 1011 } $
2016-03-29 19:28:01 -07:00
in this position are used to distinguish uses of the full $ \FullHashName $ hash
function --- see \crossref { comm} .
2016-03-20 16:19:38 -07:00
(The specific bit patterns chosen here are motivated by the possibility of future
extensions that either increase $ \NOld $ and/or $ \NNew $ to 3, or that add an
additional bit to $ \AuthPrivate $ to encode a new key type, or that require an
additional PRF.)
2016-03-29 19:28:01 -07:00
$ \BlakeHashName $ is also used to construct a Key Derivation Function and as a
hash function for the computation of $ \hSig $ . The notation $ \BlakeHash ( p, x ) $
2016-03-30 18:21:43 -07:00
represents the application of unkeyed $ \BlakeHashName $ to a 16-byte personalization
string $ p $ and input $ x $ , as defined in \cite { blake2} .
2016-03-06 14:21:48 -08:00
}
2016-02-25 10:32:18 -08:00
\section { Concepts}
2016-03-12 18:16:30 -08:00
\subsection { Payment Addresses and Spending Keys}
2015-12-14 09:03:59 -08:00
2016-03-12 18:16:30 -08:00
A \keyTuple $ ( \SpendingKey , \PaymentAddress ) $ is
2016-03-31 01:00:04 -07:00
generated by users \eli { ``who wish to receive payments'' is an intended usage explanation, suggest removing} who wish to receive payments under this scheme.
The \paymentAddress $ \PaymentAddress $ is derived \eli { it's not clear what ``derived'' means, suggest putting the formal derivations right away here} from the \spendingKey
2016-03-12 18:16:30 -08:00
$ \SpendingKey $ .
2016-01-28 16:10:30 -08:00
2016-02-16 12:07:31 -08:00
The following diagram depicts the relations between key components.
2016-02-16 17:57:21 -08:00
Arrows point from a component to any other component(s) that can be derived
2016-03-31 01:00:04 -07:00
from it. \eli { formally, any $ a $ can be derived from any $ b $ as long as ``derived'' remains undefined, hence think the
derivation rule should be explicitly stated here}
2016-02-16 12:07:31 -08:00
\begin { center}
2016-02-16 17:57:21 -08:00
\includegraphics [scale=.8] { key_ components}
2016-02-16 12:07:31 -08:00
\end { center}
2016-03-31 01:00:04 -07:00
\eli { following sentence is an intended usage explanation, and its very confusing: what happens if a player deviates? will it ruin the system?
Additionally, its not clear what happens in our system, how is it ``not explosed to users''?}
2016-03-12 18:16:30 -08:00
The composition of \paymentAddresses and \spendingKeys
2016-02-16 12:07:31 -08:00
is a cryptographic protocol detail that should not normally be
2016-03-31 01:00:04 -07:00
exposed to users. However, user-visible operations \eli { what's a user-visible operation? what's an operation? how is it provided?} should be provided
2016-03-12 18:16:30 -08:00
to obtain a \paymentAddress or \viewingKey from a \spendingKey .
2015-12-17 08:34:46 -08:00
2016-03-12 18:16:30 -08:00
\changed { $ \AuthPrivate $ is 252 bits.}
2016-02-26 09:22:59 -08:00
$ \AuthPublic $ , $ \TransmitPrivate $ , and $ \TransmitPublic $ , are each 256 bits.
2016-02-25 13:42:00 -08:00
2016-03-12 18:16:30 -08:00
\changed { $ \AuthPublic $ , $ \TransmitPrivate $ and $ \TransmitPublic $ are derived
2016-03-31 01:00:04 -07:00
as follows: \eli { this be moved up. Additionally, the clamp/curve stuff is an ``instantiation'' and here we should have abstract PKC functionality (public key, private key)} }
2016-03-07 08:52:15 -08:00
{ \hfuzz =50pt
2016-02-25 09:13:31 -08:00
\begin { equation*}
\begin { aligned}
2016-03-12 18:16:30 -08:00
\AuthPublic & := \changed { \PRFaddr { \AuthPrivate } (0)} \\
\TransmitPrivate & := \changed { \Clamp (\PRFaddr { \AuthPrivate } (1))} \\
2016-03-03 10:43:10 -08:00
\TransmitPublic & := \changed { \CurveMultiply (\TransmitPrivate , \CurveBase )}
2016-02-25 09:13:31 -08:00
\end { aligned}
\end { equation*}
2016-03-05 13:02:46 -08:00
}
2016-02-25 09:13:31 -08:00
2016-03-03 10:43:10 -08:00
\changed {
2016-03-06 15:26:40 -08:00
where
\begin { itemize}
\item $ \CurveMultiply ( \bytes { n } , \bytes { q } ) $ performs point
multiplication of the Curve25519 public key represented by the byte
2016-03-06 19:38:00 -08:00
sequence $ \bytes { q } $ by the Curve25519 secret key represented by the
byte sequence $ \bytes { n } $ , as defined in section 2 of \cite { Curve25519} ;
\item $ \CurveBase $ is the public byte sequence representing the Curve25519
2016-03-06 15:26:40 -08:00
base point;
2016-03-06 19:38:00 -08:00
\item $ \Clamp ( \bytes { x } ) $ takes a 32-byte sequence $ \bytes { x } $ as input
and returns a byte sequence representing a Curve25519 private key, with
2016-03-06 15:26:40 -08:00
bits ``clamped'' as described in section 3 of \cite { Curve25519} :
``clear bits 0, 1, 2 of the first byte, clear bit 7 of the last byte,
and set bit 6 of the last byte.'' Here the bits of a byte are numbered
such that bit $ b $ has numeric weight $ 2 ^ b $ .
\end { itemize}
2016-02-25 09:13:31 -08:00
}
2016-02-16 17:57:21 -08:00
2016-03-31 01:00:04 -07:00
\eli { following paragraph talks about intended usage, hence confusing. }
2016-01-28 16:10:30 -08:00
Users can accept payment from multiple parties with a single
2016-02-16 12:07:31 -08:00
$ \PaymentAddress $ and the fact that these payments are destined to
2016-01-28 16:10:30 -08:00
the same payee is not revealed on the blockchain, even to the
paying parties. \emph { However} if two parties collude to compare a
2016-02-16 12:07:31 -08:00
$ \PaymentAddress $ they can trivially determine they are the same. In the
2016-01-28 16:10:30 -08:00
case that a payee wishes to prevent this they should create a distinct
2016-02-16 12:07:31 -08:00
\paymentAddress for each payer.
2015-12-14 09:03:59 -08:00
2016-03-28 18:28:07 -07:00
\subsection { \Notes }
2015-12-14 09:03:59 -08:00
2016-03-28 18:28:07 -07:00
A \note (denoted $ \NoteTuple { } $ ) is a tuple $ \changed { ( \AuthPublic , \Value ,
2016-03-31 01:00:04 -07:00
\NoteAddressRand , \NoteCommitRand )} $ \eli { shouldn't $ \NoteCommitRand $ be part of the note commitment, not the note? } which represents that a value $ \Value $ is
2016-02-27 12:38:58 -08:00
spendable by the recipient who holds the \spendingKey $ \AuthPrivate $ corresponding
to $ \AuthPublic $ , as described in the previous section.
2016-02-25 11:43:03 -08:00
2016-03-31 01:00:04 -07:00
\eli { following list mixes abstract and instantiation stuff}
2016-02-25 11:43:03 -08:00
\begin { itemize}
2016-03-31 01:00:04 -07:00
\item $ \AuthPublic $ is a 32-byte \authKeypair public key \eli { this should have been defined in the previous section} of the recipient.
2016-02-25 11:43:03 -08:00
\item $ \Value $ is a 64-bit unsigned integer representing the value of the
2016-03-28 18:28:07 -07:00
\note in \zatoshi (1 \ZEC = $ 10 ^ 8 $ \zatoshi ).
2016-03-29 17:36:34 -07:00
\item $ \NoteAddressRand $ is a 32-byte $ \PRFnf { \AuthPrivate } $ preimage.
2016-03-28 19:15:08 -07:00
\item $ \NoteCommitRand $ is a 32-byte \COMMtrapdoor .
2016-02-25 11:43:03 -08:00
\end { itemize}
2016-02-07 14:37:36 -08:00
2016-03-31 01:00:04 -07:00
$ \NoteCommitRand $ is randomly generated by the sender. \eli { previous and next sentence should be merged into bullets above} \changed { $ \NoteAddressRand $
2016-03-28 18:28:07 -07:00
is generated from a random seed $ \NoteAddressPreRand $ using
$ \PRFrho { \NoteAddressPreRand } $ .} Only a commitment to these values is disclosed
publicly, which allows the tokens $ \NoteCommitRand $ and $ \NoteAddressRand $ to blind
2016-03-31 01:00:04 -07:00
the value and recipient \emph { except} to those who possess these tokens \eli { inaccurate, even if you have these tokens you'd have to exhaustively try all address keys (not all of them are necessarily known to you) and values
to find the recipient} .
2015-12-14 09:03:59 -08:00
2016-03-28 18:28:07 -07:00
\subsubsection { \NoteCommitments } \label { comm}
2015-12-14 09:03:59 -08:00
2016-03-28 18:28:07 -07:00
The underlying $ \Value $ and $ \AuthPublic $ are blinded with $ \NoteAddressRand $
2016-03-30 06:27:43 -07:00
and $ \NoteCommitRand $ \changed { using the collision-resistant hash function $ \FullHash $ } .
2016-03-31 01:00:04 -07:00
\eli { The note commitment of $ \NoteTuple { } $ , denoted $ \cm $ , is defined as \ldots }
2016-03-28 18:28:07 -07:00
The resulting hash $ \cm = \Commitment ( \NoteTuple { } ) $ .
2015-12-14 09:03:59 -08:00
2016-01-28 14:33:43 -08:00
\newsavebox { \cmbox }
\begin { lrbox} { \cmbox }
2016-02-26 08:36:59 -08:00
\setchanged
2016-03-28 19:15:08 -07:00
\begin { bytefield} [bitwidth=0.036em]{ 840}
2016-03-20 16:19:38 -07:00
\bitbox { 24} { 1} &
2016-03-30 06:27:43 -07:00
\bitbox { 24} { 0} &
2016-03-20 16:19:38 -07:00
\bitbox { 24} { 1} &
\bitbox { 24} { 1} &
2016-03-30 06:27:43 -07:00
\bitbox { 24} { 0} &
\bitbox { 24} { 0} &
\bitbox { 24} { 0} &
\bitbox { 24} { 0} &
2016-03-20 16:19:38 -07:00
\bitbox { 256} { 256 bit $ \AuthPublic $ } &
\bitbox { 128} { 64 bit $ \Value $ } &
2016-03-28 18:28:07 -07:00
\bitbox { 256} { 256 bit $ \NoteAddressRand $ }
2016-03-28 19:15:08 -07:00
\bitbox { 256} { 256 bit $ \NoteCommitRand $ } &
2015-12-14 09:03:59 -08:00
\end { bytefield}
2016-01-28 14:33:43 -08:00
\end { lrbox}
2015-12-14 09:03:59 -08:00
2016-02-26 08:36:59 -08:00
\changed {
2016-03-20 16:19:38 -07:00
\hskip 1em $ \cm : = \FullHashbox { \cmbox } $
2016-03-30 06:27:43 -07:00
\subparagraph { Note:}
The leading byte of the $ \FullHash $ input is $ \hexint { B 0 } $ .
2016-02-26 08:36:59 -08:00
}
2015-12-14 09:03:59 -08:00
2016-03-29 17:36:34 -07:00
\subsubsection { \Nullifiers }
2015-12-14 09:03:59 -08:00
2016-03-29 17:36:34 -07:00
A \nullifier (denoted $ \nf $ ) is derived from the $ \NoteAddressRand $ component
of a \note as $ \PRFnf { \AuthPrivate } ( \NoteAddressRand ) $ . A \note is spent by proving
2016-03-28 18:28:07 -07:00
knowledge of $ \NoteAddressRand $ and $ \AuthPrivate $ in zero knowledge while
2016-03-29 17:36:34 -07:00
disclosing its \nullifier $ \nf $ , allowing $ \nf $ to be used to prevent double-spending.
2015-12-14 09:03:59 -08:00
2016-03-28 18:28:07 -07:00
\subsubsection { \NotePlaintexts and \Memos } \label { notept}
2016-02-25 11:43:03 -08:00
2016-03-31 01:00:04 -07:00
\eli { what's a transmitted note? is it different from a note? and who encrypts
them? }
2016-03-28 18:28:07 -07:00
Transmitted \notes are stored on the blockchain in encrypted form, together with
a \noteCommitment $ \cm $ .
2016-02-25 11:43:03 -08:00
2016-03-31 01:00:04 -07:00
\eli { next paragraph mentions ``note plainext'', ``joinsplit description'',
``transmission keys'', ``transmitted notes cyphertext'' all of which are undefined yet. It seems the main thing defined here is the memo, and then a note-plaintext. In the ``abstract'' part both are easy to describe, and the rest of the details should likely be moved to ``instantiation''}
2016-03-28 18:28:50 -07:00
The \notePlaintexts associated with a \joinSplitDescription are encrypted to the
2016-03-06 20:36:29 -08:00
respective \transmitKeypair keys $ \TransmitPublicNew { \allNew } $ ,
2016-03-28 18:28:07 -07:00
and the result forms part of a \notesCiphertext (see \crossref { inband}
2016-03-05 12:20:11 -08:00
for further details).
2016-02-25 11:43:03 -08:00
2016-03-28 18:28:07 -07:00
Each \notePlaintext (denoted $ \NotePlaintext { } $ ) consists of
$ ( \Value , \NoteAddressRand , \NoteCommitRand \changed { , \Memo } ) $ .
2016-02-25 11:43:03 -08:00
2016-03-20 16:36:54 -07:00
The first three of these fields are as defined earlier.
2016-03-28 19:21:50 -07:00
\changed { $ \Memo $ is a 128-byte \memo associated with this \note .
2016-02-25 11:43:03 -08:00
2016-03-29 07:08:15 -07:00
The usage of the \memo is by agreement between the sender and recipient of the
\note . The memo \SHOULD be encoded either as:
\begin { itemize}
\item a UTF-8 human-readable string \cite { Unicode} , padded with zero bytes; or
\item an arbitrary sequence of 128 bytes starting with a byte value of $ \hexint { F 5 } $
or greater, which is therefore not a valid UTF-8 string.
\end { itemize}
In the former case, wallet software is expected to strip any trailing zero bytes
and then display the resulting \mbox { UTF-8} string to the recipient user, where applicable.
2016-02-25 11:43:03 -08:00
Incorrect UTF-8-encoded byte sequences should be displayed as replacement characters
2016-03-29 07:08:15 -07:00
(\ReplacementCharacter ).
In the latter case, the contents of the \memo \SHOULDNOT be displayed. A start byte
of $ \hexint { F 5 } $ is reserved for use by automated software by private agreement.
A start byte of $ \hexint { F 6 } $ or greater is reserved for use in future \Zcash
protocol extensions.
2016-02-25 11:43:03 -08:00
}
2016-03-28 18:28:07 -07:00
The encoding of a \notePlaintext consists of, in order:
2016-03-05 10:37:40 -08:00
\begin { equation*}
2016-03-29 19:47:57 -07:00
\begin { bytefield} [bitwidth=0.029em]{ 1608}
\changed {
\bitbox { 192} { 8 bit $ \NotePlaintextLeadByte $ }
& } \bitbox { 192} { $ \Value $ (8 bytes)} &
2016-03-28 18:28:07 -07:00
\bitbox { 256} { $ \NoteAddressRand $ (32 bytes)} &
2016-03-28 19:15:08 -07:00
\bitbox { 256} { $ \NoteCommitRand $ (\changed { 32} bytes)} &
2016-03-29 19:47:57 -07:00
\changed { \bitbox { 800} { $ \Memo $ (128 bytes)} }
2016-03-05 10:37:40 -08:00
\end { bytefield}
\end { equation*}
\begin { itemize}
2016-03-29 19:47:57 -07:00
\changed {
\item A byte, $ \NotePlaintextLeadByte $ , indicating this version of the
encoding of a \notePlaintext .
}
2016-03-20 16:19:38 -07:00
\item 8 bytes specifying $ \Value $ .
2016-03-28 18:28:07 -07:00
\item 32 bytes specifying $ \NoteAddressRand $ .
2016-03-28 19:15:08 -07:00
\item \changed { 32} bytes specifying $ \NoteCommitRand $ .
2016-03-05 10:37:40 -08:00
\changed {
2016-03-28 19:21:50 -07:00
\item 128 bytes specifying $ \Memo $ .
2016-03-05 10:37:40 -08:00
}
\end { itemize}
2016-03-28 18:28:07 -07:00
\subsection { \NoteCommitment Tree}
2015-12-14 09:03:59 -08:00
\begin { center}
\includegraphics [scale=.4] { incremental_ merkle}
\end { center}
2016-03-31 01:00:04 -07:00
\eli { Prefer ``A \noteCommitmentTree '' because all that follows works for any tree and we expect it to dynamically change}
2016-03-28 18:28:07 -07:00
The \noteCommitmentTree is an \incrementalMerkleTree of depth $ \MerkleDepth $ used to
2016-03-31 01:00:04 -07:00
store \noteCommitments that \joinSplitTransfers produce \eli { undefined yet because \joinSplitTransfer . Why not define it just as in the figure, it's a merkle tree of note commitments.} . Just as the \term { unspent
2016-03-28 18:28:07 -07:00
transaction output set} (UTXO) used in \Bitcoin , it is used to express the existence
2016-01-26 15:15:17 -08:00
of value and the capability to spend it. However, unlike the UTXO, it is \emph { not}
2016-03-31 01:00:04 -07:00
the job of this tree \eli { intended usage. particularly confusing because we now assign a job to a tree.} to protect against double-spending, as it is append-only.
2015-12-14 09:03:59 -08:00
2016-03-31 01:00:04 -07:00
\eli { more intendend usage: how does the honest player associate blocks with a tree? and what happens if a user deviates from this? We're going to describe the split-join circuit. For this purpose we only need to have defined a tree of commitments and define (or assume knowledge) of authentication paths in a merkle tree} Blocks in the blockchain are associated (by all nodes) with the root of this tree
2016-03-28 18:28:50 -07:00
after all of its constituent \joinSplitDescriptions ' \noteCommitments have been
2016-01-26 15:15:17 -08:00
entered into the tree associated with the previous block.
2015-12-14 09:03:59 -08:00
2016-03-29 17:36:34 -07:00
\subsection { \NullifierSet }
2015-12-14 09:03:59 -08:00
2016-03-31 01:00:04 -07:00
\eli { intended usage. Prefer to have defined (i) a nullifier set and (ii) commitment tree, and now talk about join-split. Later we'll explain how these two objects are modified.}
\eli { tx undefined yet}
2016-03-29 17:36:34 -07:00
Transactions insert \nullifiers into a \nullifierSet which is maintained
2016-01-26 15:15:17 -08:00
alongside the UTXO by all nodes.
\eli { a tx is just a string, so it doesn't insert anything. Rather, nodes process
2016-03-29 17:36:34 -07:00
tx's and the ``good'' ones lead to the addition of \nullifiers to the
\nullifierSet .}
2016-01-26 15:15:17 -08:00
2016-03-29 17:36:34 -07:00
Transactions that attempt to insert a \nullifier into this set that already
2016-01-26 15:15:17 -08:00
exists within it are invalid as they are attempting to double-spend.
\eli { After defining \term { transaction} , one should define what a \term { legal tx} is
(this definition depends on a particular blockchain [view]) and only then can one
2016-03-29 17:36:34 -07:00
talk about ``attempts'' of transactions, and insertions of \nullifiers into the
\nullifierSet .}
2016-01-26 15:15:17 -08:00
2016-03-31 01:00:04 -07:00
\eli { suggest to move the discussion of the split-join circuit to here, so that we first completely discuss the single-tx level (with respect to some fixed comm-tree and nullifier set). Then we'll move to the topic of consensus and blockchain.}
2016-01-26 15:15:17 -08:00
\subsection { The Blockchain}
2016-03-31 01:00:04 -07:00
\eli { For the ``abstract'' part, all we care about is that each block-chain is converted to a merkle tree in a deterministic manner, so that all honest players agree on it's structure (assuming they see the same blockchain). so the particular way the ``canonical'' tree is constructed should appear in ``instantiation''.}
At a given point in time, the \blockchainview of each \fullnode \eli { undefined. So far we had ``users''. Are there several kinds?} consists of a
2016-01-26 15:15:17 -08:00
sequence of one or more valid \blocks . Each \block consists of a sequence of one or
2016-03-31 01:00:04 -07:00
more \transactions . In a given node's \blockchainview , \treestates are chained
\eli { defined?} in an
2016-01-26 15:15:17 -08:00
obvious way:
\begin { itemize}
\item The input \treestate of the first \block is the empty \treestate .
\item The input \treestate of the first \transaction of a \block is the final
2016-01-26 15:40:53 -08:00
\treestate of the immediately preceding \block .
2016-01-26 15:15:17 -08:00
\item The input \treestate of each subsequent \transaction in a \block is the
2016-01-26 15:40:53 -08:00
output \treestate of the immediately preceding \transaction .
2016-01-26 15:15:17 -08:00
\item The final \treestate of a \block is the output \treestate of its last
\transaction .
\end { itemize}
An \anchor is a Merkle tree root of a \treestate , and uniquely identifies that
\treestate given the assumed security properties of the Merkle tree's hash function.
2016-03-31 01:00:04 -07:00
Each \transaction is associated with a \sequenceOfJoinSplitDescriptions \eli { this is undefined yet. let's work bottom up: first define a join-split assuming a fixed tree} .
2016-03-28 18:28:50 -07:00
\todo { They also have a transparent value flow that interacts with the \joinSplitDescription 's
2016-02-11 07:04:56 -08:00
\changed { $ \vpubOld $ and} $ \vpubNew $ .}
2016-03-31 01:00:04 -07:00
Inputs and outputs are associated with a value. \eli { what're inputs/outputs of join-split?}
2016-01-26 15:15:17 -08:00
The total value of the outputs must not exceed the total value of the inputs.
2016-03-28 18:28:50 -07:00
The \anchor of the \changed { first} \joinSplitDescription in a \transaction must refer to
2016-02-11 07:04:56 -08:00
some earlier \block 's final \treestate .
2016-01-26 15:15:17 -08:00
2016-02-11 07:04:56 -08:00
\changed {
2016-03-28 18:28:50 -07:00
The \anchor of each subsequent \joinSplitDescription may refer either to some earlier
2016-01-26 15:40:53 -08:00
\block 's final \treestate , or to the output \treestate of the immediately preceding
2016-03-28 18:28:50 -07:00
\joinSplitDescription .
2016-02-11 07:04:56 -08:00
}
2016-01-26 15:15:17 -08:00
These conditions act as constraints on the blocks that a \fullnode will
accept into its \blockchainview .
We rely on Bitcoin-style consensus for \fullnodes to eventually converge on their
views of valid \blocks , and therefore of the sequence of \treestates in those
\blocks .
2015-12-14 09:03:59 -08:00
\subparagraph { Value pool}
2016-03-31 01:00:04 -07:00
\eli { who maintains the value pool? is this part of the specification? seems like
more intended usage?} \eli { tx undefined yet}
2016-01-26 15:36:53 -08:00
Transaction inputs insert value into a \term { value pool} , and transaction outputs
2016-01-26 15:15:17 -08:00
remove value from this pool. The remaining value in the pool is available to miners
as a fee.
2015-12-14 09:03:59 -08:00
2016-03-28 18:28:50 -07:00
\section { \JoinSplitTransfers and Descriptions} \label { pourdesc}
2015-12-14 09:03:59 -08:00
2016-03-31 01:00:04 -07:00
A \joinSplitDescription is data included in a \transaction \eli { lets first define split-join, then tx} that describes a \joinSplitTransfer ,
2016-01-26 15:15:17 -08:00
i.e. a confidential value transfer. This kind of value transfer is the primary
2016-03-31 01:00:04 -07:00
\Zcash -specific operation performed by \transactions \eli { we keep referring to undefined tx. furthermore, it's not clear from last sentence if tx is a type of data or a process, as it performs something} ; it uses, but should not be
2016-03-28 18:28:50 -07:00
confused with, the \JoinSplitCircuit used for the \zkSNARK proof and verification.
2016-01-26 15:15:17 -08:00
2016-03-31 01:00:04 -07:00
A \joinSplitTransfer spends $ \NOld $ \notes $ \cOld { \allOld } $ \eli { confusing notation, usually one uses $ x _ 1 , \ldots , x _ n $ for a sequence of $ n $ objects, not $ x _ { 1 \ldots ,n } $ } and transparent input
2016-03-28 18:28:07 -07:00
$ \vpubOld $ , and creates $ \NNew $ \notes $ \cNew { \allNew } $ and transparent output
2016-03-15 18:36:37 -07:00
$ \vpubNew $ .
2016-03-31 01:00:04 -07:00
\subparagraph { Consensus rule:} \eli { what's a consensus rule? what happens if I deviate from it?}
Either $ \vpubOld $ or $ \vpubNew $ \MUST be zero. \eli { why? what harm would follow
if we allow both nonzero?}
2016-03-28 17:16:06 -07:00
2016-03-15 18:36:37 -07:00
\changed {
2016-03-31 01:00:04 -07:00
\Zcash \transactions have the following additional fields \eli { additional to what?} :
2016-03-15 18:36:37 -07:00
2016-03-17 18:20:44 -07:00
\begin { center}
2016-03-30 18:21:02 -07:00
\begin { tabularx} { 0.9\textwidth } { |c|l|p{ 10.49em} |X|}
2016-03-17 18:20:44 -07:00
\hline
Bytes & \heading { Name} & \heading { Data Type} & \heading { Description} \\
\hhline { |=|=|=|=|}
2016-03-28 18:28:50 -07:00
\Varies & $ \nJoinSplit $ & \type { compactSize uint} & The number of \joinSplitDescriptions
in $ \vJoinSplit $ . \\ \hline
2016-03-17 18:20:44 -07:00
2016-03-29 19:47:57 -07:00
$ 1026 \times \nJoinSplit $ & $ \vJoinSplit $ &
2016-03-30 18:21:02 -07:00
\type { JoinSplitDescription} \type { [$ \nJoinSplit $ ]} &
2016-03-28 18:28:50 -07:00
The \sequenceOfJoinSplitDescriptions in this \transaction . \\ \hline
2016-03-17 18:20:44 -07:00
2016-03-30 18:21:02 -07:00
33 $ \dagger $ & $ \joinSplitPubKey $ & \type { char[33]} & An encoding of a ECDSA public verification key,
2016-03-15 18:36:37 -07:00
using the secp256k1 curve and parameters defined in \cite { sec2-ecdsa} and
2016-03-17 18:20:44 -07:00
\cite { secp256k1} . \\ \hline
2016-03-15 18:36:37 -07:00
2016-03-30 18:21:02 -07:00
64 $ \dagger $ & $ \joinSplitSig $ & \type { char[64]} & A signature on a prefix of the \transaction encoding,
2016-03-28 18:28:50 -07:00
to be verified using $ \joinSplitPubKey $ . \\ \hline
2016-03-17 18:20:44 -07:00
\end { tabularx}
\end { center}
2016-03-15 18:36:37 -07:00
2016-03-30 18:21:02 -07:00
$ \dagger $ The $ \joinSplitPubKey $ and $ \joinSplitSig $ fields are present if and only if
2016-03-30 07:18:50 -07:00
$ \nJoinSplit > 0 $ .
2016-03-28 18:28:50 -07:00
The encoding of $ \joinSplitPubKey $ and the data to be signed are specified in
2016-03-15 18:36:37 -07:00
more detail in \crossref { nonmalleability} .
}
2016-01-26 15:15:17 -08:00
2016-03-31 01:00:04 -07:00
Each \type { JoinSplitDescription} consists of: \eli { maybe move this up, to beginning of section?}
2015-12-14 09:03:59 -08:00
2016-03-17 18:20:44 -07:00
\begin { center}
\begin { tabularx} { 0.9\textwidth } { |c|l|l|X|}
\hline
Bytes & \heading { Name} & \heading { Data Type} & \heading { Description} \\
\hhline { |=|=|=|=|}
\setchanged 8 & \setchanged $ \vpubOldField $ & \setchanged \type { int64\_ t} & \mbox { } \setchanged
2016-03-28 18:28:50 -07:00
A value $ \vpubOld $ that the \joinSplitTransfer removes from the value pool. \\ \hline
2015-12-14 09:03:59 -08:00
2016-03-28 18:28:50 -07:00
8 & $ \vpubNewField $ & \type { int64\_ t} & A value $ \vpubNew $ that the \joinSplitTransfer inserts
2016-03-17 18:20:44 -07:00
into the value pool. \\ \hline
2015-12-14 09:03:59 -08:00
2016-03-28 18:28:07 -07:00
32 & $ \anchorField $ & \type { char[32]} & A merkle root $ \rt $ of the \noteCommitmentTree at
2016-03-28 18:28:50 -07:00
some block height in the past, or the merkle root produced by a previous \joinSplitTransfer in
2016-03-28 17:19:34 -07:00
this \transaction . \sean { We need to be more specific here.} \\ \hline
2015-12-14 09:03:59 -08:00
2016-03-29 17:36:34 -07:00
64 & $ \nullifiersField $ & \type { char[32][$ \NOld $ ]} & A sequence of \nullifiers of the input
\notes $ \nfOld { \allOld } $ . \\ \hline
2015-12-14 09:03:59 -08:00
2016-03-28 18:28:07 -07:00
64 & $ \commitments $ & \type { char[32][$ \NNew $ ]} . & A sequence of \noteCommitments for the
output \notes $ \cmNew { \allNew } $ . \\ \hline
2015-12-14 09:03:59 -08:00
2016-03-28 16:31:11 -07:00
\setchanged 32 & \setchanged $ \ephemeralKey $ & \setchanged \type { char[32]} & \mbox { } \setchanged
A Curve25519 public key $ \EphemeralPublic $ . \\ \hline
2016-02-01 14:11:36 -08:00
2016-03-29 19:47:57 -07:00
434 & $ \encCiphertexts $ & \type { char[217][$ \NNew $ ]} & A sequence of ciphertext
2016-03-28 18:28:07 -07:00
components for the encrypted output \notes , $ \TransmitCiphertext { \allNew } $ . \\ \hline
2016-02-25 09:13:31 -08:00
2016-03-17 18:20:44 -07:00
\setchanged 32 & \setchanged $ \randomSeed $ & \setchanged \type { char[32]} & \mbox { } \setchanged
2016-03-28 18:28:50 -07:00
A 256-bit seed that must be chosen independently at random for each \joinSplitDescription . \\ \hline
2016-02-25 15:38:31 -08:00
2016-03-17 18:20:44 -07:00
64 & $ \vmacs $ & \type { char[32][$ \NOld $ ]} & A sequence of message authentication tags
2016-03-06 20:36:29 -08:00
$ \h { \allOld } $ that bind $ \hSig $ to each $ \AuthPrivate $ of the
2016-03-28 18:28:50 -07:00
$ \joinSplitDescription $ . \\ \hline
2016-03-17 18:20:44 -07:00
288 & $ \zkproof $ & \type { char[288]} & An encoding, as determined by the libsnark library
2016-03-28 18:28:50 -07:00
\cite { libsnark} , of the zero-knowledge proof $ \JoinSplitProof $ . \\ \hline
2015-12-14 09:03:59 -08:00
2016-03-17 18:20:44 -07:00
\end { tabularx}
\end { center}
2015-12-14 09:03:59 -08:00
2016-03-28 18:28:07 -07:00
The $ \ephemeralKey $ and $ \encCiphertexts $ fields together form the \notesCiphertext .
2015-12-14 09:03:59 -08:00
2016-03-28 18:28:07 -07:00
\todo { Describe case where there are fewer than $ \NOld $ real input \notes .}
2016-02-25 10:32:18 -08:00
2016-03-15 16:23:05 -07:00
\subsection { Computation of \hSigText } \label { hsig}
2016-02-07 14:37:36 -08:00
2016-03-31 01:00:04 -07:00
\eli { this is mostly ``instantiation'' but I notice we use a different crypto primitive instantiation (Blake) not mentioned previously. Let's use the ``abstract'' notation here: what is it? a CRH? PRF? requires different multiple of the security parameter $ \lambda $ ? does it require special properties not needed by other instances of these that we used previously?}
2016-03-29 19:28:01 -07:00
\newsavebox { \hsigtagbox }
\begin { lrbox} { \hsigtagbox }
\setchanged
\begin { bytefield} [bitwidth=0.16em]{ 128}
\bitbox { 72} { 72 bit $ \ascii { ZcashhSig } $ }
\bitbox { 56} { $ \zeros { 56 } $ }
\end { bytefield}
\end { lrbox}
2016-02-07 14:37:36 -08:00
\newsavebox { \hsigbox }
\begin { lrbox} { \hsigbox }
2016-02-11 10:21:39 -08:00
\setchanged
2016-03-29 19:28:01 -07:00
\begin { bytefield} [bitwidth=0.033em]{ 1024}
\bitbox { 256} { $ \randomSeed $ }
2016-03-29 17:36:34 -07:00
\bitbox { 256} { \hfill 256 bit $ \nfOld { \mathrm { 1 } } $ \hfill ...\; } &
\bitbox { 256} { 256 bit $ \nfOld { \NOld } $ } &
2016-03-28 18:28:50 -07:00
\bitbox { 256} { $ \joinSplitPubKey $ }
2016-02-07 14:37:36 -08:00
\end { bytefield}
\end { lrbox}
2016-02-11 10:21:39 -08:00
\changed {
2016-03-28 18:28:50 -07:00
Given a \joinSplitDescription , we define:
2016-02-07 14:37:36 -08:00
2016-03-29 19:28:01 -07:00
\hskip 1em $ \hSigtag : = \Justthebox { \hsigtagbox } { - 1 . 3 ex } $
\hskip 1em $ \hSig : = \BlakeHashbox { \hSigtag } { \hsigbox } $
2016-02-11 10:21:39 -08:00
}
2016-02-07 14:37:36 -08:00
2016-03-15 16:23:05 -07:00
\subsection { Merkle root validity}
2015-12-14 09:03:59 -08:00
2016-03-28 18:28:50 -07:00
A \joinSplitDescription is valid if $ \rt $ is a \noteCommitmentTree root found in
2016-03-28 18:28:07 -07:00
either the blockchain or a merkle root produced by inserting the \noteCommitments
2016-03-28 18:28:50 -07:00
of a previous \joinSplitDescription in the \transaction to the \noteCommitmentTree
identified by that previous \joinSplitDescription 's $ \anchor $ .
2015-12-14 09:03:59 -08:00
2016-03-15 16:23:05 -07:00
\subsection { Non-malleability} \label { nonmalleability}
2015-12-14 09:03:59 -08:00
2016-03-31 01:00:04 -07:00
\eli { mix of ``abstract'' and ``instantiation''. Can we first describe abstractly what's going on here? I got pretty lost pretty quickly. In particular, what
are the abstract functionalities of SIGHASH, SIGHASHALL, ECDSA,
the ``compressed elliptic curve point'', are they CRH and digital signature, respectively? what security (as multiple of $ \lambda $ ?)}
2016-03-15 18:36:37 -07:00
\changed {
2016-03-30 07:18:50 -07:00
\Bitcoin defines several \sighashTypes that cover various parts of a transaction.
In \Zcash , all of these \sighashTypes are extended to cover the \Zcash -specific
fields $ \nJoinSplit $ , $ \vJoinSplit $ , and $ \joinSplitPubKey $ . They \emph { do not}
cover the field $ \joinSplitSig $ .
2016-03-31 01:00:04 -07:00
\subparagraph { Consensus rule:} \eli { what's a consensus rule?}
2016-03-30 07:18:50 -07:00
If $ \nJoinSplit > 0 $ , the \transaction \MUSTNOT use \sighashTypes other than
$ \SIGHASHALL $ .
Let $ \dataToBeSigned $ be the hash of the \transaction using the $ \SIGHASHALL $
\sighashType . Note that this \emph { excludes} all of the $ \scriptSig $ fields in
the non-\Zcash -specific parts of the \transaction .
2016-03-15 18:36:37 -07:00
2016-03-28 18:28:50 -07:00
In order to ensure that a \joinSplitDescription is cryptographically bound to the
2016-03-15 18:36:37 -07:00
transparent inputs and outputs corresponding to $ \vpubNew $ and $ \vpubOld $ , and
2016-03-28 18:28:50 -07:00
to the other \joinSplitDescriptions in the same \transaction , an ephemeral ECDSA
2016-03-15 18:36:37 -07:00
key pair is generated for each \transaction , and the $ \dataToBeSigned $ is
signed with the private signing key of this key pair. The corresponding public
2016-03-28 18:28:50 -07:00
verification key is included in the \transaction encoding as $ \joinSplitPubKey $ .
2016-03-15 18:36:37 -07:00
2016-03-30 07:18:50 -07:00
If $ \nJoinSplit $ is zero, the $ \joinSplitPubKey $ and $ \joinSplitSig $ fields are
omitted. Otherwise, a \transaction has a correct \joinSplitSignature if:
2016-03-15 16:20:17 -07:00
\begin { itemize}
2016-03-28 18:28:50 -07:00
\item $ \joinSplitSig $ can be verified as an encoding of a signature on
$ \dataToBeSigned $ , using the ECDSA public key encoded as $ \joinSplitPubKey $ ; and
\item $ \joinSplitSig $ has an $ \ECDSAs $ value in the lower half of the possible range
2016-03-15 16:20:17 -07:00
(i.e. $ \ECDSAs $ must be in the range from 0x1 to \linebreak
0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0,
inclusive).
\end { itemize}
If $ \ECDSAs $ is not in the given range, the signature is treated as invalid.
2016-03-15 18:36:37 -07:00
}
2016-03-15 16:20:17 -07:00
\newsavebox { \sigbox }
\begin { lrbox} { \sigbox }
2016-03-15 18:36:37 -07:00
\setchanged
2016-03-15 16:20:17 -07:00
\begin { bytefield} [bitwidth=0.075em]{ 512}
\bitbox { 256} { 256 bit $ \ECDSAr $ }
\bitbox { 256} { 256 bit $ \ECDSAs $ }
\end { bytefield}
\end { lrbox}
\newsavebox { \pubkeybox }
\begin { lrbox} { \pubkeybox }
2016-03-15 18:36:37 -07:00
\setchanged
2016-03-15 17:06:01 -07:00
\begin { bytefield} [bitwidth=0.075em]{ 264}
2016-03-30 06:27:43 -07:00
\bitbox { 14} { 0}
\bitbox { 14} { 0}
\bitbox { 14} { 0}
\bitbox { 14} { 0}
\bitbox { 14} { 0}
\bitbox { 14} { 0}
\bitbox { 14} { 1}
2016-03-15 17:06:01 -07:00
\bitbox { 56} { 1 bit $ \tilde { y } _ P $ }
\bitbox { 256} { 256 bit $ x _ P $ }
2016-03-15 16:20:17 -07:00
\end { bytefield}
\end { lrbox}
2016-03-15 18:36:37 -07:00
\changed {
2016-03-15 16:20:17 -07:00
The encoding of a signature is:
2016-03-15 18:36:37 -07:00
}
2016-03-15 16:20:17 -07:00
\begin { itemize}
\item [] $ \Justthebox { \sigbox } { - 1 . 3 ex } $
\end { itemize}
2016-03-15 18:36:37 -07:00
\changed {
2016-03-15 16:20:17 -07:00
where $ \ECDSAr $ and $ \ECDSAs $ are as defined in \cite { sec2-ecdsa} .
2016-03-15 17:06:01 -07:00
The encoding of a public key is as defined in section E.2.3.2 of \cite { std1363}
for a compressed elliptic curve point with $ x $ -coordinate $ x _ P $ and compressed
$ y $ -coordinate $ \tilde { y } _ P $ :
2016-03-15 18:36:37 -07:00
}
2016-03-15 16:20:17 -07:00
\begin { itemize}
\item [] $ \Justthebox { \pubkeybox } { - 1 . 3 ex } $
\end { itemize}
2016-03-15 18:36:37 -07:00
\changed {
2016-03-15 17:06:01 -07:00
Note that only compressed public keys are valid.
2016-03-15 18:36:37 -07:00
}
2016-03-15 17:06:01 -07:00
2016-03-28 18:28:50 -07:00
The condition enforced by the \JoinSplitCircuit specified in \crossref { nonmalleablepour}
2016-03-15 18:36:37 -07:00
ensures that a holder of all of $ \AuthPrivateOld { \allOld } $ for each
2016-03-28 18:28:50 -07:00
\joinSplitDescription has authorized the use of the private signing key corresponding
to $ \joinSplitPubKey $ to sign this \transaction .
2016-03-15 16:20:17 -07:00
2015-12-14 09:03:59 -08:00
2016-03-15 16:23:05 -07:00
\subsection { Balance}
2015-12-14 09:03:59 -08:00
2016-03-31 01:00:04 -07:00
A \joinSplitTransfer can be seen \eli { more intended usage} , from the perspective of the \transaction \eli { does a transaction ``see''?} , as
2016-02-11 07:04:56 -08:00
an input \changed { and an output simultaneously} .
\changed { $ \vpubOld $ takes value from the value pool and}
$ \vpubNew $ adds value to the value pool. As a result, \changed { $ \vpubOld $ is
2016-03-31 01:00:04 -07:00
treated \eli { by whom?} like an \emph { output} value, whereas} $ \vpubNew $ is treated like an
2016-02-11 07:04:56 -08:00
\emph { input} value.
\changed {
Note that unlike original \Zerocash \cite { ZerocashOakland} , \Zcash does not have
2016-03-18 14:09:24 -07:00
a distinction between Mint and Pour operations. The addition of $ \vpubOld $ to a
2016-03-28 18:28:50 -07:00
\joinSplitDescription subsumes the functionality of both Mint and Pour. Also,
\joinSplitDescriptions are indistinguishable regardless of the number of real input
2016-03-28 18:28:07 -07:00
\notes .
2016-03-28 17:16:06 -07:00
As stated in \crossref { pourdesc} , either $ \vpubOld $ or $ \vpubNew $ \MUST be zero.
No generality is lost because, if a \transaction in which both $ \vpubOld $ and
$ \vpubNew $ were nonzero were allowed, it could be replaced by an equivalent one
in which $ \minimum ( \vpubOld , \vpubNew ) $ is subtracted from both of these values.
This restriction helps to avoid unnecessary distinctions between \transactions
according to client implementation.
2016-02-11 07:04:56 -08:00
}
2015-12-14 09:03:59 -08:00
2016-03-29 17:36:34 -07:00
\subsection { \NoteCommitments and \Nullifiers }
2015-12-14 09:03:59 -08:00
2016-03-31 01:00:04 -07:00
A \transaction \eli { undefined yet} that contains one or more \joinSplitDescriptions , when entered into the
2016-03-28 18:28:07 -07:00
blockchain, appends to the \noteCommitmentTree with all constituent
2016-03-29 17:36:34 -07:00
\noteCommitments . All of the constituent \nullifiers are also entered into the
\nullifierSet of the \blockchainview \emph { and} \mempool . A \transaction is not
valid if it attempts to add a \nullifier to the \nullifierSet that already
2016-03-31 01:00:04 -07:00
exists in the set.
2015-12-14 09:03:59 -08:00
2016-03-28 18:28:50 -07:00
\subsection { \JoinSplitCircuit and Proofs}
2015-12-14 09:03:59 -08:00
2016-01-26 15:15:17 -08:00
In \Zcash , $ \NOld $ and $ \NNew $ are both $ 2 $ .
2015-12-14 09:03:59 -08:00
2016-03-28 18:28:50 -07:00
A valid instance of $ \JoinSplitProof $ assures that given a \term { primary input} :
2015-12-14 09:03:59 -08:00
2016-02-25 13:42:28 -08:00
\begin { itemize}
2016-03-29 17:36:34 -07:00
\item [] $ ( \rt , \nfOld { \allOld } , \cmNew { \allNew } , \changed { \vpubOld , \; }
2016-03-12 18:16:30 -08:00
\vpubNew , \hSig , \h { \allOld } )$ ,
2016-02-25 13:42:28 -08:00
\end { itemize}
2015-12-14 09:03:59 -08:00
2016-02-25 13:42:28 -08:00
there exists a witness of \term { auxiliary input} :
\begin { itemize}
2016-03-06 20:36:29 -08:00
\item [] $ ( \treepath { \allOld } , \cOld { \allOld } , \AuthPrivateOld { \allOld } ,
2016-03-28 18:28:07 -07:00
\cNew { \allNew } \changed { , \NoteAddressPreRand } )$
2016-02-25 13:42:28 -08:00
\end { itemize}
2015-12-14 09:03:59 -08:00
2016-02-25 13:42:28 -08:00
where:
2015-12-14 09:03:59 -08:00
2016-02-25 13:42:28 -08:00
\begin { itemize}
2016-03-06 20:36:29 -08:00
\item [] for each $ i \in \setofOld $ : $ \cOld { i } = ( \AuthPublicOld { i } ,
2016-03-28 18:28:07 -07:00
\vOld { i} , \NoteAddressRandOld { i} , \NoteCommitRandOld { i} )$ ;
2016-03-12 18:16:30 -08:00
\item [] for each $ i \in \setofNew $ : $ \cNew { i } = ( \AuthPublicNew { i } ,
2016-03-28 18:28:07 -07:00
\vNew { i} , \NoteAddressRandNew { i} , \NoteCommitRandNew { i} )$
2016-02-25 13:42:28 -08:00
\end { itemize}
2015-12-14 09:03:59 -08:00
2016-02-25 13:42:28 -08:00
such that the following conditions hold:
2015-12-14 09:03:59 -08:00
\subparagraph { Merkle path validity}
2016-03-06 20:36:29 -08:00
for each $ i \in \setofOld $ \changed { $ \mid $ $ \vOld { i } \neq 0 $ } :
2016-02-25 13:42:28 -08:00
$ \treepath { i } $ must be a valid path of depth $ \MerkleDepth $ from \linebreak
2016-03-28 18:28:07 -07:00
$ \Commitment ( \cOld { i } ) $ to \noteCommitmentTree root $ \rt $ .
2015-12-14 09:03:59 -08:00
\subparagraph { Balance}
2016-02-25 13:42:28 -08:00
$ \changed { \vpubOld \; + } \vsum { i = 1 } { \NOld } \vOld { i } = \vpubNew + \vsum { i = 1 } { \NNew } \vNew { i } $ .
2015-12-14 09:03:59 -08:00
2016-03-29 17:36:34 -07:00
\subparagraph { \Nullifier integrity}
2015-12-14 09:03:59 -08:00
2016-03-06 20:36:29 -08:00
for each $ i \in \setofNew $ :
2016-03-29 17:36:34 -07:00
$ \nfOld { i } = \PRFnf { \AuthPrivateOld { i } } ( \NoteAddressRandOld { i } ) $ .
2015-12-14 09:03:59 -08:00
\subparagraph { Spend authority}
2016-03-06 20:36:29 -08:00
for each $ i \in \setofOld $ :
2016-03-12 18:16:30 -08:00
$ \AuthPublicOld { i } = \changed { \PRFaddr { \AuthPrivateOld { i } } ( 0 ) } $ .
2015-12-14 09:03:59 -08:00
2016-03-15 17:06:01 -07:00
\subparagraph { Non-malleability} \label { nonmalleablepour}
2015-12-14 09:03:59 -08:00
2016-03-06 20:36:29 -08:00
for each $ i \in \setofOld $ :
2016-02-25 17:56:04 -08:00
$ \h { i } = \PRFpk { \AuthPrivateOld { i } } ( i, \hSig ) $ .
2015-12-14 09:03:59 -08:00
2016-02-11 10:21:39 -08:00
\changed {
2016-03-28 18:28:07 -07:00
\subparagraph { Uniqueness of $ \NoteAddressRandNew { i } $ } \label { uniquerho}
2016-02-07 14:37:36 -08:00
2016-03-06 20:36:29 -08:00
for each $ i \in \setofNew $ :
2016-03-28 18:28:07 -07:00
$ \NoteAddressRandNew { i } = \PRFrho { \NoteAddressPreRand } ( i, \hSig ) $ .
2016-02-11 10:21:39 -08:00
}
2016-02-07 14:37:36 -08:00
2015-12-14 09:03:59 -08:00
\subparagraph { Commitment integrity}
2016-03-18 14:09:24 -07:00
for each $ i \in \setofNew $ : $ \cmNew { i } $ = $ \Commitment ( \cNew { i } ) $ .
2016-02-25 10:32:18 -08:00
2016-02-27 12:58:39 -08:00
2016-03-05 12:20:11 -08:00
\section { In-band secret distribution} \label { inband}
2016-02-25 10:32:18 -08:00
2016-03-28 18:28:07 -07:00
In order to transmit the secret $ \Value $ , $ \NoteAddressRand $ , and $ \NoteCommitRand $
2016-02-25 10:32:18 -08:00
(necessary for the recipient to later spend) \changed { and also a \memo } to the
recipient \emph { without} requiring an out-of-band communication channel, the
\transmitKeypair public key $ \TransmitPublic $ is used to encrypt these
secrets. The recipient's possession of the associated
$ ( \PaymentAddress , \SpendingKey ) $ (which contains both $ \AuthPublic $ and
2016-03-28 18:28:07 -07:00
$ \TransmitPrivate $ ) is used to reconstruct the original \note \changed { and \memo } .
2016-02-25 10:32:18 -08:00
2016-03-28 18:28:07 -07:00
All of the resulting ciphertexts are combined to form a \notesCiphertext .
2016-02-25 10:32:18 -08:00
2016-03-29 19:28:01 -07:00
\newsavebox { \kdftagbox }
\begin { lrbox} { \kdftagbox }
\setchanged
\begin { bytefield} [bitwidth=0.16em]{ 128}
\bitbox { 64} { 64 bit $ \ascii { ZcashKDF } $ } &
\bitbox { 32} { 8 bit $ i \! - \! 1 $ }
\bitbox { 56} { $ \zeros { 56 } $ }
\end { bytefield}
\end { lrbox}
\newsavebox { \kdfinputbox }
\begin { lrbox} { \kdfinputbox }
2016-02-25 10:32:18 -08:00
\setchanged
2016-03-29 19:28:01 -07:00
\begin { bytefield} [bitwidth=0.04em]{ 1024}
\bitbox { 256} { 256-bit $ \hSig $ }
2016-02-25 10:32:18 -08:00
\bitbox { 256} { 256 bit $ \DHSecret { i } $ } &
\bitbox { 256} { 256 bit $ \EphemeralPublic $ } &
\bitbox { 256} { 256 bit $ \TransmitPublicNew { i } $ } &
\end { bytefield}
\end { lrbox}
2016-02-25 13:42:00 -08:00
\subsection { Encryption}
2016-02-25 10:32:18 -08:00
\changed {
2016-03-20 16:32:01 -07:00
Let $ \SymEncrypt { \Key } ( \Plaintext ) $ be authenticated encryption using
$ \SymSpecific $ \cite { rfc7539} encryption of plaintext $ \Plaintext $ , with empty
``associated data", all-zero nonce $ \zeros { 96 } $ , and 256-bit key $ \Key $ .
2016-03-02 08:09:52 -08:00
2016-03-20 16:32:01 -07:00
Similarly, let $ \SymDecrypt { \Key } ( \Ciphertext ) $ be $ \SymSpecific $
decryption of ciphertext $ \Ciphertext $ , with empty ``associated data",
all-zero nonce $ \zeros { 96 } $ , and 256-bit key $ \Key $ . The result is either
the plaintext byte sequence, or $ \bot $ indicating failure to decrypt.
2016-03-29 19:28:01 -07:00
}
Define:
2016-02-25 13:42:00 -08:00
2016-03-29 19:28:01 -07:00
\hskip 1.5em $ \KDF ( i, \hSig , \DHSecret { i } , \EphemeralPublic , \TransmitPublicNew { i } ) : =
2016-03-30 06:27:43 -07:00
\LeadingBytes { 32} (\BlakeHash (\kdftag , \kdfinput ))$
2016-03-29 19:28:01 -07:00
where:
2016-02-25 13:42:00 -08:00
2016-03-29 19:28:01 -07:00
\hskip 1.5em $ \kdftag : = \Justthebox { \kdftagbox } { - 1 . 3 ex } $
2016-03-22 10:41:57 -07:00
2016-03-29 19:28:01 -07:00
\hskip 1.5em $ \kdfinput : = \Justthebox { \kdfinputbox } { - 1 . 3 ex } $ .
2016-02-25 10:32:18 -08:00
2016-03-29 19:28:01 -07:00
\vspace { 2ex}
2016-03-06 20:36:29 -08:00
Let $ \TransmitPublicNew { \allNew } $ be the \changed { Curve25519} public keys
2016-03-28 18:28:07 -07:00
for the intended recipient addresses of each new \note , and let
$ \NotePlaintext { \allNew } $ be the \notePlaintexts . Let $ \hSig $ be the
2016-03-22 10:41:57 -07:00
value computed in \crossref { hsig} .
2016-02-25 13:42:00 -08:00
2016-02-25 10:32:18 -08:00
Then to encrypt:
\begin { itemize}
\changed {
2016-02-25 13:42:00 -08:00
\item Generate a new Curve25519 (public, private) key pair
2016-03-02 08:09:52 -08:00
$ ( \EphemeralPublic , \EphemeralPrivate ) $ .
2016-03-06 20:36:29 -08:00
\item For $ i \in \setofNew $ ,
2016-02-25 10:32:18 -08:00
\begin { itemize}
2016-03-28 18:28:07 -07:00
\item Let $ \TransmitPlaintext { i } $ be the raw encoding of $ \NotePlaintext { i } $ .
2016-02-27 13:12:50 -08:00
\item Let $ \DHSecret { i } : = \CurveMultiply ( \EphemeralPrivate ,
\TransmitPublicNew { i} )$ .
2016-03-22 13:40:52 -07:00
\item Let $ \TransmitKey { i } : = \KDF ( i, \hSig , \DHSecret { i } , \EphemeralPublic ,
\TransmitPublicNew { i} )$ .
2016-02-25 13:42:00 -08:00
\item Let $ \TransmitCiphertext { i } : =
2016-02-25 17:56:04 -08:00
\SymEncrypt { \TransmitKey { i} } (\TransmitPlaintext { i} )$ .
2016-02-25 10:32:18 -08:00
\end { itemize}
2016-03-03 10:43:10 -08:00
}
2016-02-25 10:32:18 -08:00
\end { itemize}
2016-03-28 18:28:07 -07:00
The resulting \notesCiphertext is $ \changed { ( \EphemeralPublic ,
2016-03-12 18:16:30 -08:00
\TransmitCiphertext { \allNew } )} $ .
2016-02-25 10:32:18 -08:00
2016-02-25 13:42:00 -08:00
\subsection { Decryption by a Recipient}
2016-03-20 16:36:54 -07:00
Let $ \PaymentAddress = ( \AuthPublic , \TransmitPublic ) $ be the recipient's
\paymentAddress , and let $ \TransmitPrivate $ be the recipient's \changed { Curve25519}
2016-03-22 10:41:57 -07:00
private key. Let $ \hSig $ be the value computed in \crossref { hsig} .
2016-03-28 18:28:07 -07:00
Let $ \cmNew { \allNew } $ be the \noteCommitments of each output coin.
2016-03-20 16:36:54 -07:00
Then for each $ i \in \setofNew $ , the recipient will attempt to decrypt that ciphertext
component as follows:
2016-02-25 10:32:18 -08:00
\changed {
\begin { itemize}
2016-02-27 13:12:50 -08:00
\item Let $ \DHSecret { i } : = \CurveMultiply ( \TransmitPrivate , \EphemeralPublic ) $ .
2016-03-22 13:40:52 -07:00
\item Let $ \TransmitKey { i } : = \KDF ( i, \hSig , \DHSecret { i } , \EphemeralPublic ,
\TransmitPublicNew { i} )$ .
2016-03-20 16:36:54 -07:00
\item Return $ \DecryptNote ( \TransmitKey { i } , \TransmitCiphertext { i } , \cmNew { i } ,
\AuthPublic ).$
2016-02-25 10:32:18 -08:00
\end { itemize}
2016-03-20 16:36:54 -07:00
$ \DecryptNote ( \TransmitKey { i } , \TransmitCiphertext { i } , \cmNew { i } , \AuthPublic ) $
is defined as follows:
2016-02-25 10:32:18 -08:00
\begin { itemize}
2016-02-25 13:42:00 -08:00
\item Let $ \TransmitPlaintext { i } : =
2016-02-25 17:56:04 -08:00
\SymDecrypt { \TransmitKey { i} } (\TransmitCiphertext { i} )$ .
2016-02-25 10:32:18 -08:00
\item If $ \TransmitPlaintext { i } = \bot $ , return $ \bot $ .
2016-03-28 18:28:07 -07:00
\item Extract $ \NotePlaintext { i } = ( \ValueNew { i } ,
\NoteAddressRandNew { i} , \NoteCommitRandNew { i} , \Memo _ i)$ from $ \TransmitPlaintext { i} $ .
\item If $ \Commitment ( ( \AuthPublic , \ValueNew { i } , \NoteAddressRandNew { i } ,
\NoteCommitRandNew { i} )) \neq \cmNew { i} $ , return $ \bot $ , else return $ \NotePlaintext { i} $ .
2016-02-25 10:32:18 -08:00
\end { itemize}
}
Note that this corresponds to step 3 (b) i. and ii. (first bullet point) of the
$ \Receive $ algorithm shown in Figure 2 of \cite { ZerocashOakland} .
2016-03-28 18:28:07 -07:00
To test whether a \note is unspent in a particular \blockchainview also requires
2016-02-25 10:32:18 -08:00
the \authKeypair private key $ \AuthPrivate $ ; the coin is unspent if and only if
2016-03-29 17:36:34 -07:00
$ \nf = \PRFnf { \AuthPrivate } ( \NoteAddressRand ) $ is not in the \nullifierSet
2016-02-25 10:32:18 -08:00
for that \blockchainview .
2016-03-28 18:28:07 -07:00
Note that a \note may change from being unspent to spent on a given \blockchainview ,
2016-03-28 17:19:34 -07:00
as \transactions are added to that view. Also, blockchain reorganisations may cause
2016-03-28 18:28:07 -07:00
the \transaction in which a \note was output to no longer be on the consensus
2016-02-25 10:32:18 -08:00
blockchain.
2016-03-03 10:43:10 -08:00
\changed {
\subsection { Commentary}
2016-02-25 10:32:18 -08:00
The public key encryption used in this part of the protocol is based loosely on
2016-02-25 13:42:00 -08:00
other encryption schemes based on Diffie-Hellman over an elliptic curve, such
as ECIES or the $ \CryptoBoxSeal $ algorithm defined in libsodium \cite { cryptoboxseal} .
Note that:
2016-03-03 10:43:10 -08:00
}
2016-02-25 10:32:18 -08:00
\begin { itemize}
2016-03-03 10:43:10 -08:00
\changed {
2016-02-25 10:32:18 -08:00
\item The same ephemeral key is used for all encryptions to the recipient keys
2016-03-28 18:28:50 -07:00
in a given \joinSplitDescription .
2016-02-25 13:42:00 -08:00
\item In addition to the Diffie-Hellman secret, the KDF takes as input the
2016-03-29 19:32:28 -07:00
seed $ \hSig $ , the public keys of both parties, and the index $ i $ .
2016-02-25 17:56:04 -08:00
\item The nonce parameter to $ \SymSpecific $ is not used.
2016-03-29 19:32:28 -07:00
\item The ``IETF" definition of $ \SymSpecific $ from \cite { rfc7539} is
used; this uses a 32-bit block count and a 96-bit nonce, rather than a 64-bit
block count and 64-bit nonce as in the original definition of $ \SymCipher $ .
2016-03-03 10:43:10 -08:00
}
\end { itemize}
2016-02-25 10:32:18 -08:00
2015-12-14 09:03:59 -08:00
2016-03-05 10:37:40 -08:00
\section { Encoding Addresses and Keys}
2015-12-16 12:55:16 -08:00
2016-03-12 18:16:30 -08:00
This section describes how \Zcash encodes \paymentAddresses and \spendingKeys .
2015-12-16 12:55:16 -08:00
2016-03-06 19:38:00 -08:00
Addresses and keys can be encoded as a byte sequence; this is called
the \term { raw encoding} . This byte sequence can then be further encoded using
2016-01-26 15:36:29 -08:00
Base58Check. The Base58Check layer is the same as for upstream \Bitcoin
addresses \cite { Base58Check} .
2015-12-16 12:55:16 -08:00
2016-03-06 19:38:00 -08:00
SHA-256 compression function outputs are always represented as sequences of 32
2015-12-16 12:55:16 -08:00
bytes.
The language consisting of the following encoding possibilities is prefix-free.
2016-02-25 10:32:18 -08:00
\subsection { Transparent Payment Addresses}
2015-12-16 13:02:22 -08:00
2016-01-26 15:36:29 -08:00
These are encoded in the same way as in \Bitcoin \cite { Base58Check} .
2015-12-16 13:02:22 -08:00
2016-01-26 15:15:17 -08:00
\subsection { Transparent Private Keys}
2015-12-16 13:02:22 -08:00
2016-01-26 15:36:29 -08:00
These are encoded in the same way as in \Bitcoin \cite { Base58Check} .
2015-12-16 13:02:22 -08:00
2016-03-20 16:32:01 -07:00
\subsection { Protected Payment Addresses}
2015-12-16 12:55:16 -08:00
2016-02-16 12:07:31 -08:00
A \paymentAddress consists of $ \AuthPublic $ and $ \TransmitPublic $ .
$ \AuthPublic $ is a SHA-256 compression function output.
2016-02-11 07:04:56 -08:00
$ \TransmitPublic $ is a \changed { Curve25519} public key, for use with the
2016-03-05 12:20:11 -08:00
encryption scheme defined in \crossref { inband} .
2015-12-16 12:55:16 -08:00
2016-02-25 11:41:06 -08:00
The raw encoding of a \paymentAddress consists of:
2015-12-16 12:55:16 -08:00
\begin { equation*}
2016-02-08 16:51:25 -08:00
\begin { bytefield} [bitwidth=0.07em]{ 520}
2016-02-16 12:07:31 -08:00
\changed {
2016-03-06 19:38:00 -08:00
\bitbox { 72} { 8 bit $ \PaymentAddressLeadByte $ }
2016-02-26 09:22:59 -08:00
& } \bitbox { 256} { 256 bit $ \AuthPublic $ } &
2016-02-26 08:36:59 -08:00
\bitbox { 256} { \changed { 256 bit} $ \TransmitPublic $ }
2015-12-16 12:55:16 -08:00
\end { bytefield}
\end { equation*}
\begin { itemize}
2016-02-11 07:04:56 -08:00
\changed {
2016-02-16 12:07:31 -08:00
\item A byte, $ \PaymentAddressLeadByte $ , indicating this version of the
2015-12-22 15:58:55 -08:00
raw encoding of a \Zcash public address.
2016-02-11 07:04:56 -08:00
}
2016-02-26 09:22:59 -08:00
\item 256 bits specifying $ \AuthPublic $ .
2016-02-26 08:36:59 -08:00
\item \changed { 256 bits} specifying $ \TransmitPublic $ , \changed { using the
2016-02-11 07:04:56 -08:00
normal encoding of a Curve25519 public key \cite { Curve25519} } .
2015-12-16 12:55:16 -08:00
\end { itemize}
2016-01-26 15:15:17 -08:00
\daira { check that this lead byte is distinct from other Bitcoin stuff,
2015-12-22 15:58:55 -08:00
and produces `z' as the Base58Check leading character.}
2015-12-16 12:55:16 -08:00
2016-01-26 15:15:17 -08:00
\nathan { what about the network version byte?}
2015-12-16 12:55:16 -08:00
2016-02-25 10:32:18 -08:00
\subsection { Spending Keys}
2015-12-16 12:55:16 -08:00
2016-03-30 06:27:43 -07:00
A \spendingKey consists of $ \AuthPrivate $ , which is a sequence of 252 bits.
2015-12-16 12:55:16 -08:00
2016-02-25 11:41:06 -08:00
The raw encoding of a \spendingKey consists of, in order:
2015-12-16 12:55:16 -08:00
\begin { equation*}
2016-02-25 11:41:06 -08:00
\begin { bytefield} [bitwidth=0.07em]{ 264}
2016-02-16 12:07:31 -08:00
\changed {
2016-03-06 19:38:00 -08:00
\bitbox { 72} { 8 bit $ \SpendingKeyLeadByte $ }
\bitbox { 32} { $ \zeros { 4 } $ } &
2016-02-26 09:22:59 -08:00
& } \bitbox { 252} { \changed { 252} bit $ \AuthPrivate $ }
2015-12-16 12:55:16 -08:00
\end { bytefield}
\end { equation*}
\begin { itemize}
2016-02-11 07:04:56 -08:00
\changed {
2016-02-16 12:07:31 -08:00
\item A byte $ \SpendingKeyLeadByte $ indicating this version of the
2016-02-25 11:41:06 -08:00
raw encoding of a \Zcash \spendingKey .
2016-02-26 08:36:59 -08:00
\item 4 zero padding bits.
2016-02-11 07:04:56 -08:00
}
2016-02-26 09:22:59 -08:00
\item \changed { 252} bits specifying $ \AuthPrivate $ .
2015-12-16 12:55:16 -08:00
\end { itemize}
2016-03-30 06:27:43 -07:00
The zero padding occupies the most significant 4 bits of the second byte.
2016-03-20 16:19:38 -07:00
\subparagraph { Note:} If an implementation represents $ \AuthPrivate $
internally as a sequence of 32 bytes with the 4 bits of zero padding
intact, it will be in the correct form for use as an input to
2016-03-29 17:36:34 -07:00
$ \PRFaddr { } $ , $ \PRFnf { } $ , and $ \PRFpk { } $ without need for bit-shifting.
2016-03-20 16:19:38 -07:00
Future key representations may make use of these padding bits.
2016-02-26 08:36:59 -08:00
2016-01-26 15:15:17 -08:00
\daira { check that this lead byte is distinct from other Bitcoin stuff,
2016-02-25 11:41:06 -08:00
and produces a suitable Base58Check leading character.}
2015-12-16 12:55:16 -08:00
2016-01-26 15:15:17 -08:00
\nathan { what about the network version byte?}
2015-12-16 12:55:16 -08:00
2016-02-25 10:32:18 -08:00
\section { Differences from the Zerocash paper}
2015-12-16 12:55:16 -08:00
2016-03-12 17:23:04 -08:00
\subsection { Transaction Structure} \label { trstructure}
\Zerocash introduces two new operations, which are described in
the paper as new transaction types, in addition to the original
transaction type of the cryptocurrency on which it is based
(e.g. \Bitcoin ).
In \Zcash , there is only the original \Bitcoin transaction type,
which is extended to contain a sequence of zero or more
\Zcash -specific operations.
This allows for the possibility of chaining transfers of protected
2016-03-28 18:28:07 -07:00
value in a single \Zcash \transaction , e.g. to spend a protected \note
2016-03-20 13:26:37 -07:00
that has just been created. (In \Zcash , we refer to value stored in
2016-03-28 18:28:50 -07:00
UTXOs as ``transparent'', and value stored in \joinSplitTransfer output
2016-03-28 18:28:07 -07:00
\notes as ``protected''.)
2016-03-12 17:23:04 -08:00
This was not possible in the \Zerocash design without using multiple
transactions. It also allows transparent and protected transfers to
happen atomically --- possibly under the control of nontrivial script
conditions, at some cost in distinguishability.
2016-03-15 18:36:37 -07:00
\todo { Describe changes to signing.}
2016-03-12 17:23:04 -08:00
2016-02-26 16:54:06 -08:00
\subsection { Unification of Mints and Pours}
2016-03-12 17:23:04 -08:00
In the original \Zerocash protocol, there were two kinds of transaction
2016-03-28 18:28:07 -07:00
relating to protected \notes :
2016-03-12 17:23:04 -08:00
\begin { itemize}
\item a ``Mint'' transaction takes value from transparent UTXOs as
2016-03-28 18:28:07 -07:00
input and produces a new protected \note as output.
2016-03-12 17:23:04 -08:00
\item a ``Pour'' transaction takes up to $ \NOld $ protected
2016-03-28 18:28:07 -07:00
\notes as input, and produces up to $ \NNew $ protected \notes and a
2016-03-12 17:23:04 -08:00
transparent UTXO as output.
\end { itemize}
Only ``Pour'' transactions included a \zkSNARK proof.
2016-03-20 13:26:37 -07:00
In \Zcash , the sequence of operations added to a \transaction
2016-03-28 18:28:50 -07:00
(described in \crossref { trstructure} ) consists only of \joinSplitTransfers .
A \joinSplitTransfer is a Pour operation generalized to take a transparent
UTXO as input, allowing \joinSplitTransfers to subsume the functionality of
2016-03-18 14:09:24 -07:00
Mints. An advantage of this is that a \Zcash \transaction that takes
2016-03-28 18:28:07 -07:00
input from an UTXO can produce up to $ \NNew $ output \notes , improving
2016-03-18 14:09:24 -07:00
the indistinguishability properties of the protocol. A related change
2016-03-28 18:28:50 -07:00
conceals the input arity of the \joinSplitTransfer : an unused (zero-value)
2016-03-28 18:28:07 -07:00
input is indistinguishable from an input that takes value from a \note .
2016-03-12 17:23:04 -08:00
This unification also simplifies the fix to the Faerie Gold attack
described below, since no special case is needed for Mints.
2016-03-18 14:09:24 -07:00
\subsection { \Memos }
2016-03-12 17:23:04 -08:00
2016-03-28 18:28:50 -07:00
\Zcash adds a \memo sent from the creator of a \joinSplitDescription to
2016-03-28 18:28:07 -07:00
the recipient of each output \note . This feature is described in
more detail in \crossref { notept} .
2016-03-12 17:23:04 -08:00
2016-02-26 16:54:06 -08:00
2016-02-25 10:32:18 -08:00
\subsection { Faerie Gold attack and fix}
2016-02-11 07:04:56 -08:00
2016-03-28 18:28:07 -07:00
When a protected \note is created in \Zerocash , the creator is
supposed to choose a new $ \NoteAddressRand $ value at random.
2016-03-29 17:36:34 -07:00
The \nullifier of the \note is derived from its \spendingKey
2016-03-28 18:28:07 -07:00
($ \AuthPrivate $ ) and $ \NoteAddressRand $ . The \noteCommitment
2016-03-12 17:23:04 -08:00
is derived from the recipient address component $ \AuthPublic $ ,
2016-03-28 18:28:07 -07:00
the value $ \Value $ , and the commitment trapdoor $ \NoteCommitRand $ ,
as well as $ \NoteAddressRand $ . However nothing prevents creating
multiple \notes with different $ \Value $ and $ \NoteCommitRand $
(hence different \noteCommitments ) but the same $ \NoteAddressRand $ .
2016-03-12 17:23:04 -08:00
2016-03-28 18:28:07 -07:00
An adversary can use this to mislead a \note recipient, by sending
two \notes both of which are verified as valid by $ \Receive $ (as
2016-03-12 17:23:04 -08:00
defined in Figure 2 of \cite { ZerocashOakland} ), but only one of
which can be spent.
We call this a ``Faerie Gold'' attack --- referring to various Celtic
legends in which faeries pay mortals in what appears to be gold,
but which soon after reveals itself to be leaves, gorse blossoms,
gingerbread cakes, or other less valuable things \cite { LG2004} .
This attack does not violate the security definitions given in
\cite { ZerocashOakland} . The issue could be framed as a problem
either with the definition of Completeness, or the definition of
Balance:
\begin { itemize}
\item The Completeness property asserts that a validly received
2016-03-29 17:36:34 -07:00
\note can be spent provided that its \nullifier does not appear
2016-03-12 17:23:04 -08:00
on the ledger. This does not take into account the possibility
2016-03-28 18:28:07 -07:00
that distinct \notes , which are validly received, could have the
2016-03-29 17:36:34 -07:00
same \nullifier . That is, the security definition depends on
a protocol detail --\nullifiers -- that is not part of the
2016-03-12 17:23:04 -08:00
intended abstract security property, and that could be implemented
incorrectly.
\item The Balance property only asserts that an adversary cannot
obtain \emph { more} funds than they have minted or received via
payments. It does not prevent an adversary from causing others'
funds to decrease. In a Faerie Gold attack, an adversary can cause
2016-03-28 18:28:07 -07:00
spending of a \note to reduce (to zero) the effective value of another
\note for which the attacker does not know the \spendingKey , which
2016-03-12 17:23:04 -08:00
violates an intuitive conception of global balance.
\end { itemize}
These problems with the security definitions need to be repaired,
but doing so is outside the scope of this specification. Here we
only describe how \Zcash addresses the immediate attack.
It would be possible to address the attack by requiring that a
2016-03-28 18:28:07 -07:00
recipient remember all of the $ \NoteAddressRand $ values for all
\notes they have ever received, and reject duplicates (as proposed
2016-03-12 17:23:04 -08:00
in \cite { GGM2016} ). However, this requirement would interfere
with the intended \Zcash feature that a holder of a \spendingKey
can recover access to (and be sure that they are able to spend) all
of their funds, even if they have forgotten everything but the
\spendingKey .
Instead, \Zcash enforces that an adversary must choose distinct values
2016-03-28 18:28:07 -07:00
for each $ \NoteAddressRand $ , by making use of the fact that all of the
2016-03-29 17:36:34 -07:00
\nullifiers in \joinSplitDescriptions that appear in a valid \blockchainview
2016-03-29 19:28:01 -07:00
must be distinct. The \nullifiers are used as input to $ \BlakeHashName $
2016-03-12 17:23:04 -08:00
to derive a public value $ \hSig $ which uniquely identifies the transaction,
as described in \crossref { hsig} . ($ \hSig $ was already used in \Zerocash
in a way that requires it to be unique in order to maintain
2016-03-29 17:36:34 -07:00
indistinguishability of \joinSplitDescriptions ; adding the \nullifiers
2016-03-12 17:23:04 -08:00
to the input of the hash used to calculate it has the effect of making
this uniqueness property robust even if the \transaction creator is an
adversary.)
2016-03-28 18:28:07 -07:00
The $ \NoteAddressRand $ value for each output \note is then derived from
a random private seed $ \NoteAddressPreRand $ and $ \hSig $ using
$ \PRFrho { \NoteAddressPreRand } $ . The correct construction of
$ \NoteAddressRand $ for each output \note is enforced by the circuit
2016-03-12 17:23:04 -08:00
(see \crossref { uniquerho} ).
2016-03-28 18:28:50 -07:00
Now even if the creator of a \joinSplitDescription does not choose
2016-03-29 17:36:34 -07:00
$ \NoteAddressPreRand $ randomly, uniqueness of \nullifiers and
2016-03-29 19:28:01 -07:00
collision resistance of both $ \BlakeHashName $ and $ \PRFrho { } $ will ensure
2016-03-28 18:28:07 -07:00
that the derived $ \NoteAddressRand $ values are unique, at least for
2016-03-28 18:28:50 -07:00
any two \joinSplitDescriptions that get into a valid \blockchainview .
2016-03-12 17:23:04 -08:00
This is sufficient to prevent the Faerie Gold attack.
2015-12-16 12:55:16 -08:00
2016-02-26 16:54:06 -08:00
\subsection { Internal hash collision attack and fix}
The \Zerocash security proof requires that the composition of
2016-03-28 18:28:07 -07:00
$ \COMM { \NoteCommitRand } $ and $ \COMM { \NoteCommitS } $ is a computationally
2016-02-26 16:54:06 -08:00
binding commitment to its inputs $ \AuthPublic $ , $ \Value $ , and
2016-03-28 18:28:07 -07:00
$ \NoteAddressRand $ . However, the instantiation of $ \COMM { \NoteCommitRand } $
and $ \COMM { \NoteCommitS } $ in section 5.1 of the paper did not meet
2016-02-26 16:54:06 -08:00
the definition of a binding commitment at a 128-bit security level.
2016-03-28 18:28:07 -07:00
Specifically, the internal hash of $ \AuthPublic $ and $ \NoteAddressRand $
2016-02-26 16:54:06 -08:00
is truncated to 128 bits (motivated by providing statistical hiding
security). This allows an attacker, with a work factor on the order of
2016-03-28 18:28:07 -07:00
$ 2 ^ { 64 } $ , to find distinct values of $ \NoteAddressRand $ with colliding
outputs of the truncated hash, and therefore the same \noteCommitment .
2016-02-26 16:54:06 -08:00
This would have allowed such an attacker to break the balance property
2016-03-28 18:28:07 -07:00
by double-spending \notes , potentially creating arbitrary amounts of
2016-02-26 16:54:06 -08:00
currency for themself.
\Zcash uses a simpler construction with a single $ \FullHash $ evaluation
for the commitment. The motivation for the nested construction in \Zerocash
was to allow Mint transactions to be publically verified without requiring
a ZK proof (as described under step 3 in section 1.3 of
\cite { ZerocashOakland} ). Since \Zcash combines ``Mint'' and ``Pour''
2016-03-28 18:28:50 -07:00
transactions into a generalized \joinSplitTransfer which always uses a ZK proof,
2016-03-18 14:09:24 -07:00
it does not require the nesting. A side benefit is that this reduces the
2016-03-28 18:28:07 -07:00
number of $ \SHA $ evaluations needed to compute each \noteCommitment from
2016-02-26 16:54:06 -08:00
three to two, saving a total of four $ \SHA $ evaluations in the
2016-03-28 18:28:50 -07:00
$ \JoinSplitCircuit $ .
2016-02-26 16:54:06 -08:00
2016-03-28 18:28:07 -07:00
Note that \Zcash \noteCommitments are not statistically hiding, and
2016-02-26 16:54:06 -08:00
so \Zcash does not support the ``everlasting anonymity'' property
described in section 8.1 of the \Zerocash paper \cite { ZerocashOakland} ,
even when used as described in that section. While it is possible to
define a statistically hiding, computationally binding commitment scheme
for this use at a 128-bit security level, the overhead of doing so
within the circuit was not considered to justify the benefits.
\subsection { Changes to PRF inputs and truncation}
\todo { }
2016-03-30 06:27:43 -07:00
%The need for collision resistance of \CRH(.) truncated to 253 bits was not
2016-02-26 16:54:33 -08:00
%explicitly stated in \ (This does not follow from collision resistance of $\CRH$.)
2016-02-25 10:32:18 -08:00
\subsection { In-band secret distribution}
2015-12-16 12:55:16 -08:00
2016-02-25 10:32:18 -08:00
\todo { }
2016-02-01 14:08:13 -08:00
2016-02-25 10:32:18 -08:00
\subsection { Miscellaneous}
2016-02-01 14:08:13 -08:00
\begin { itemize}
2016-03-28 18:28:07 -07:00
\item The paper defines a \note as a tuple $ ( \AuthPublic , \Value ,
\NoteAddressRand , \NoteCommitRand , \NoteCommitS , \cm )$ , whereas this specification
defines it as $ ( \AuthPublic , \Value , \NoteAddressRand , \NoteCommitRand ) $ .
This is just a clarification, because the instantiation of $ \COMM { \NoteCommitS } $
in section 5.1 of the paper did not use $ \NoteCommitS $ (and neither does the
2016-03-18 14:09:24 -07:00
new instantiation of $ \Commitment $ ). $ \cm $ can be computed from the other
2016-02-26 16:54:06 -08:00
fields.
2016-02-01 14:08:13 -08:00
\end { itemize}
2016-02-26 16:54:33 -08:00
\section { Acknowledgements}
The inventors of \Zerocash are Eli Ben-Sasson, Alessandro Chiesa,
Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars
Virza.
The authors would like to thank everyone with whom they have discussed
the \Zerocash protocol design; in addition to the inventors, this includes
Mike Perry, Isis Lovecruft, Leif Ryge, Andrew Miller, Zooko Wilcox,
2016-03-12 17:23:04 -08:00
Samantha Hulsey, and no doubt others.
2016-02-26 16:54:33 -08:00
The Faerie Gold attack was found by Zooko Wilcox.
The internal hash collision attack was found by Taylor Hornby.
2016-01-26 15:15:17 -08:00
\section { References}
2016-01-26 16:32:57 -08:00
\begingroup
\renewcommand { \section } [2]{ }
\bibliographystyle { plain}
2016-01-26 15:15:17 -08:00
\bibliography { zcash}
2016-01-26 16:32:57 -08:00
\endgroup
2016-01-26 15:15:17 -08:00
2015-12-14 09:03:59 -08:00
\end { document}