diff --git a/render.sh b/render.sh
index 4ff61157c..e2a4f6459 100755
--- a/render.sh
+++ b/render.sh
@@ -24,6 +24,11 @@ if ! [ -f "${inputfile}" ]; then
exit
fi
+# Set RENDER_INTERMEDIATE to a path to capture the post-sed, pre-renderer stream
+# (used by the render regression tests; see test/). Defaults to /dev/null, so normal
+# runs are unaffected and the `tee` below is a harmless pass-through.
+intermediate="${RENDER_INTERMEDIATE:-/dev/null}"
+
if [ "x$1" = "x--rst" ]; then
filetype='.rst'
else
@@ -38,34 +43,54 @@ Math3=''
+# Our `style.css` must load *after* KaTeX's CSS so that our `.katex .*` overrides win the
+# cascade (several KaTeX font rules have the same specificity as ours). Both paths inject
+# `ViewAndStyle` at the end of ``, so our stylesheet always loads last. (Unlike
+# ``, the viewport meta has no early-placement requirement.)
ViewAndStyle=''
cat <(
- if [ "x$1" = "x--rst" ]; then
- # These are basic regexps so \+ is needed, not +.
- # We use the Unicode 💲 character to move an escaped $ out of the way,
- # which is much easier than trying to handle escapes within a capture.
+ # These are basic regexps so \+ is needed, not +, and similarly for \?.
+ # We use the Unicode 💲 character to move an escaped $ out of the way,
+ # which is much easier than trying to handle escapes within a capture.
+ # In both rst and Markdown, we must be careful not to rewrite a math span
+ # so that it has a non-whitespace character immediately after it.
- cat "${inputfile}" \
- | sed 's|[\][$]|💲|g;
- s|[$]\([^$]\+\)[$]\([.,:;!?)-]\)|:math:`\1\\!`\2|g;
+ if [ "x$1" = "x--rst" ]; then
+ # For rst we want to unescape `\$`, because $ is not reserved without our $ extension.
+ cat "${inputfile}" |
+ sed 's|[\][$]|💲|g;
+ s|[$]\([^$]\+\)[$]\([—)-]\)|:math:`\1\\kern-0.15em` \2|g;
+ s|[$]\([^$]\+\)[$]\([.,:;!?]\)$|:math:`\1\\kern-0.03em\\textsf{\2}`|g;
+ s|[$]\([^$]\+\)[$]\([.,:;!?]\)\ |:math:`\1\\kern-0.03em\\textsf{\2}` |g;
s|[$]\([^$]\+\)[$]|:math:`\1`|g;
- s|💲|$|g' \
- | rst2html5 -v --title="${title}" - \
- | sed "s||${Math1}\n ${Math2}\n ${Math3}|;
+ s|💲|$|g' |
+ tee "${intermediate}" |
+ rst2html5 -v --title="${title}" - |
+ sed "s||${Math1}\n ${Math2}\n ${Math3}|;
s||${ViewAndStyle}|"
else
if [ "x$1" = "x--pandoc" ]; then
# Not actually MathJax. KaTeX is compatible if we use the right headers.
pandoc --mathjax --from=markdown --to=html "${inputfile}" --output="${outputfile}.temp"
else
- cat "${inputfile}" \
- | sed 's|[\][$]|💲|g;
- s|[$]\([.,:;!?-][^ $]\)|💲\1|g;
- s|[$]\([.,:;!?-]\)|\\kern-0.05em\\textsf{\\small \1}$|g;
- s|[$]—|\\kern-0.3em$ —|g;
- s|💲|$|g' \
- | multimarkdown -o "${outputfile}.temp"
+ # For Markdown we just want to protect `\$`.
+ # We match a whole `$...$` span (as the rst rules above do), so we only
+ # ever rewrite a *closing* delimiter. Matching a lone `$` would misfire
+ # on the *opening* `$` of a span whose content starts with punctuation
+ # (e.g. `$-x$`). Caveat: this is line-by-line, so a multi-line `$...$`
+ # span (which Markdown allows) is not matched. Punctuation just after
+ # such a span won't be fixed, and a line carrying both one span's close
+ # and another's open can still mismatch. These cases are rare, would show
+ # up when reviewing rendered output, and are easy to work around.
+ cat "${inputfile}" |
+ sed 's|[\][$]|💲|g;
+ s|[$]\([^$]\+\)[$]\([—)-]\)|$\1\\kern-0.15em$ \2|g;
+ s|[$]\([^$]\+\)[$]\([.,:;!?]\)$|$\1\\kern-0.05em\\textsf{\2}$|g;
+ s|[$]\([^$]\+\)[$]\([.,:;!?]\)\ |$\1\\kern-0.05em\\textsf{\2}$ |g;
+ s|💲|\\$|g' |
+ tee "${intermediate}" |
+ multimarkdown -o "${outputfile}.temp"
fi
# Both pandoc and multimarkdown just output the HTML body.
@@ -74,7 +99,6 @@ cat <(
echo ""
echo " ${title}"
echo " "
- echo " ${ViewAndStyle}"
if grep -q -E 'class="mermaid"' "${outputfile}.temp"; then
echo " ${Mermaid}"
fi
@@ -83,6 +107,8 @@ cat <(
echo " ${Math2}"
echo " ${Math3}"
fi
+ # ViewAndStyle last, so our `style.css` loads after the KaTeX CSS (as in rst).
+ echo " ${ViewAndStyle}"
echo ""
echo ""
cat "${outputfile}.temp"
diff --git a/static/css/style.css b/static/css/style.css
index 5ed7f237d..c02f3d293 100644
--- a/static/css/style.css
+++ b/static/css/style.css
@@ -310,14 +310,14 @@ div.warning + p {
@font-face {
font-family: raleway;
src: url('../assets/fonts/Raleway-VariableFont_wght.ttf') format('truetype');
- font-weight: normal;
+ font-weight: 100 900;
font-style: normal;
}
@font-face {
font-family: ralewayitalic;
src: url('../assets/fonts/Raleway-Italic-VariableFont_wght.ttf') format('truetype');
- font-weight: normal;
+ font-weight: 100 900;
font-style: italic;
}
@@ -478,13 +478,28 @@ pre {
font-size: 1.2em;
}
-/* Render \textit{...} inside KaTeX in the body font, so slanted identifiers
- in math (e.g. pool names such as IronwoodPool) match the slanted look of
- Markdown emphasis *foo* in surrounding text. */
+/*
+Render `\textit{...}` inside KaTeX in Raleway Italic. This is used for pool names
+such as IronwoodPool, matching *Ironwood pool* in surrounding text.
+*/
.katex .textit {
- font-family: 'ralewayitalic', Arial, 'Helvetica Neue', Helvetica, sans-serif;
- font-style: italic;
- font-size: 0.92em;
+ font-family: 'ralewayitalic', Arial, 'Helvetica Neue', Helvetica, sans-serif !important;
+ font-style: italic !important;
+ font-weight: 500 !important;
+ font-size: 0.92em !important;
+}
+
+/*
+Render `\textsf{...}` inside KaTeX in the body font. This is used to render trailing
+punctuation, e.g. `$x$.` gets transformed by `render.sh` to `$x\kern-0.05em\textsf{.}$`
+(or the equivalent using :math:`...`), to avoid a line break between the math and the
+punctuation. It's also useful to make text-in-math match the surrounding font, e.g.
+in `\cases` where we can't just skip out of math mode.
+*/
+.katex .textsf {
+ font-family: 'robotoregular', Arial, 'Helvetica Neue', Helvetica, sans-serif !important;
+ font-style: normal !important;
+ font-size: 0.83em !important;
}
div.math {
@@ -594,7 +609,7 @@ a.footnote-ref sup, a.footnote sup {
em {
font-family: 'ralewayitalic',Arial,Helvetica Neue,Helvetica,sans-serif;
- font-weight: 720;
+ font-weight: 500;
font-stretch: 85%;
}
diff --git a/test/render-test.sh b/test/render-test.sh
new file mode 100755
index 000000000..650b1c547
--- /dev/null
+++ b/test/render-test.sh
@@ -0,0 +1,59 @@
+#!/bin/bash
+# Regression test for render.sh's math-punctuation rewriting and stylesheet ordering.
+#
+# For each fixture under test/render/, render it via the Makefile (capturing render.sh's
+# post-sed, pre-renderer stream through RENDER_INTERMEDIATE) and compare that intermediate
+# against the checked-in golden. Also check, in the rendered HTML, that our style.css loads
+# after the KaTeX CSS (so our `.katex .*` font overrides win the cascade).
+#
+# Update goldens after an intended render.sh change with:
+# RENDER_INTERMEDIATE=test/render/.intermediate make rendered/test/.html
+set -euo pipefail
+
+cd "$(dirname "$0")/.." # repo root
+
+# `.Makefile.uptodate` runs `make clean` (which removes temp/), so create temp/ after it.
+make .Makefile.uptodate >/dev/null
+mkdir -p temp
+# Clean up our own intermediates on exit, so we don't leave files that would trip
+# update_check.sh's `rmdir temp` (it shares temp/ but expects to empty it).
+trap 'rm -f temp/test-render-*.intermediate' EXIT
+
+status=0
+
+check() {
+ stem="$1"
+ html="rendered/test/${stem}.html"
+ golden="test/render/${stem}.intermediate"
+ got="temp/${stem}.intermediate"
+
+ rm -f "$html"
+ RENDER_INTERMEDIATE="$got" make "$html" >/dev/null
+
+ if diff -u "$golden" "$got"; then
+ echo "PASS intermediate ${stem}"
+ else
+ echo "FAIL intermediate ${stem} (diff above: golden vs actual)"
+ status=1
+ fi
+
+ # Our style.css must load after the KaTeX CSS, else our `.katex .*` overrides lose.
+ katex_line="$(grep -n 'katex\.min\.css' "$html" | head -1 | cut -d: -f1 || true)"
+ style_line="$(grep -n 'href="css/style\.css"' "$html" | head -1 | cut -d: -f1 || true)"
+ if [ -n "$katex_line" ] && [ -n "$style_line" ] && [ "$style_line" -gt "$katex_line" ]; then
+ echo "PASS css-order ${stem} (style.css@${style_line} after katex@${katex_line})"
+ else
+ echo "FAIL css-order ${stem} (katex=${katex_line:-none} style=${style_line:-none})"
+ status=1
+ fi
+}
+
+check test-render-rst
+check test-render-md
+
+if [ "$status" -eq 0 ]; then
+ echo "render tests: PASS"
+else
+ echo "render tests: FAIL"
+fi
+exit "$status"
diff --git a/test/render/test-render-md.intermediate b/test/render/test-render-md.intermediate
new file mode 100644
index 000000000..2f51f1872
--- /dev/null
+++ b/test/render/test-render-md.intermediate
@@ -0,0 +1,26 @@
+ Title: Render test (Markdown)
+
+Trailing period: $x\kern-0.05em\textsf{.}$
+
+Comma then space: $a\kern-0.05em\textsf{,}$ then.
+
+Hyphen after span: $n\kern-0.15em$ -bit.
+
+Threshold: $t\kern-0.15em$ -of-$n\kern-0.05em\textsf{.}$
+
+Close paren: (see $i\kern-0.15em$ ).
+
+Em-dash directly after: $x\kern-0.15em$ —note.
+
+Leading minus preserved: $-x$ stays.
+
+Leading minus then period: $-y\kern-0.05em\textsf{.}$
+
+Punctuation mid-token unchanged: $x$.5 here.
+
+Plain span: $z$ here.
+
+Escaped dollars: \$5 and \$10.
+
+Multi-line span left alone: $a +
+b$.
diff --git a/test/render/test-render-md.md b/test/render/test-render-md.md
new file mode 100644
index 000000000..2e4d88cf1
--- /dev/null
+++ b/test/render/test-render-md.md
@@ -0,0 +1,26 @@
+ Title: Render test (Markdown)
+
+Trailing period: $x$.
+
+Comma then space: $a$, then.
+
+Hyphen after span: $n$-bit.
+
+Threshold: $t$-of-$n$.
+
+Close paren: (see $i$).
+
+Em-dash directly after: $x$—note.
+
+Leading minus preserved: $-x$ stays.
+
+Leading minus then period: $-y$.
+
+Punctuation mid-token unchanged: $x$.5 here.
+
+Plain span: $z$ here.
+
+Escaped dollars: \$5 and \$10.
+
+Multi-line span left alone: $a +
+b$.
diff --git a/test/render/test-render-rst.intermediate b/test/render/test-render-rst.intermediate
new file mode 100644
index 000000000..2140d0779
--- /dev/null
+++ b/test/render/test-render-rst.intermediate
@@ -0,0 +1,26 @@
+.. Title: Render test (rst)
+
+Trailing period: :math:`x\kern-0.03em\textsf{.}`
+
+Comma then space: :math:`a\kern-0.03em\textsf{,}` then.
+
+Hyphen after span: :math:`n\kern-0.15em` -bit.
+
+Threshold: :math:`t\kern-0.15em` -of-:math:`n\kern-0.03em\textsf{.}`
+
+Close paren: (see :math:`i\kern-0.15em` ).
+
+Em-dash directly after: :math:`x\kern-0.15em` —note.
+
+Leading minus preserved: :math:`-x` stays.
+
+Leading minus then period: :math:`-y\kern-0.03em\textsf{.}`
+
+Punctuation mid-token unchanged: :math:`x`.5 here.
+
+Plain span: :math:`z` here.
+
+Escaped dollars: $5 and $10.
+
+Multi-line span left alone: $a +
+b$.
diff --git a/test/render/test-render-rst.rst b/test/render/test-render-rst.rst
new file mode 100644
index 000000000..081027bf9
--- /dev/null
+++ b/test/render/test-render-rst.rst
@@ -0,0 +1,26 @@
+.. Title: Render test (rst)
+
+Trailing period: $x$.
+
+Comma then space: $a$, then.
+
+Hyphen after span: $n$-bit.
+
+Threshold: $t$-of-$n$.
+
+Close paren: (see $i$).
+
+Em-dash directly after: $x$—note.
+
+Leading minus preserved: $-x$ stays.
+
+Leading minus then period: $-y$.
+
+Punctuation mid-token unchanged: $x$.5 here.
+
+Plain span: $z$ here.
+
+Escaped dollars: \$5 and \$10.
+
+Multi-line span left alone: $a +
+b$.
diff --git a/zips/zip-0032.rst b/zips/zip-0032.rst
index 7360d1f1b..d43ac6c5e 100644
--- a/zips/zip-0032.rst
+++ b/zips/zip-0032.rst
@@ -15,7 +15,6 @@
Created: 2018-05-22
License: MIT
-$% This ZIP makes heavy use of mathematical markup. If you can see this, you may want to instead view the rendered version at https://zips.z.cash/zip-0032 .$
Terminology
===========
@@ -104,13 +103,13 @@ Most of the notation and functions used in this ZIP are defined in the Zcash pro
- $\mathsf{repr}_\mathbb{J}(P)$ is the representation of the Jubjub elliptic curve point $P$
as a bit sequence, defined in [#protocol-jubjub]_.
-- $\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)$ refers to unkeyed BLAKE2b-256 in sequential mode,
+- $\mathsf{BLAKE2b}\textsf{-}\mathsf{256}(p, x)$ refers to unkeyed BLAKE2b-256 in sequential mode,
with an output digest length of 32 bytes, 16-byte personalization string $p$, and input $x$.
-- $\mathsf{BLAKE2b}\text{-}\mathsf{512}(p, x)$ refers to unkeyed BLAKE2b-512 in sequential mode,
+- $\mathsf{BLAKE2b}\textsf{-}\mathsf{512}(p, x)$ refers to unkeyed BLAKE2b-512 in sequential mode,
with an output digest length of 64 bytes, 16-byte personalization string $p$, and input $x$.
-- $\mathsf{PRF^{expand}}(\mathsf{sk}, t) :=$ $\mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“Zcash\_ExpandSeed”},$ $\mathsf{sk}\,||\,t)$.
+- $\mathsf{PRF^{expand}}(\mathsf{sk}, t) :=$ $\mathsf{BLAKE2b}\textsf{-}\mathsf{512}(\texttt{“Zcash\_ExpandSeed”},$ $\mathsf{sk}\,||\,t)$.
- $r_\mathbb{J}$ is the order of the Jubjub large prime subgroup.
@@ -125,8 +124,8 @@ Most of the notation and functions used in this ZIP are defined in the Zcash pro
The following algorithm standardized in [#NIST-SP-800-38G]_ is used:
-- $\mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(key, tweak, x)$ refers to the FF1 encryption algorithm
- using AES with a 256-bit $key$, and parameters $radix = 2,$ $minlen = 88,$ $maxlen = 88$.
+- $\mathsf{FF1}\textsf{-}\mathsf{AES256.Encrypt}(key, tweak, x)$ refers to the FF1 encryption algorithm
+ using AES with a 256-bit $key$, and parameters $radix = 2$, $minlen = 88$, $maxlen = 88$.
It will be used only with the empty string $\texttt{“”}$ as the $tweak$. $x$ is a
sequence of 88 bits, as is the output.
@@ -139,7 +138,7 @@ We also define the following conversion function:
Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling and Orchard
specifications), which is the opposite of BIP 32.
-We adapt the path notation of BIP 32 [#bip-0032]_ to describe shielded HD paths, using prime marks ($\kern-0.1em{}'$) to
+We adapt the path notation of BIP 32 [#bip-0032]_ to describe shielded HD paths, using prime marks $\textsf{(}\kern0.1em{}'\textsf{)}$ to
indicate hardened derivation ($\!i' = i + 2^{31}$) as in BIP 44 [#bip-0044]_:
- $\mathsf{CKDfvk}(\mathsf{CKDfvk}(\mathsf{CKDfvk}(m_\mathsf{Sapling}, a), b), c)$ is written as $m_\mathsf{Sapling} / a / b / c$.
@@ -234,7 +233,7 @@ Sapling master key generation
Let $S$ be a seed byte sequence meeting the requirements in `Specification: Wallet seeds`_.
-- Calculate $I = \mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“ZcashIP32Sapling”}, S)$.
+- Calculate $I = \mathsf{BLAKE2b}\textsf{-}\mathsf{512}(\texttt{“ZcashIP32Sapling”}, S)$.
- Split $I$ into two 32-byte sequences, $I_L$ and $I_R$.
- Use $I_L$ as the master spending key $\mathsf{sk}_m$, and $I_R$ as the master chain code
$\mathsf{c}_m$.
@@ -396,7 +395,7 @@ reach the maximum possible diversifier range without running into repetitions du
use FF1-AES256 as a Pseudo-Random Permutation as follows:
- Let $j$ be the index of the desired diversifier, in the range $0\,..\, 2^{88} - 1$.
-- $d_j = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))$.
+- $d_j = \mathsf{FF1}\textsf{-}\mathsf{AES256.Encrypt}(\mathsf{dk}, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))$.
A valid diversifier $d_j$ is one for which $\mathsf{DiversifyHash^{Sapling}}(d_j) \neq \bot$.
For a given $\mathsf{dk}$, approximately half of the possible values of $j$ yield valid
@@ -441,7 +440,7 @@ to be encoded.
$\mathsf{MKGh}^\mathsf{Context}(\mathsf{IKM}) \rightarrow (\mathsf{sk}_m, \mathsf{c}_m)$ :
-- Calculate $I = \mathsf{BLAKE2b}\text{-}\mathsf{512}(\mathsf{Context.MKGDomain}, \mathsf{IKM})$.
+- Calculate $I = \mathsf{BLAKE2b}\textsf{-}\mathsf{512}(\mathsf{Context.MKGDomain}, \mathsf{IKM})$.
- Split $I$ into two 32-byte sequences, $I_L$ and $I_R$.
- Use $I_L$ as the master secret key $\mathsf{sk}_m$.
- Use $I_R$ as the master chain code $\mathsf{c}_m$.
@@ -479,7 +478,7 @@ process with the following constants:
Orchard extended keys
---------------------
-We represent an Orchard extended spending key as $(\mathsf{sk, c}),$ where $\mathsf{sk}$
+We represent an Orchard extended spending key as $(\mathsf{sk, c})$, where $\mathsf{sk}$
is the normal Orchard spending key (opaque 32 bytes), and $\mathsf{c}$ is the chain code.
Orchard master key generation
@@ -562,13 +561,13 @@ either external or internal):
- $(\mathsf{dk}, \mathsf{ovk}) = \mathsf{DeriveDkAndOvk^{Orchard}}(\mathsf{rivk}, \mathsf{ak}, \mathsf{nk})$.
- Let $j$ be the index of the desired diversifier, in the range $0\,..\, 2^{88} - 1$.
-- $\mathsf{d}_j = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}\big(\mathsf{dk}, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j)\kern-0.1em\big)$.
+- $\mathsf{d}_j = \mathsf{FF1}\textsf{-}\mathsf{AES256.Encrypt}\big(\mathsf{dk}, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j)\kern-0.1em\big)$.
Note that unlike Sapling, all Orchard diversifiers are valid, and thus all possible values
of $j$ yield valid diversifiers.
The default diversifier for $(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})$ is defined to be
-$\mathsf{d}_0.$
+$\mathsf{d}_0$.
No mechanism is provided to derive distinct Outgoing Viewing Keys ($\!\mathsf{ovk}$) for
each diversified address. This is because payments are sent from accounts (with external
@@ -787,7 +786,7 @@ Sapling Full Viewing Key Fingerprints and Tags
A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding $\mathit{FVK}$ (as specified
in [#protocol-saplingfullviewingkeyencoding]_) is given by:
-* $\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})$.
+* $\mathsf{BLAKE2b}\textsf{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})$.
It MAY be used to uniquely identify a particular Sapling full viewing key.
@@ -801,7 +800,7 @@ Orchard Full Viewing Key Fingerprints and Tags
An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding $\mathit{FVK}$ (as
specified in [#protocol-orchardfullviewingkeyencoding]_) is given by:
-* $\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})$.
+* $\mathsf{BLAKE2b}\textsf{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})$.
It MAY be used to uniquely identify a particular Orchard full viewing key.
@@ -814,7 +813,7 @@ Seed Fingerprints
A "seed fingerprint" for the master seed $S$ of a hierarchical deterministic wallet is given by:
-* $\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash\_HD\_Seed\_FP”},$ $[\mathsf{length}(S)]\,||\,S)$.
+* $\mathsf{BLAKE2b}\textsf{-}\mathsf{256}(\texttt{“Zcash\_HD\_Seed\_FP”},$ $[\mathsf{length}(S)]\,||\,S)$.
It MAY be used to uniquely identify a particular hierarchical deterministic wallet.
@@ -890,9 +889,9 @@ Values reserved due to previous specification for Sprout
The following values were previously used in the specification of hierarchical derivation
for Sprout, and therefore SHOULD NOT be used in future Zcash-related specifications:
-* the $\mathsf{BLAKE2b}\text{-}\mathsf{512}$ personalization $\texttt{“ZcashIP32\_Sprout”}$,
+* the $\mathsf{BLAKE2b}\textsf{-}\mathsf{512}$ personalization $\texttt{“ZcashIP32\_Sprout”}$,
formerly specified for derivation of the master key of the Sprout tree;
-* the $\mathsf{BLAKE2b}\text{-}\mathsf{256}$ personalization $\texttt{“Zcash\_Sprout\_AFP”}$,
+* the $\mathsf{BLAKE2b}\textsf{-}\mathsf{256}$ personalization $\texttt{“Zcash\_Sprout\_AFP”}$,
formerly specified for generation of Sprout address fingerprints;
* the $\mathsf{PRF^{expand}}$ prefix $\mathtt{0x80}$, formerly specified for
Sprout child key derivation;
diff --git a/zips/zip-0204.rst b/zips/zip-0204.rst
index d3b9476f4..5f1a13744 100644
--- a/zips/zip-0204.rst
+++ b/zips/zip-0204.rst
@@ -341,7 +341,7 @@ Service Flags
Service flags are advertised in the ``services`` field of ``version`` messages and
``CAddress`` structures. In the table below, bit $k$ refers to the bit with
-numeric weight $2^k;$ that is, the ``services`` field has the corresponding flag
+numeric weight $2^k$; that is, the ``services`` field has the corresponding flag
set if and only if ``services & (1 << k) != 0``.
+------------------+-----+------------------------------------------------------+
diff --git a/zips/zip-0208.rst b/zips/zip-0208.rst
index c81865370..4392cfa6c 100644
--- a/zips/zip-0208.rst
+++ b/zips/zip-0208.rst
@@ -101,8 +101,8 @@ $\mathsf{height}$ parameter, as follows:
.. math::
\mathsf{PoWTargetSpacing}(\mathsf{height}) :=
\begin{cases}
- \mathsf{PreBlossomPoWTargetSpacing}, &\!\!\text{if not } \mathsf{IsBlossomActivated}(\mathsf{height}) \\
- \mathsf{PostBlossomPoWTargetSpacing} &\!\!\text{otherwise}
+ \mathsf{PreBlossomPoWTargetSpacing}, &\!\!\textsf{if not } \mathsf{IsBlossomActivated}(\mathsf{height}) \\
+ \mathsf{PostBlossomPoWTargetSpacing} &\!\!\textsf{otherwise}
\end{cases}
Also redefine $\mathsf{AveragingWindowTimespan}$, $\mathsf{MinActualTimespan}$, $\mathsf{MaxActualTimespan}$,
@@ -119,19 +119,19 @@ to section 7.8], redefine the $\mathsf{Halving}$ and $\mathsf{BlockSubsidy}$ fun
.. math::
\mathsf{Halving}(\mathsf{height}) :=
\begin{cases}
- \mathsf{floor}((\mathsf{height} - \mathsf{SlowStartShift}) / \mathsf{PreBlossomHalvingInterval}), &\!\!\text{if not } \mathsf{IsBlossomActivated}(\mathsf{height}) \\
+ \mathsf{floor}((\mathsf{height} - \mathsf{SlowStartShift}) / \mathsf{PreBlossomHalvingInterval}), &\!\!\textsf{if not } \mathsf{IsBlossomActivated}(\mathsf{height}) \\
\mathsf{floor}((\mathsf{BlossomActivationHeight} - \mathsf{SlowStartShift}) / \mathsf{PreBlossomHalvingInterval} & \\
- \hspace{1em}+\; (\mathsf{height} - \mathsf{BlossomActivationHeight}) / \mathsf{PostBlossomHalvingInterval}) &\!\!\text{otherwise}
+ \hspace{1em}+\; (\mathsf{height} - \mathsf{BlossomActivationHeight}) / \mathsf{PostBlossomHalvingInterval}) &\!\!\textsf{otherwise}
\end{cases}
.. math::
\mathsf{BlockSubsidy}(\mathsf{height}) :=
\begin{cases}
- \mathsf{SlowStartRate} \cdot \mathsf{height}, &\!\!\text{if } \mathsf{height} < \mathsf{SlowStartInterval} / 2 \\
- \mathsf{SlowStartRate} \cdot (\mathsf{height} + 1), &\!\!\text{if } \mathsf{SlowStartInterval} / 2 \leq \mathsf{height} \text{ and } \mathsf{height} < \mathsf{SlowStartInterval} \\
- \mathsf{floor}(\mathsf{MaxBlockSubsidy} / 2^{\mathsf{Halving}(\mathsf{height})}), &\!\!\text{if } \mathsf{SlowStartInterval} \leq \mathsf{height} \text{ and not } \mathsf{IsBlossomActivated}(\mathsf{height}) \\
+ \mathsf{SlowStartRate} \cdot \mathsf{height}, &\!\!\textsf{if } \mathsf{height} < \mathsf{SlowStartInterval} / 2 \\
+ \mathsf{SlowStartRate} \cdot (\mathsf{height} + 1), &\!\!\textsf{if } \mathsf{SlowStartInterval} / 2 \leq \mathsf{height} \textsf{ and } \mathsf{height} < \mathsf{SlowStartInterval} \\
+ \mathsf{floor}(\mathsf{MaxBlockSubsidy} / 2^{\mathsf{Halving}(\mathsf{height})}), &\!\!\textsf{if } \mathsf{SlowStartInterval} \leq \mathsf{height} \textsf{ and not } \mathsf{IsBlossomActivated}(\mathsf{height}) \\
\mathsf{floor}(\mathsf{MaxBlockSubsidy} / & \\
- \hspace{1em}(\mathsf{BlossomPoWTargetSpacingRatio} \cdot 2^{\mathsf{Halving}(\mathsf{height})})) &\!\!\text{otherwise}
+ \hspace{1em}(\mathsf{BlossomPoWTargetSpacingRatio} \cdot 2^{\mathsf{Halving}(\mathsf{height})})) &\!\!\textsf{otherwise}
\end{cases}
Note: $\mathsf{BlossomActivationHeight}$, $\mathsf{PostBlossomHalvingInterval}$, and $\mathsf{PostBlossomTargetSpacing}$ are chosen so that:
@@ -147,9 +147,9 @@ In section 7.8 (Payment of Founders’ Reward) [later moved to section 7.9], def
.. math::
\mathsf{FounderAddressAdjustedHeight}(\mathsf{height}) :=
\begin{cases}
- \mathsf{height}, &\!\!\text{if not } \mathsf{IsBlossomActivated}(\mathsf{height}) \\
+ \mathsf{height}, &\!\!\textsf{if not } \mathsf{IsBlossomActivated}(\mathsf{height}) \\
\mathsf{BlossomActivationHeight} + \mathsf{floor}((\mathsf{height} - \mathsf{BlossomActivationHeight}) / \\
- \hspace{1em}\mathsf{BlossomPoWTargetSpacingRatio}) &\!\!\text{otherwise}
+ \hspace{1em}\mathsf{BlossomPoWTargetSpacingRatio}) &\!\!\textsf{otherwise}
\end{cases}
and in the definition of $\mathsf{FounderAddressIndex}$, replace the use of $\mathsf{height}$ with $\mathsf{FounderAddressAdjustedHeight}(\mathsf{height})$.
diff --git a/zips/zip-0218.md b/zips/zip-0218.md
index 7bb50f1de..e2a8e17bc 100644
--- a/zips/zip-0218.md
+++ b/zips/zip-0218.md
@@ -243,7 +243,7 @@ integer constants.
In § 5.3 'Constants', define:
-$$\mathsf{PostNU7PoWTargetSpacing} := 25 \text{ seconds}$$
+$$\mathsf{PostNU7PoWTargetSpacing} := 25 \textsf{ seconds}$$
For a given network (production or test), define
$\mathsf{NU7ActivationHeight}$ as the height at which
@@ -265,9 +265,9 @@ as:
$$
\mathsf{PoWTargetSpacing}(\mathsf{height}) :=
\begin{cases}
- \mathsf{PreBlossomPoWTargetSpacing}, &\text{if not } \mathsf{IsBlossomActivated}(\mathsf{height}) \\\\
- \mathsf{PostBlossomPoWTargetSpacing}, &\text{if } \mathsf{IsBlossomActivated}(\mathsf{height}) \text{ and not } \mathsf{IsNU7Activated}(\mathsf{height}) \\\\
- \mathsf{PostNU7PoWTargetSpacing} &\text{otherwise}
+ \mathsf{PreBlossomPoWTargetSpacing}, &\textsf{if not } \mathsf{IsBlossomActivated}(\mathsf{height}) \\\\
+ \mathsf{PostBlossomPoWTargetSpacing}, &\textsf{if } \mathsf{IsBlossomActivated}(\mathsf{height}) \textsf{ and not } \mathsf{IsNU7Activated}(\mathsf{height}) \\\\
+ \mathsf{PostNU7PoWTargetSpacing} &\textsf{otherwise}
\end{cases}
$$
@@ -286,8 +286,8 @@ $\mathsf{PoWAveragingWindow}$ as a height-dependent function:
$$
\mathsf{PoWAveragingWindow}(\mathsf{height}) :=
\begin{cases}
- 17, &\text{if not } \mathsf{IsNU7Activated}(\mathsf{height}) \\\\
- \mathsf{PostNU7PoWAveragingWindow} &\text{otherwise}
+ 17, &\textsf{if not } \mathsf{IsNU7Activated}(\mathsf{height}) \\\\
+ \mathsf{PostNU7PoWAveragingWindow} &\textsf{otherwise}
\end{cases}
$$
@@ -311,14 +311,14 @@ $$
\mathsf{Halving}(\mathsf{height}) :=
\begin{cases}
\left\lfloor \dfrac{\mathsf{height} - \mathsf{SlowStartShift}}{\mathsf{PreBlossomHalvingInterval}} \right\rfloor,
- &\text{if not } \mathsf{IsBlossomActivated}(\mathsf{height}) \\\\[1.5ex]
+ &\textsf{if not } \mathsf{IsBlossomActivated}(\mathsf{height}) \\\\[1.5ex]
\left\lfloor \dfrac{\mathsf{BlossomActivationHeight} - \mathsf{SlowStartShift}}{\mathsf{PreBlossomHalvingInterval}}
+ \dfrac{\mathsf{height} - \mathsf{BlossomActivationHeight}}{\mathsf{PostBlossomHalvingInterval}} \right\rfloor,
- &\text{if } \mathsf{IsBlossomActivated}(\mathsf{height}) \text{ and not } \mathsf{IsNU7Activated}(\mathsf{height}) \\\\[1.5ex]
+ &\textsf{if } \mathsf{IsBlossomActivated}(\mathsf{height}) \textsf{ and not } \mathsf{IsNU7Activated}(\mathsf{height}) \\\\[1.5ex]
\left\lfloor \dfrac{\mathsf{BlossomActivationHeight} - \mathsf{SlowStartShift}}{\mathsf{PreBlossomHalvingInterval}}
+ \dfrac{\mathsf{NU7ActivationHeight} - \mathsf{BlossomActivationHeight}}{\mathsf{PostBlossomHalvingInterval}}
+ \dfrac{\mathsf{height} - \mathsf{NU7ActivationHeight}}{\mathsf{PostNU7HalvingInterval}} \right\rfloor,
- &\text{otherwise}
+ &\textsf{otherwise}
\end{cases}
$$
@@ -333,7 +333,7 @@ $$
\begin{cases}
\ldots &\text{(prior cases, with the Blossom case amended as above)} \\\\[1ex]
\mathsf{floor}\left(\dfrac{\mathsf{MaxBlockSubsidy}}{\mathsf{BlossomPoWTargetSpacingRatio} \cdot \mathsf{NU7PoWTargetSpacingRatio} \cdot 2^{\mathsf{Halving}(\mathsf{height})}}\right),
- &\text{if } \mathsf{IsNU7Activated}(\mathsf{height})
+ &\textsf{if } \mathsf{IsNU7Activated}(\mathsf{height})
\end{cases}
$$
@@ -593,7 +593,7 @@ is despite a 3× increase in block frequency and overall throughput
capacity.
The binding constraint is Orchard at 330 actions per block:
-$330 \times 148 \times 3{,}456 + 90 \times 3{,}456 = 169.10\text{ MB/day}$.
+$330 \times 148 \times 3{,}456 + 90 \times 3{,}456 = 169.10\textsf{ MB/day}$.
The trial decryption count also decreases significantly, since the
per-block action limits more than offset the 3× increase in block count.
@@ -611,7 +611,7 @@ Orchard wallets always attempt both.
For standard 2-action Orchard transactions, the action limit of 330
allows $\lfloor 330 / 2 \rfloor = 165$ transactions per block, giving:
-$$\mathsf{orchard\_tps} = 165 \;/\; 25 = 6.6 \text{ TPS}$$
+$$\mathsf{orchard\_tps} = 165 \;/\; 25 = 6.6 \textsf{ TPS}$$
For comparison, the current protocol (75s blocks, block-size limited)
supports approximately 2.9 TPS for 2-action Orchard transactions. This
diff --git a/zips/zip-0224.rst b/zips/zip-0224.rst
index cbede7687..1abab6f61 100644
--- a/zips/zip-0224.rst
+++ b/zips/zip-0224.rst
@@ -180,7 +180,7 @@ derivation mechanism (similar to Sprout).
Notes
-----
-Orchard notes have the structure $(addr, v, \text{ρ}, \text{φ}, \mathsf{rcm}).$ $\text{ρ}$
+Orchard notes have the structure $(addr, v, \text{ρ}, \text{φ}, \mathsf{rcm})$. $\text{ρ}$
is set to the nullifier of the spent note in the same action, which ensures it is unique.
$\text{φ}$ and $\mathsf{rcm}$ are derived from a random seed (as with Sapling
after ZIP 212 [#zip-0212]_).
diff --git a/zips/zip-0226.rst b/zips/zip-0226.rst
index 4c35334a8..896334be1 100644
--- a/zips/zip-0226.rst
+++ b/zips/zip-0226.rst
@@ -141,8 +141,8 @@ This uses the note commitment scheme defined in §5.4.8.4 ‘Sinsemilla Commitme
.. math::
\mathsf{NoteCommit^{OrchardZSA}_{rcm}}(\mathsf{g_d}\star, \mathsf{pk_d}\star, \mathsf{v}, \text{ρ}, \text{ψ}, \mathsf{AssetBase}) :=
\begin{cases}
- \mathsf{NoteCommit^{Orchard}_{rcm}}(\mathsf{g_d}\star, \mathsf{pk_d}\star, \mathsf{v}, \text{ρ}, \text{ψ}), &\!\!\text{if } \mathsf{AssetBase} = \mathcal{V}^{\mathsf{Orchard}} \\
- \mathsf{cm_{ZSA}} &\!\!\text{otherwise}
+ \mathsf{NoteCommit^{Orchard}_{rcm}}(\mathsf{g_d}\star, \mathsf{pk_d}\star, \mathsf{v}, \text{ρ}, \text{ψ}), &\!\!\textsf{if } \mathsf{AssetBase} = \mathcal{V}^{\mathsf{Orchard}} \\
+ \mathsf{cm_{ZSA}} &\!\!\textsf{otherwise}
\end{cases}
where:
diff --git a/zips/zip-0227.rst b/zips/zip-0227.rst
index 51841ad6d..746ba2090 100644
--- a/zips/zip-0227.rst
+++ b/zips/zip-0227.rst
@@ -157,7 +157,7 @@ $\mathsf{CKDsk}((\mathsf{sk}_{par},\mathsf{c}_{par}), i) \rightarrow (\mathsf{sk
- Return $\mathsf{CKDh}^{\mathsf{Issuance}}((\mathsf{sk}_{par},\mathsf{c}_{par}), i)$
-We use the notation of ZIP 32 [#zip-0032-orchard-key-path]_ for shielded HD paths, and define the issuance authorizing key path as $m_{\mathsf{Issuance}} / \mathit{purpose}' / \mathit{coin\_type}' / \mathit{account}'.$ We fix the path levels as follows:
+We use the notation of ZIP 32 [#zip-0032-orchard-key-path]_ for shielded HD paths, and define the issuance authorizing key path as $m_{\mathsf{Issuance}} / \mathit{purpose}' / \mathit{coin\_type}' / \mathit{account}'$. We fix the path levels as follows:
- $\mathit{purpose}$: a constant set to $227$ (i.e. $\mathtt{0xe3}$). $\mathit{purpose}'$ is thus $227'$ (or $\mathtt{0x800000e3}$) following the BIP 43 recommendation. [#bip-0043]_
- $\mathit{coin\_type}$: Defined as in ZIP 32 [#zip-0032-key-path-levels]_.
diff --git a/zips/zip-0271.md b/zips/zip-0271.md
index d8ed8edf6..e68ceb897 100644
--- a/zips/zip-0271.md
+++ b/zips/zip-0271.md
@@ -207,8 +207,8 @@ Add the following definitions:
and
> $\mathsf{totalDeferredInput}(\mathsf{height}) := \begin{cases}
-> \mathsf{ZIP271DisbursementAmount},&\!\!\text{if } \mathsf{height} = \mathsf{ZIP217ActivationHeight} \\
-> 0,&\!\!\text{otherwise}.
+> \mathsf{ZIP271DisbursementAmount},&\!\!\textsf{if } \mathsf{height} = \mathsf{ZIP217ActivationHeight} \\
+> 0,&\!\!\textsf{otherwise.}
> \end{cases}$
#### § 7.10 ‘Payment of Funding Streams’ [^protocol-fundingstreams]
diff --git a/zips/zip-0307.rst b/zips/zip-0307.rst
index 9575f620f..2a54802f8 100644
--- a/zips/zip-0307.rst
+++ b/zips/zip-0307.rst
@@ -274,7 +274,7 @@ viewing key $\mathsf{ivk}$ is a slight deviation from the standard decryption pr
- [Pre-Canopy] let $\mathsf{\underline{rcm}} = \mathsf{rseed}$
- [Canopy onward] if $\mathsf{height} < \mathsf{CanopyActivationHeight} + \mathsf{ZIP212GracePeriod}$ and $\mathsf{leadByte} \not\in \{ \mathtt{0x01}, \mathtt{0x02} \}$, return $\bot$
- [Canopy onward] if $\mathsf{height} < \mathsf{CanopyActivationHeight} + \mathsf{ZIP212GracePeriod}$ and $\mathsf{leadByte} \neq \mathtt{0x02}$, return $\bot$
-- [Canopy onward] let $\mathsf{\underline{rcm}} = \begin{cases}\mathsf{rseed}, &\text{if } \mathsf{leadByte} = \mathtt{0x01} \\ \mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5])), &\text{otherwise}\end{cases}$
+- [Canopy onward] let $\mathsf{\underline{rcm}} = \begin{cases}\mathsf{rseed}, &\textsf{if } \mathsf{leadByte} = \mathtt{0x01} \\ \mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5])), &\textsf{otherwise}\end{cases}$
- let $\mathsf{rcm} = \mathsf{LEOS2IP}_{256}(\mathsf{\underline{rcm}})$ and $\mathsf{g_d} = \mathsf{DiversifyHash}(\mathsf{d})$
- if $\mathsf{rcm} \geq r_{\mathbb{J}}$ or $\mathsf{g_d} = \bot$, return $\bot$
- [Canopy onward] if $\mathsf{leadByte} \neq \mathtt{0x01}$:
diff --git a/zips/zip-0316.rst b/zips/zip-0316.rst
index 7e7058f4c..0cec75c94 100644
--- a/zips/zip-0316.rst
+++ b/zips/zip-0316.rst
@@ -427,12 +427,12 @@ of the constituent Receivers, in ascending order of Typecode:
above Priority List;
* $\mathtt{length} : \mathtt{compactSize}$ — the length in bytes of
- $\mathtt{addr};$
+ $\mathtt{addr}$;
* $\mathtt{addr} : \mathtt{byte[length]}$ — the Receiver Encoding.
The values of the $\mathtt{typecode}$ and $\mathtt{length}$
-fields MUST be less than or equal to $\mathtt{0x2000000}.$
+fields MUST be less than or equal to $\mathtt{0x2000000}$.
(The limitation on the total length of encodings described below imposes
a smaller limit for $\mathtt{length}$ in practice.)
@@ -491,20 +491,20 @@ corresponding Unified Address.
The following FVK or IVK Encodings are used in place of the
$\mathtt{addr}$ field:
-* An Orchard FVK or IVK Encoding, with Typecode $\mathtt{0x03},$ is
+* An Orchard FVK or IVK Encoding, with Typecode $\mathtt{0x03}$, is
the raw encoding of the Orchard Full Viewing Key or Orchard Incoming
Viewing Key respectively.
-* A Sapling FVK Encoding, with Typecode $\mathtt{0x02},$ is the
+* A Sapling FVK Encoding, with Typecode $\mathtt{0x02}$, is the
encoding of $(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})$
given by $\mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})$,
where $\mathsf{EncodeExtFVKParts}$ is defined in [#zip-0032-sapling-helper-functions]_.
This SHOULD be derived from the Extended Full Viewing Key at the Account
level of the ZIP 32 hierarchy.
-* A Sapling IVK Encoding, also with Typecode $\mathtt{0x02},$
+* A Sapling IVK Encoding, also with Typecode $\mathtt{0x02}$,
is an encoding of $(\mathsf{dk}, \mathsf{ivk})$ given by
- $\mathsf{dk}\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).$ Note that
+ $\mathsf{dk}\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk})$. Note that
a zero $\mathsf{ivk}$ is not valid [#protocol-2025.6.0]_.
.. _`P2SH Viewing Key Items`:
@@ -547,14 +547,14 @@ $\mathtt{addr}$ field:
pubkey.
The number of ``@N`` key placeholders in the descriptor template MUST equal
- $\mathtt{n\_keys}.$ Consumers MUST reject P2SH Viewing Key Items for which
+ $\mathtt{n\_keys}$. Consumers MUST reject P2SH Viewing Key Items for which
this does not hold, or for which the descriptor template is not a valid BIP
388 descriptor template, or does not satisfy the above requirements on the
use of ``/**`` or ``/*`` multipath notation.
* For Transparent P2PKH Addresses that are derived according to BIP 32
[#bip-0032]_ and BIP 44 [#bip-0044]_, the FVK and IVK Encodings have
- Typecode $\mathtt{0x00}.$ Both of these are encodings of the
+ Typecode $\mathtt{0x00}$. Both of these are encodings of the
chain code and public key $(\mathsf{c}, \mathsf{pk})$ given by
$\mathsf{c}\,||\,\mathsf{ser_P}(\mathsf{pk})$. (This is the
same as the last 65 bytes of the extended public key format defined
@@ -610,7 +610,7 @@ Requirements for both Unified Addresses and Unified Viewing Keys
violates the restriction applying to its Revision.
* The $\mathtt{typecode}$ and $\mathtt{length}$ fields are encoded as
- $\mathtt{compactSize}.$ [#Bitcoin-CompactSize]_ (Although existing Receiver
+ $\mathtt{compactSize}$. [#Bitcoin-CompactSize]_ (Although existing Receiver
Encodings and Viewing Key Encodings are all less than 256 bytes and so could
use a one-byte length field, encodings for experimental types may be longer.)
@@ -1061,7 +1061,7 @@ we derive the external and internal $\mathsf{ovk}$ components from the P2SH FVK
Item (i.e. the concatenation of $\mathsf{template\_len}$,
$\mathsf{template}$, $\mathsf{n\_keys}$, and the key information
entries, as specified in `P2SH Viewing Key Items`_).
-- Let $I_\mathsf{ovk} = \textsf{BLAKE2b-512}(\texttt{"ZIP316\_P2SH\_OVK\_"},\, \mathsf{fvk\_ser}).$
+- Let $I_\mathsf{ovk} = \textsf{BLAKE2b-512}(\texttt{"ZIP316\_P2SH\_OVK\_"},\, \mathsf{fvk\_ser})$.
- Let $\mathsf{ovk_{external}}$ be the first $32$ bytes of
$I_\mathsf{ovk}$ and let $\mathsf{ovk_{internal}}$ be the
remaining $32$ bytes of $I_\mathsf{ovk}$.
@@ -1177,7 +1177,7 @@ diversifier index:
assumed to correspond to the extended public key for the external
(non-change) element of the path. That is, if the UIVK was constructed
correctly then the BIP 44 path of the Transparent P2PKH Receiver will be
- $m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.$
+ $m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}$.
* As of `Revision 2`_, for a Transparent P2SH IVK, the corresponding P2SH
Receiver is obtained by:
@@ -1290,7 +1290,7 @@ etc.
The generic attack puts an upper bound on the achievable security: if it takes
work $w$ to produce and verify a UA/UVK, and the size of the character
-set is $c,$ then the generic attack costs $\sim \frac{w \cdot c^{n+m}}{q}.$
+set is $c$, then the generic attack costs $\sim \frac{w \cdot c^{n+m}}{q}$.
There is also a generic brute force attack against nonmalleability. The
adversary modifies the target UA/UVK slightly and computes the corresponding
@@ -1305,16 +1305,16 @@ Solution
We use an unkeyed 4-round Feistel construction to approximate a random
permutation. (As explained below, 3 rounds would not be sufficient.)
-Let $H_i$ be a hash personalized by $i,$ with maximum output
+Let $H_i$ be a hash personalized by $i$, with maximum output
length $\ell_H$ bytes. Let $G_i$ be a XOF (a hash function with
-extendable output length) based on $H,$ personalized by $i.$
+extendable output length) based on $H$, personalized by $i$.
-Define $\ell^\mathsf{MAX}_M = (2^{16} + 1) \cdot \ell_H.$
+Define $\ell^\mathsf{MAX}_M = (2^{16} + 1) \cdot \ell_H$.
For the instantiation using BLAKE2b defined below,
-$\ell^\mathsf{MAX}_M = 4194368.$
+$\ell^\mathsf{MAX}_M = 4194368$.
Given input $M$ of length $\ell_M$ bytes such that
-$38 \leq \ell_M \leq \ell^\mathsf{MAX}_M,$ define
+$38 \leq \ell_M \leq \ell^\mathsf{MAX}_M$, define
$\mathsf{F4Jumble}(M)$ by:
* let $\ell_L = \mathsf{min}(\ell_H, \mathsf{floor}(\ell_M/2))$
@@ -1324,22 +1324,22 @@ $\mathsf{F4Jumble}(M)$ by:
* let $y = a \oplus H_0(x)$
* let $d = x \oplus G_1(y)$
* let $c = y \oplus H_1(d)$
-* return $c \,||\, d.$
+* return $c \,||\, d$.
The inverse function $\mathsf{F4Jumble}^{-1}$ is obtained in the usual
-way for a Feistel construction, by observing that $r = p \oplus q$ implies $p = r \oplus q.$
+way for a Feistel construction, by observing that $r = p \oplus q$ implies $p = r \oplus q$.
The first argument to BLAKE2b below is the personalization.
We instantiate $H_i(u)$ by
$\mathsf{BLAKE2b‐}(8\ell_L)(\texttt{“UA\_F4Jumble\_H”} \,||\,$
-$[i, 0, 0], u),$ with $\ell_H = 64.$
+$[i, 0, 0], u),$ with $\ell_H = 64$.
We instantiate $G_i(u)$ as the first $\ell_R$ bytes of the
concatenation of
$[\mathsf{BLAKE2b‐}512(\texttt{“UA\_F4Jumble\_G”} \,||\, [i] \,||\,$
-$\mathsf{I2LEOSP}_{16}(j), u) \text{ for } j \text{ from}$
-$0 \text{ up to } \mathsf{ceiling}(\ell_R/\ell_H)-1].$
+$\mathsf{I2LEOSP}_{16}(j), u) \textsf{ for } j \textsf{ from}$
+$0 \textsf{ up to } \mathsf{ceiling}(\ell_R/\ell_H)-1]$.
.. figure:: ../rendered/assets/images/zip-0316-f4.png
:width: 372px
@@ -1362,7 +1362,7 @@ before encoding the result with Bech32m.
The Consumer rejects any Bech32m-decoded byte sequence that is less than
38 bytes or greater than $\ell^\mathsf{MAX}_M$ bytes; otherwise it
-applies $\mathsf{F4Jumble}^{-1}.$ It rejects any result that does
+applies $\mathsf{F4Jumble}^{-1}$. It rejects any result that does
not end in the expected 16-byte padding, before stripping these 16 bytes
and parsing the result.
@@ -1386,7 +1386,7 @@ This allows for a UA containing only a Transparent P2PKH Receiver:
* 20-byte transparent address hash
$\ell^\mathsf{MAX}_M$ bytes is the largest input/output size
-supported by $\mathsf{F4Jumble}.$
+supported by $\mathsf{F4Jumble}$.
Allowing only a Transparent P2PKH Receiver is consistent with dropping
the requirement to have at least one shielded Item in Revision 2 UA/UVKs
@@ -1419,31 +1419,31 @@ A 3-round unkeyed Feistel, as shown, is not sufficient:
Diagram of 3-round unkeyed Feistel construction
Suppose that an adversary has a target input/output pair
-$(a \,||\, b, c \,||\, d),$ and that the input to $H_0$ is
-$x.$ By fixing $x,$ we can obtain another pair
+$(a \,||\, b, c \,||\, d)$, and that the input to $H_0$ is
+$x$. By fixing $x$, we can obtain another pair
$((a \oplus t) \,||\, b', (c \oplus t) \,||\, d')$ such that
$a \oplus t$ is close to $a$ and $c \oplus t$ is close
-to $c.$
-($\!b'$ and $d'$ will not be close to $b$ and $d,$
+to $c$.
+($\!b'$ and $d'$ will not be close to $b$ and $d$,
but that isn't necessarily required for a valid attack.)
A 4-round Feistel thwarts this and similar attacks. Defining $x$ and
$y$ as the intermediate values in the first diagram above:
-* if $(x', y')$ are fixed to the same values as $(x, y),$ then
- $(a', b', c', d') = (a, b, c, d);$
+* if $(x', y')$ are fixed to the same values as $(x, y)$, then
+ $(a', b', c', d') = (a, b, c, d)$;
-* if $x' = x$ but $y' \neq y,$ then the adversary is able to
+* if $x' = x$ but $y' \neq y$, then the adversary is able to
introduce a controlled $\oplus$-difference
- $a \oplus a' = y \oplus y',$ but the other three pieces
+ $a \oplus a' = y \oplus y'$, but the other three pieces
$(b, c, d)$ are all randomized, which is sufficient;
-* if $y' = y$ but $x' \neq x,$ then the adversary is able to
+* if $y' = y$ but $x' \neq x$, then the adversary is able to
introduce a controlled $\oplus$-difference
- $d \oplus d' = x \oplus x',$ but the other three pieces
+ $d \oplus d' = x \oplus x'$, but the other three pieces
$(a, b, c)$ are all randomized, which is sufficient;
-* if $x' \neq x$ and $y' \neq y,$ all four pieces are
+* if $x' \neq x$ and $y' \neq y$, all four pieces are
randomized.
Note that the size of each piece is at least 19 bytes.
@@ -1468,8 +1468,8 @@ A UA containing a Sapling Address and an Orchard
Address would have $\ell_M = 106$ bytes.
For longer UAs (when other Receiver Types are added) or UVKs, the cost
-increases to 6 BLAKE2b compressions for $128 < \ell_M \leq 192,$ and
-10 BLAKE2b compressions for $192 < \ell_M \leq 256,$ for example. The
+increases to 6 BLAKE2b compressions for $128 < \ell_M \leq 192$, and
+10 BLAKE2b compressions for $192 < \ell_M \leq 256$, for example. The
maximum cost for which the algorithm is defined would be 196608 BLAKE2b
compressions at $\ell_M = \ell^\mathsf{MAX}_M$ bytes.
@@ -1480,9 +1480,9 @@ the jumbled encoding three times from a less memory-constrained device. It
is essential that the streamed value of $d$ is the same on each pass,
which can be verified using a Message Authentication Code (with key held
only by the Consumer) or collision-resistant hash function. After the first
-pass of $d$, the implementation is able to compute $y;$ after
-the second pass it is able to compute $a;$ and the third allows it to
-compute and incrementally parse $b.$ The maximum memory usage during
+pass of $d$, the implementation is able to compute $y$; after
+the second pass it is able to compute $a$; and the third allows it to
+compute and incrementally parse $b$. The maximum memory usage during
this process would be 128 bytes plus two BLAKE2b hash states.
Since this streaming implementation of $\mathsf{F4Jumble}^{-1}$ is
diff --git a/zips/zip-0317.rst b/zips/zip-0317.rst
index 5ca8b081f..aa824e2dd 100644
--- a/zips/zip-0317.rst
+++ b/zips/zip-0317.rst
@@ -122,8 +122,8 @@ calculated in zatoshis per the following formulae:
\begin{array}{lcl}
\mathit{free\_memo\_chunks} &=& \begin{cases}
- 2, &\!\!\text{if } \mathit{nOutputsSapling} + \mathit{nA\kern-0.05em ctionsOrchard} > 0, \\
- 0, &\!\!\text{otherwise}
+ 2, &\!\!\textsf{if } \mathit{nOutputsSapling} + \mathit{nA\kern-0.05em ctionsOrchard} > 0, \\
+ 0, &\!\!\textsf{otherwise}
\end{cases}
\\[4ex]
\mathit{contribution}_{\,\mathsf{Transparent}} &=& \mathsf{max}\big(\mathsf{ceiling}\big(\frac{\mathit{tx\_in\_total\_size}}{\mathit{p2pkh\_standard\_input\_size}}\big),\,
diff --git a/zips/zip-2005.md b/zips/zip-2005.md
index 25688852c..14fe3a604 100644
--- a/zips/zip-2005.md
+++ b/zips/zip-2005.md
@@ -450,7 +450,7 @@ statement that only uses $\mathsf{H^{qk}}$ and a commitment scheme.
For example, for some hiding and collapse-binding commitment
$$\mathsf{c_{link}} = \mathsf{LinkCommit}_r(\mathsf{qk}, \mathsf{sighash})$$
the hardware wallet could prove knowledge of $(\mathsf{qsk}, r)$ such that
-$$\mathsf{c_{link}} = \mathsf{LinkCommit}_r(\mathsf{H^{qk}}(\mathsf{qsk}), \mathsf{sighash})\textsf{\small .}$$
+$$\mathsf{c_{link}} = \mathsf{LinkCommit}_r(\mathsf{H^{qk}}(\mathsf{qsk}), \mathsf{sighash})\textsf{.}$$
This statement, labelled as $\mathsf{SoK^{qsk}}$ in the diagram, can be
implemented in a much smaller circuit, so it might be feasible to do the
proof in quite constrained hardware.
@@ -561,9 +561,9 @@ Replace the paragraph
> Define $\mathsf{allowedLeadBytes^{protocol}}(\mathsf{height}, \mathsf{txVersion}) =$
> $\hspace{2em} \begin{cases}
-> \{ \mathtt{0x01} \},&\!\!\!\text{if } \mathsf{height} < \mathsf{CanopyActivationHeight} \\
-> \{ \mathtt{0x01}, \mathtt{0x02} \},&\!\!\!\text{if } \mathsf{CanopyActivationHeight} \leq \mathsf{height} < \mathsf{CanopyActivationHeight} + \mathsf{ZIP212GracePeriod} \\
-> \{ \mathtt{0x02} \},&\!\!\!\text{otherwise.}
+> \{ \mathtt{0x01} \},&\!\!\!\textsf{if } \mathsf{height} < \mathsf{CanopyActivationHeight} \\
+> \{ \mathtt{0x01}, \mathtt{0x02} \},&\!\!\!\textsf{if } \mathsf{CanopyActivationHeight} \leq \mathsf{height} < \mathsf{CanopyActivationHeight} + \mathsf{ZIP212GracePeriod} \\
+> \{ \mathtt{0x02} \},&\!\!\!\textsf{otherwise.}
> \end{cases}$
with
@@ -573,10 +573,10 @@ with
>
> Define $\mathsf{allowedLeadBytes^{pool}}(\mathsf{height}, \mathsf{txVersion}) =$
> $\hspace{2em} \begin{cases}
-> \{ \mathtt{0x01} \},&\!\!\!\text{if } \mathsf{height} < \mathsf{CanopyActivationHeight} \\
-> \{ \mathtt{0x01}, \mathtt{0x02} \},&\!\!\!\text{if } \mathsf{CanopyActivationHeight} \leq \mathsf{height} < \mathsf{CanopyActivationHeight} + \mathsf{ZIP212GracePeriod} \\
-> \{ \mathtt{0x02} \},&\!\!\!\text{if } \mathsf{CanopyActivationHeight} + \mathsf{ZIP212GracePeriod} \leq \mathsf{height} \text{ and } \mathsf{pool} \neq \textit{IronwoodPool} \\
-> \{ \mathtt{0x03} \},&\!\!\!\text{otherwise.}
+> \{ \mathtt{0x01} \},&\!\!\!\textsf{if } \mathsf{height} < \mathsf{CanopyActivationHeight} \\
+> \{ \mathtt{0x01}, \mathtt{0x02} \},&\!\!\!\textsf{if } \mathsf{CanopyActivationHeight} \leq \mathsf{height} < \mathsf{CanopyActivationHeight} + \mathsf{ZIP212GracePeriod} \\
+> \{ \mathtt{0x02} \},&\!\!\!\textsf{if } \mathsf{CanopyActivationHeight} + \mathsf{ZIP212GracePeriod} \leq \mathsf{height} \textsf{ and } \mathsf{pool} \neq \textit{IronwoodPool} \\
+> \{ \mathtt{0x03} \},&\!\!\!\textsf{otherwise.}
> \end{cases}$
Replace the non-normative note:
@@ -732,8 +732,8 @@ Add the following notes:
Add after the definition of $\mathsf{leadByte}$:
> Define $\mathsf{Derive\_rcm^{Sapling}_{rseed}}(\mathsf{leadByte}) = \begin{cases}
-> \mathsf{LEOS2IP}_{256}(\mathsf{rseed}),&\!\!\!\text{if } \mathsf{leadByte} = \mathtt{0x01} \\
-> \mathsf{ToScalar^{Sapling}}\big(\mathsf{PRF^{expand}_{rseed}}([\mathtt{0x04}])\kern-0.1em\big),&\!\!\!\text{if } \mathsf{leadByte} = \mathtt{0x02}
+> \mathsf{LEOS2IP}_{256}(\mathsf{rseed}),&\!\!\!\textsf{if } \mathsf{leadByte} = \mathtt{0x01} \\
+> \mathsf{ToScalar^{Sapling}}\big(\mathsf{PRF^{expand}_{rseed}}([\mathtt{0x04}])\kern-0.1em\big),&\!\!\!\textsf{if } \mathsf{leadByte} = \mathtt{0x02}
> \end{cases}$
>
> Define $\mathsf{H^{esk,Sapling}_{rseed}}(\_) = \mathsf{ToScalar^{Sapling}}\big(\mathsf{PRF^{expand}_{rseed}}([\mathtt{0x05}])\kern-0.1em\big)$.
@@ -756,8 +756,8 @@ Add before "For each Action description":
> where $\mathsf{pre\_rcm} = [\mathtt{0x0B}] \,||\, \mathsf{LEBS2OSP}_{256}(\mathsf{g}\star_{\mathsf{d}}) \,||\, \mathsf{LEBS2OSP}_{256}(\mathsf{pk}\star_{\mathsf{d}}) \,||\, \mathsf{I2LEOSP}_{64}(\mathsf{v}) \,||\, \underline{\text{ρ}} \,||\, \mathsf{I2LEOSP}_{256}(\text{ψ})$.
>
> Define $\mathsf{Derive\_rcm^{Orchard}_{rseed}}(\mathsf{leadByte}, \mathsf{g}\star_{\mathsf{d}}, \mathsf{pk}\star_{\mathsf{d}}, \mathsf{v}, \underline{\text{ρ}}, \text{ψ}) = \begin{cases}
-> \mathsf{ToScalar^{Orchard}}\big(\mathsf{PRF^{expand}_{rseed}}([\mathtt{0x05}] \,||\, \underline{\text{ρ}})\kern-0.1em\big),&\!\!\!\text{if } \mathsf{leadByte} = \mathtt{0x02} \\
-> \mathsf{H^{rcm,Orchard}_{rseed}}(\mathsf{g}\star_{\mathsf{d}}, \mathsf{pk}\star_{\mathsf{d}}, \mathsf{v}, \underline{\text{ρ}}, \text{ψ}),&\!\!\!\text{if } \mathsf{leadByte} = \mathtt{0x03}
+> \mathsf{ToScalar^{Orchard}}\big(\mathsf{PRF^{expand}_{rseed}}([\mathtt{0x05}] \,||\, \underline{\text{ρ}})\kern-0.1em\big),&\!\!\!\textsf{if } \mathsf{leadByte} = \mathtt{0x02} \\
+> \mathsf{H^{rcm,Orchard}_{rseed}}(\mathsf{g}\star_{\mathsf{d}}, \mathsf{pk}\star_{\mathsf{d}}, \mathsf{v}, \underline{\text{ρ}}, \text{ψ}),&\!\!\!\textsf{if } \mathsf{leadByte} = \mathtt{0x03}
> \end{cases}$
>
> Define $\mathsf{H^{esk,Orchard}_{rseed}}(\underline{\text{ρ}}) = \mathsf{ToScalar^{Orchard}}\big(\mathsf{PRF^{expand}_{rseed}}([\mathtt{0x04}] \,||\, \underline{\text{ρ}})\kern-0.1em\big)$.
@@ -852,8 +852,8 @@ with
For § 4.20.2, replace
> $\hspace{1.0em}$ let $\mathsf{rcm} = \begin{cases}
-> \mathsf{LEOS2IP}_{256}(\mathsf{rseed}),&\!\!\!\text{if } \mathsf{leadByte} = \mathtt{0x01} \\
-> \mathsf{ToScalar}\big(\mathsf{PRF^{expand}_{rseed}}(\mathsf{pre\_rcm})\kern-0.1em\big),&\!\!\!\text{otherwise}
+> \mathsf{LEOS2IP}_{256}(\mathsf{rseed}),&\!\!\!\textsf{if } \mathsf{leadByte} = \mathtt{0x01} \\
+> \mathsf{ToScalar}\big(\mathsf{PRF^{expand}_{rseed}}(\mathsf{pre\_rcm})\kern-0.1em\big),&\!\!\!\textsf{otherwise}
> \end{cases}$
> $\hspace{1.0em}$ if $\mathsf{rcm} \geq r_{\mathbb{G}}$, return $\bot$
> $\hspace{1.0em}$ let $\mathsf{g_d} = \mathsf{DiversifyHash}(\mathsf{d})$. if (for Sapling) $\mathsf{g_d} = \bot$, return $\bot$
@@ -874,8 +874,8 @@ with
> $\hspace{1.0em}$ let $\mathsf{g}\star_{\mathsf{d}} = \mathsf{repr}_{\mathbb{P}}(\mathsf{g_d})$, $\mathsf{pk}\star_{\mathsf{d}} = \mathsf{repr}_{\mathbb{P}}(\mathsf{pk_d})$
> $\hspace{1.0em}$ let $\text{ψ} = \mathsf{H^{\text{ψ},Orchard}_{rseed}}(\underline{\text{ρ}})$ for Orchard or $\bot$ for Sapling
> $\hspace{1.0em}$ let $\mathsf{rcm} = \begin{cases}
-> \mathsf{Derive\_rcm^{Sapling}_{rseed}}(\mathsf{leadByte}),&\!\!\!\text{if } \mathsf{protocol} = \mathsf{Sapling} \\
-> \mathsf{Derive\_rcm^{Orchard}_{rseed}}(\mathsf{leadByte}, \mathsf{g}\star_{\mathsf{d}}, \mathsf{pk}\star_{\mathsf{d}}, \mathsf{v}, \underline{\text{ρ}}, \text{ψ}),&\!\!\!\text{if } \mathsf{protocol} = \mathsf{Orchard}
+> \mathsf{Derive\_rcm^{Sapling}_{rseed}}(\mathsf{leadByte}),&\!\!\!\textsf{if } \mathsf{protocol} = \mathsf{Sapling} \\
+> \mathsf{Derive\_rcm^{Orchard}_{rseed}}(\mathsf{leadByte}, \mathsf{g}\star_{\mathsf{d}}, \mathsf{pk}\star_{\mathsf{d}}, \mathsf{v}, \underline{\text{ρ}}, \text{ψ}),&\!\!\!\textsf{if } \mathsf{protocol} = \mathsf{Orchard}
> \end{cases}$
> $\hspace{1.0em}$ if $\mathsf{rcm} \geq r_{\mathbb{G}}$, return $\bot$
@@ -888,8 +888,8 @@ define $\mathsf{Derive\_rcm^{\{Sapling,Orchard\}}}$ and $\mathsf{H^{esk,\{Saplin
For § 4.20.3, replace
> $\hspace{1.0em}$ let $\mathsf{rcm} = \begin{cases}
-> \mathsf{LEOS2IP}_{256}(\mathsf{rseed}),&\!\!\!\text{if } \mathsf{leadByte} = \mathtt{0x01} \\
-> \mathsf{ToScalar}\big(\mathsf{PRF^{expand}_{rseed}}(\mathsf{pre\_rcm})\kern-0.1em\big),&\!\!\!\text{otherwise}
+> \mathsf{LEOS2IP}_{256}(\mathsf{rseed}),&\!\!\!\textsf{if } \mathsf{leadByte} = \mathtt{0x01} \\
+> \mathsf{ToScalar}\big(\mathsf{PRF^{expand}_{rseed}}(\mathsf{pre\_rcm})\kern-0.1em\big),&\!\!\!\textsf{otherwise}
> \end{cases}$
> $\hspace{1.0em}$ if $\mathsf{rcm} \geq r_{\mathbb{G}}$, return $\bot$
> $\hspace{1.0em}$ let $\mathsf{g_d} = \mathsf{DiversifyHash}(\mathsf{d})$. if (for Sapling) $\mathsf{g_d} = \bot$ or $\mathsf{pk_d} \not\in \mathbb{J}^{(r)*}$ (see note below), return $\bot$
@@ -900,8 +900,8 @@ with
> $\hspace{1.0em}$ let $\mathsf{g}\star_{\mathsf{d}} = \mathsf{repr}_{\mathbb{P}}(\mathsf{g_d})$, $\mathsf{pk}\star_{\mathsf{d}} = \mathsf{repr}_{\mathbb{P}}(\mathsf{pk_d})$
> $\hspace{1.0em}$ let $\text{ψ} = \mathsf{H^{\text{ψ},Orchard}_{rseed}}(\underline{\text{ρ}})$ for Orchard or $\bot$ for Sapling
> $\hspace{1.0em}$ let $\mathsf{rcm} = \begin{cases}
-> \mathsf{Derive\_rcm^{Sapling}_{rseed}}(\mathsf{leadByte}),&\!\!\!\text{if } \mathsf{protocol} = \mathsf{Sapling} \\
-> \mathsf{Derive\_rcm^{Orchard}_{rseed}}(\mathsf{leadByte}, \mathsf{g}\star_{\mathsf{d}}, \mathsf{pk}\star_{\mathsf{d}}, \mathsf{v}, \underline{\text{ρ}}, \text{ψ}),&\!\!\!\text{if } \mathsf{protocol} = \mathsf{Orchard}
+> \mathsf{Derive\_rcm^{Sapling}_{rseed}}(\mathsf{leadByte}),&\!\!\!\textsf{if } \mathsf{protocol} = \mathsf{Sapling} \\
+> \mathsf{Derive\_rcm^{Orchard}_{rseed}}(\mathsf{leadByte}, \mathsf{g}\star_{\mathsf{d}}, \mathsf{pk}\star_{\mathsf{d}}, \mathsf{v}, \underline{\text{ρ}}, \text{ψ}),&\!\!\!\textsf{if } \mathsf{protocol} = \mathsf{Orchard}
> \end{cases}$
> $\hspace{1.0em}$ if $\mathsf{rcm} \geq r_{\mathbb{G}}$, return $\bot$
@@ -1051,7 +1051,7 @@ $\begin{array}{l}
\wedge\; \mathsf{cm} \neq \bot \vphantom{\Big(}\\
\wedge\; \text{let } \mathsf{cm}_x = \mathsf{Extract}_{\mathbb{P}}(\mathsf{cm}) \vphantom{\big(}\\
\wedge\; \text{let } \mathsf{leaf} = \mathsf{MerkleCRH}(\mathsf{cm}_x, \text{ρ}) \vphantom{\Big(}\\
-\wedge\; \mathsf{path} \text{ is a path to } \mathsf{leaf} \text{ in the rehashed commitment tree} \vphantom{\big(}\\
+\wedge\; \mathsf{path} \textsf{ is a path to } \mathsf{leaf} \textsf{ in the rehashed commitment tree} \vphantom{\big(}\\
\wedge\; \mathsf{nf} = \mathsf{DeriveNullifier_{nk}}(\text{ρ}, \text{ψ}, \mathsf{cm}) \vphantom{\Big(}\\
\}
\end{array}$
@@ -1170,11 +1170,11 @@ and some other function of $\mathsf{notetuple}$.
Without loss of generality, we can write that function as
$[\mathsf{f}(\mathsf{notetuple})]\, \mathcal{R}$,
by expanding each of the Sinemilla bases
-$\mathcal{C}_j = \mathcal{Q}(D) \text{ or } \mathcal{S}(j)$ used by
+$\mathcal{C}_j = \mathcal{Q}(D) \textsf{ or } \mathcal{S}(j)$ used by
[$\mathsf{HashToSinsimillaPoint}$](https://zips.z.cash/protocol/protocol.pdf#concretesinsemillahash)
as $\mathcal{C}_j = [c_j]\, \mathcal{R}$ for some $c_j$. That is,
the note commitment for $\mathsf{notetuple}$ is
-$$[\mathsf{H^{rcm}_{rseed}}(\mathsf{noterepr}) + \mathsf{f}(\mathsf{notetuple})]\, \mathcal{R}\textsf{\small .}$$
+$$[\mathsf{H^{rcm}_{rseed}}(\mathsf{noterepr}) + \mathsf{f}(\mathsf{notetuple})]\, \mathcal{R}\textsf{.}$$
We will model $\mathsf{H^{rcm}}$ as a random oracle independent of $\mathsf{f}$ with
uniform output on $\mathbb{F}_{r_{\mathbb{P}}}$. This is reasonable because
@@ -1418,19 +1418,19 @@ $\varepsilon_{\mathsf{kb}}(\mathcal{A}, q_{\mathsf{kb}}) \leq \frac{3\, q_{\math
*Algebraic setup.*
By § 5.4.1.10 “Sinsemilla commitments”,
$$\mathsf{Commit^{ivk}_{rivk}}(\mathsf{ak}, \mathsf{nk}) =
-\mathsf{Extract}_{\mathbb{P}}\big(M' + [\mathsf{rivk}]\, \mathcal{S}\big)\textsf{\small ,}$$
+\mathsf{Extract}_{\mathbb{P}}\big(M' + [\mathsf{rivk}]\, \mathcal{S}\big)\textsf{,}$$
where $\mathcal{S}$ is the rivk-randomization base
-$$\mathcal{S} := \mathsf{GroupHash}^{\mathbb{P}}(\texttt{“z.cash:Orchard-CommitIvk-r”}, \texttt{“”})\textsf{\small ,}$$
+$$\mathcal{S} := \mathsf{GroupHash}^{\mathbb{P}}(\texttt{“z.cash:Orchard-CommitIvk-r”}, \texttt{“”})\textsf{,}$$
and
$$M' := \mathsf{SinsemillaHashToPoint}\big(\texttt{“z.cash:Orchard-CommitIvk-M”},\;
\mathsf{I2LEBSP}_{\ell^{\mathsf{Orchard}}_{\mathsf{base}}}(\mathsf{ak}) \,\Vert\,
-\mathsf{I2LEBSP}_{\ell^{\mathsf{Orchard}}_{\mathsf{base}}}(\mathsf{nk})\big)\textsf{\small .}$$
+\mathsf{I2LEBSP}_{\ell^{\mathsf{Orchard}}_{\mathsf{base}}}(\mathsf{nk})\big)\textsf{.}$$
By expanding the Sinsemilla bases used inside $\mathsf{SinsemillaHashToPoint}$
as scalar multiples of $\mathcal{S}$, without loss of generality we have
$M' = [h(\mathsf{ak}, \mathsf{nk})]\, \mathcal{S}$ for a Pedersen-like
deterministic scalar hash $h$, so
$$\mathsf{Commit^{ivk}_{rivk}}(\mathsf{ak}, \mathsf{nk}) =
-\mathsf{Extract}_{\mathbb{P}}\big([h(\mathsf{ak}, \mathsf{nk}) + \mathsf{rivk}]\, \mathcal{S}\big)\textsf{\small .}$$
+\mathsf{Extract}_{\mathbb{P}}\big([h(\mathsf{ak}, \mathsf{nk}) + \mathsf{rivk}]\, \mathcal{S}\big)\textsf{.}$$
Domain separation in
the protocol's BLAKE2b instantiations ensures $h$ does not query
$\mathsf{H^{rivk\_ext}}$, $\mathsf{H^{rivk\_legacy}}$,
@@ -1440,7 +1440,7 @@ $h$ depends only on fixed Sinsemilla bases and on $(\mathsf{ak}, \mathsf{nk})$.
By the same $y^2 = Y(x)$ argument used in the Spendability proof
(using § 5.4.9.7 for the $\mathsf{Extract}_{\mathbb{P}}$-style
$x$-coordinate convention), a key-binding break implies
-$$h(\mathsf{ak}, \mathsf{nk}) + \mathsf{rivk} \equiv \pm\big(h(\mathsf{ak}', \mathsf{nk}') + \mathsf{rivk}'\big) \pmod{r_{\mathbb{P}}}\textsf{\small .}$$
+$$h(\mathsf{ak}, \mathsf{nk}) + \mathsf{rivk} \equiv \pm\big(h(\mathsf{ak}', \mathsf{nk}') + \mathsf{rivk}'\big) \pmod{r_{\mathbb{P}}}\textsf{.}$$
Define $\mathsf{G}(w) := h(\mathsf{ak}, \mathsf{nk}) + \mathsf{rivk} \pmod{r_{\mathbb{P}}}$
for a witness $w$, and let $G_i := \mathsf{G}(w_i)$ for $i \in \{1, 2\}$.
The break condition is
@@ -1530,7 +1530,7 @@ single combined uniform random oracle on the joint query domain (each
RO contributes its outputs independently of the others), and
union-bounding over the at most ${q_{\mathsf{kb}} \choose 2}$ pairs
of distinct witnesses,
-$$\varepsilon_{\mathsf{kb}}(\mathcal{A}, q_{\mathsf{kb}}) \leq \frac{3 q_{\mathsf{kb}}(q_{\mathsf{kb}}-1)}{2 r_{\mathbb{P}}}\textsf{\small .}$$
+$$\varepsilon_{\mathsf{kb}}(\mathcal{A}, q_{\mathsf{kb}}) \leq \frac{3 q_{\mathsf{kb}}(q_{\mathsf{kb}}-1)}{2 r_{\mathbb{P}}}\textsf{.}$$
## Security argument for Spendability
@@ -1569,7 +1569,7 @@ $$\mathsf{DeriveNullifier_{nk}}(\text{ρ}, \text{ψ}, \mathsf{cm}) :=
Also recall from [Repairing note commitments] that we have
$$\mathsf{cm} = [\mathsf{H^{rcm}_{rseed}}(\mathsf{noterepr})
- + \mathsf{f}(\mathsf{rseed}, \mathsf{noterepr})]\, \mathcal{R}\textsf{\small .}$$
+ + \mathsf{f}(\mathsf{rseed}, \mathsf{noterepr})]\, \mathcal{R}\textsf{.}$$
Let $K_{\kern-.08em\mathcal{R}}$ denote the discrete logarithm of
$\mathcal{K}$ with respect to $\mathcal{R}$. This is well-defined and
@@ -1587,7 +1587,7 @@ $$\mathsf{Extract}_{\mathbb{P}}\Big(
\big((\mathsf{PRF^{nf}_{nk}}(\text{ρ}) + \text{ψ}) \bmod q_{\mathbb{P}}\big) \cdot K_{\kern-.08em\mathcal{R}}
+ \mathsf{H^{rcm}_{rseed}}(\mathsf{noterepr}) + \mathsf{f}(\mathsf{rseed}, \mathsf{noterepr})
\big]\, \mathcal{R}
- \Big)\textsf{\small .}$$
+ \Big)\textsf{.}$$
We model $\mathsf{H^{rcm}}$ as a random oracle with output uniform on
$\mathbb{F}_{r_{\mathbb{P}}}$. The functions $\mathsf{f}$,
@@ -1680,7 +1680,7 @@ satisfying:
Then $\mathcal{A}$ wins this game with probability at most
$$\Big({\textstyle{q_{\mathsf{rcm}}} \atop \textstyle{2}}\Big) \cdot \frac{2}{r_{\mathbb{P}}}
+ \varepsilon_{\mathsf{kb}}(\mathcal{A}, q_{\mathsf{kb}})
- = \frac{q_{\mathsf{rcm}}(q_{\mathsf{rcm}}-1)}{r_{\mathbb{P}}} + \varepsilon_{\mathsf{kb}}(\mathcal{A}, q_{\mathsf{kb}})\textsf{\small ,}$$
+ = \frac{q_{\mathsf{rcm}}(q_{\mathsf{rcm}}-1)}{r_{\mathbb{P}}} + \varepsilon_{\mathsf{kb}}(\mathcal{A}, q_{\mathsf{kb}})\textsf{,}$$
taken over the random oracle's responses and any internal randomness of
$\mathcal{A}$.
@@ -1715,7 +1715,7 @@ Under this conditioning, define
$$\mathsf{F}(\mathsf{notetuple}) := \mathsf{H^{rcm}}(\mathsf{notetuple}) +
\mathsf{f}(\mathsf{notetuple}) + \big((\mathsf{PRF^{nf}_{nk}}(\text{ρ}) +
\text{ψ}) \bmod q_{\mathbb{P}}\big) \cdot K_{\kern-.08em\mathcal{R}}
-\pmod{r_{\mathbb{P}}}\textsf{\small ,}$$
+\pmod{r_{\mathbb{P}}}$$,
where $\mathsf{rseed}, \text{ρ}, \text{ψ}$ are fields of
$\mathsf{notetuple}$ and $\mathsf{PRF^{nf}_{nk}}(\text{ρ})$ is
determined by $\mathsf{notetuple}$ via the
@@ -1745,10 +1745,10 @@ pair of independent uniform variables, satisfied with probability at
most $2/r_{\mathbb{P}}$ (one per sign). Union-bounding over the at
most ${q_{\mathsf{rcm}} \choose 2}$ pairs of distinct
$\mathsf{H^{rcm}}$ queries:
-$$\Pr[\text{win} \mid \neg\,\text{break}] \leq \frac{q_{\mathsf{rcm}}(q_{\mathsf{rcm}}-1)}{r_{\mathbb{P}}}\textsf{\small .}$$
+$$\Pr[\text{win} \mid \neg\,\text{break}] \leq \frac{q_{\mathsf{rcm}}(q_{\mathsf{rcm}}-1)}{r_{\mathbb{P}}}\textsf{.}$$
Decomposing on whether a key-binding break occurs and applying
$\Pr[\text{win}] \leq \Pr[\text{win} \mid \neg\,\text{break}] + \Pr[\text{break}]$:
-$$\Pr[\text{win}] \leq \frac{q_{\mathsf{rcm}}(q_{\mathsf{rcm}}-1)}{r_{\mathbb{P}}} + \varepsilon_{\mathsf{kb}}(\mathcal{A}, q_{\mathsf{kb}})\textsf{\small .}$$
+$$\Pr[\text{win}] \leq \frac{q_{\mathsf{rcm}}(q_{\mathsf{rcm}}-1)}{r_{\mathbb{P}}} + \varepsilon_{\mathsf{kb}}(\mathcal{A}, q_{\mathsf{kb}})\textsf{.}$$
This completes the classical-ROM proof.
The [key-binding theorem](#thm-key-binding-rom) bounds