Fix the lead bytes in payment address and spending key encodings.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

protocol/protocol.tex

@@ -235,8 +235,14 @@
 % key pairs:
 \newcommand{\PaymentAddress}{\mathsf{addr_{pk}}}
 \newcommand{\SpendingKey}{\mathsf{addr_{sk}}}
-\newcommand{\PaymentAddressLeadByte}{\hexint{92}}
-\newcommand{\SpendingKeyLeadByte}{\hexint{??}}
+\newcommand{\PaymentAddressLeadByte}{\hexint{16}}
+\newcommand{\PaymentAddressSecondByte}{\hexint{9A}}
+\newcommand{\SpendingKeyLeadByte}{\hexint{AB}}
+\newcommand{\SpendingKeySecondByte}{\hexint{36}}
+\newcommand{\PaymentAddressTestnetLeadByte}{\hexint{14}}
+\newcommand{\PaymentAddressTestnetSecondByte}{\hexint{51}}
+\newcommand{\SpendingKeyTestnetLeadByte}{\hexint{B1}}
+\newcommand{\SpendingKeyTestnetSecondByte}{\hexint{EB}}
 \newcommand{\NotePlaintextLeadByte}{\hexint{00}}
 \newcommand{\AuthPublic}{\mathsf{a_{pk}}}
 \newcommand{\AuthPrivate}{\mathsf{a_{sk}}}
@@ -1598,7 +1604,7 @@ The first three of these fields are as defined earlier.
 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 a UTF-8 human-readable string \cite{Unicode}, padded by appending zero bytes; or
   \item an arbitrary sequence of 128 bytes starting with a byte value of $\hexint{F5}$
         or greater, which is therefore not a valid UTF-8 string.
 \end{itemize}
@@ -1673,7 +1679,8 @@ The raw encoding of a \paymentAddress consists of:
 \begin{equation*}
 \begin{bytefield}[bitwidth=0.07em]{520}
 \changed{
-    \bitbox{72}{$8$-bit $\PaymentAddressLeadByte$}
+    \bitbox{80}{$8$-bit $\PaymentAddressLeadByte$}
+    \bitbox{80}{$8$-bit $\PaymentAddressSecondByte$}
   &}\bitbox{256}{$256$-bit $\AuthPublic$} &
     \bitbox{256}{\changed{$256$}-bit $\TransmitPublic$}
 \end{bytefield}
@@ -1681,29 +1688,28 @@ The raw encoding of a \paymentAddress consists of:
 
 \begin{itemize}
 \changed{
-    \item A byte, $\PaymentAddressLeadByte$, indicating this version of the
-        raw encoding of a \Zcash \paymentAddress.
+    \item Two bytes $[\PaymentAddressLeadByte, \PaymentAddressSecondByte]$,
+        indicating this version of the raw encoding of a \Zcash \paymentAddress
+        on the production network. (Addresses on the test network use
+        $[\PaymentAddressTestnetLeadByte, \PaymentAddressTestnetSecondByte]$
+        instead.)
 }
     \item 256 bits specifying $\AuthPublic$.
     \item \changed{256 bits} specifying $\TransmitPublic$, \changed{using the
         normal encoding of a Curve25519 public key \cite{Curve25519}}.
 \end{itemize}
 
-\daira{check that this lead byte is distinct from other Bitcoin stuff,
-and produces `z' as the Base58Check leading character.}
-
-\nathan{what about the network version byte?}
-
 \nsubsubsection{Spending Keys}
 
-A \spendingKey consists of $\AuthPrivate$, which is a sequence of 252 bits.
+A \spendingKey consists of $\AuthPrivate$, which is a sequence of \changed{252} bits.
 
 The raw encoding of a \spendingKey consists of, in order:
 
 \begin{equation*}
 \begin{bytefield}[bitwidth=0.07em]{264}
 \changed{
-    \bitbox{72}{$8$-bit $\SpendingKeyLeadByte$}
+    \bitbox{80}{$8$-bit $\SpendingKeyLeadByte$}
+    \bitbox{80}{$8$-bit $\SpendingKeySecondByte$}
     \bitbox{32}{$\zeros{4}$} &
   &}\bitbox{252}{\changed{$252$}-bit $\AuthPrivate$}
 \end{bytefield}
@@ -1711,25 +1717,25 @@ The raw encoding of a \spendingKey consists of, in order:
 
 \begin{itemize}
 \changed{
-    \item A byte $\SpendingKeyLeadByte$ indicating this version of the
-        raw encoding of a \Zcash \spendingKey.
+    \item Two bytes $[\SpendingKeyLeadByte, \SpendingKeySecondByte]$,
+        indicating this version of the raw encoding of a \Zcash \spendingKey
+        on the production network. (Addresses on the test network use
+        $[\SpendingKeyTestnetLeadByte, \SpendingKeyTestnetSecondByte]$
+        instead.)
     \item 4 zero padding bits.
 }
     \item \changed{252} bits specifying $\AuthPrivate$.
 \end{itemize}
 
-The zero padding occupies the most significant 4 bits of the second byte.
+\changed{
+The zero padding occupies the most significant 4 bits of the third byte.
 
 \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
 $\PRFaddr{}$, $\PRFnf{}$, and $\PRFpk{}$ without need for bit-shifting.
 Future key representations may make use of these padding bits.
-
-\daira{check that this lead byte is distinct from other Bitcoin stuff,
-and produces a suitable Base58Check leading character.}
-
-\nathan{what about the network version byte?}
+}
 
 
 \nsection{Differences from the Zerocash paper}