Docs: Fix typos and grammar errors

Author: InfiniteSynthesis

algorithms/extend-policy.tex

@@ -24,13 +24,13 @@
 
 		\State{Let $\vec{\tx} = (\tx_1, \ldots , \tx_{|\mathtt{NxtBC}_i|})$ denote the transactions of $\mathtt{NxtBC}_i$}
 
-		\If{$\tx_1$ is not a coinbase trasnaction}
+		\If{$\tx_1$ is not a coinbase transaction}
 		\State{\Return \txSeqProposalDefault}
 		\Else
 
 		\State{$\txSeqProposal_i \gets \tx_1$}
 
-		\For{$j = 2$ \textbf{to} $| \mathtt{NxtBC} |$}
+		\For{$j = 2$ \textbf{to} $| \mathtt{NxtBC}_i |$}
 
 		\State{$\st_i \gets \blockify(\txSeqProposal_i)$}
 

algorithms/pke-two-decryptions.tex

@@ -33,11 +33,11 @@
 	\begin{minipage}[t]{.49\textwidth}
 		\begin{algorithmWithNumbering}{PKEcounter}
 			\Statex{\underline{$\Dec(ct)$}}
-			\State{Parse $\mathsf{sk}$ as $(\mathsf{f}_i, \mathsf{f}\inv_i, \mathsf{b}_i)$ and $ct$ as $ct_1, \ldots, ct_k$.}
+			\State{Parse $\mathsf{sk}$ as $(\mathsf{f}, \mathsf{f}\inv, \mathsf{b})$ and $ct$ as $ct_1, \ldots, ct_k$.}
 
 			\For{$i$ \textbf{from} $1$ \textbf{to} $k$}
 			\State{Parse $ct_i$ as $ct'_i \concat b'_i$}
-			\State{Compute $x'_i \gets \mathsf{f}\inv_i(ct'_i)$}
+			\State{Compute $x'_i \gets \mathsf{f}\inv(ct'_i)$}
 			\State{Set $m'_i \gets \mathsf{b}(x'_i) \oplus b'_i$}
 			\EndFor
 			\State{Set $m' \gets m'_1, \ldots, m'_k$ and \Return $m'$.}
@@ -47,11 +47,11 @@
 
 		\begin{algorithmWithNumbering}{PKEcounter}
 			\Statex{\underline{$\Dec^*(ct)$}}
-			\State{Parse $\mathsf{sk}$ as $(\mathsf{f}_i, \mathsf{f}\inv_i, \mathsf{b}_i)$ and $ct$ as $ct_1, \ldots, ct_k$.}
+			\State{Parse $\mathsf{sk}$ as $(\mathsf{f}, \mathsf{f}\inv, \mathsf{b})$ and $ct$ as $ct_1, \ldots, ct_k$.}
 
 			\For{$i$ \textbf{from} $1$ \textbf{to} $k$}
 			\State{Parse $ct_i$ as $ct'_i \concat b'_i$}
-			\State{Compute $x'_i \gets \mathsf{f}\inv_i(ct'_i)$}
+			\State{Compute $x'_i \gets \mathsf{f}\inv(ct'_i)$}
 			\State{Set $m'_i \gets \funcGrpoRO(x'_i) \oplus b'_i$}
 			\EndFor
 			\State{Set $m' \gets m'_1, \ldots, m'_k$ and \Return $m'$.}

content/introduction/main.tex

@@ -15,7 +15,7 @@ \section{Introduction}
 %
 More recently, the Bitcoin blockchain protocol \cite{Nak08} provided a solution in a ``permissionless'' setting where participants do not know of each other and only a public setup operation is permitted.
 %
-The protocol and its properties has been analyzed over a sequence of works \cite{EC:GarKiaLeo15,EC:PasSeeash17,C:GarKiaLeo17} that established its explicit guarantees regarding liveness and consistency.
+The protocol and its properties have been analyzed over a sequence of works \cite{EC:GarKiaLeo15,EC:PasSeeash17,C:GarKiaLeo17} that established its explicit guarantees regarding liveness and consistency.
 
 The main task of a ledger consensus protocol is to continuously serialize the submitted transactions.
 %

content/introduction/our-results.tex

@@ -23,7 +23,7 @@ \subsection{Our Results}
 %
 This ideal functionality model results to a class of fair ledgers.
 
-The most stringiest extend policy one can imagine for serializing transactions is the exact order that they were submitted to the ideal functionality.
+The most stringent extend policy one can imagine for serializing transactions is the exact order in which they were submitted to the ideal functionality.
 %
 Note that in many ways such a ``perfect'' order is unreasonable; taking into account the global clock in the model, it could be the case that two transactions are ``simultaneously'' delivered w.r.t. the global clock.
 %
@@ -67,7 +67,7 @@ \subsection{Our Results}
 %
 We first show how to enforce input-causality, and then we show how to lift the security of our protocol to realize a ledger that has \delay-approximate order fairness.
 %
-Our protocol is built on top of a Nakamoto-style PoW blockchain \chain, whose maintainers are equipped with a stateless\footnote{By stateless here we mean without secure counters, or without any mechanism that prevents the adversary from resetting the enclave.} trusted execution environment\cite{EPRINT:CosDev16} (enclave for brevity).
+Our protocol is built on top of a Nakamoto-style PoW blockchain \chain, whose maintainers are equipped with a stateless\footnote{By stateless here we mean without secure counters, or without any mechanism that prevents the adversary from resetting the enclave.} trusted execution environment~\cite{EPRINT:CosDev16} (enclave for brevity).
 %
 Each enclave is equipped with its own public-key encryption key pair $(\pk, \sk)$\footnote{Note that in the hybrid model where communication takes place strictly via the diffusion functionality \funcDiffuse that we use to model the peer-to-peer network, sharing a secret key \sk among $n$ enclaves requires diffusing $n$ distinct messages from a single source --- a prohibitive overhead. Contrary, in our protocol, in the worst case, each party has to diffuse polylogarithmic in the number of enclaves sized messages. Combining the capabilities of the enclave with the gossiping protocol over point-to-point channels may improve communication complexity --- we leave exploring this interesting direction for future work.}, where only \pk is revealed, while \sk is hidden to everyone (including the owner of the enclave).
 %
@@ -155,7 +155,7 @@ \subsection{Our Results}
 %
 Formally, the timestamping of the transaction is computed as follows:
 %
-\( \timestamp{\txTag} \triangleq \med \{ t \mathbin|  (\txTag, t) \in \PB \in B \wedge \ell \le \mathsf{height}(B) < \ell + \PBWindowLen\}. \)
+\( \timestamp{\txTag} \triangleq \med \{ t \mathbin|  (\txTag, t) \in \PB \in \block \wedge \ell \le \mathsf{height}(\block) < \ell + \PBWindowLen\}. \)
 %
 The median provides \delay-order fairness because we can argue that in the \PBWindowLen-block window associated with \txTag the majority of the timestamps are generated by honest parties.
 
@@ -177,7 +177,7 @@ \subsection{Our Results}
 %
 Note that our protocol is a PoW-based blockchain and hence it allows non-permissioned nodes to still contribute to the protocol without processing encrypted transactions; in fact such un-permissioned blocks may even contain transactions that are submitted unencrypted for which the clients do not wish to have them protected for sender-order fairness.
 %
-As a side remark, this simple observation suggests that our protocol can be implemented as a ``soft-fork'' over bitcoin --- we leave the details of this implementation to be explored in future work.
+As a side remark, this simple observation suggests that our protocol can be implemented as a ``soft-fork'' over Bitcoin --- we leave the details of this implementation to be explored in future work.
 
 Additionally, the security of our protocol relies on two assumptions --- honest majority in terms of computational power and a constant fraction of the enclaves being possessed by honest hosts.
 %
@@ -187,7 +187,7 @@ \subsection{Our Results}
 %
 Our approach is to extend the \twoforone PoW to $3 {\times} 1$ PoW (by checking non-overlapping 0s at different positions of the RO output), thus additionally mining the enclave public keys (each message mines only one key).
 %
-These PoW-ed enclave public keys are included in the blockchain, and the key subset selection procedure is then applied on the set of public keys with \emph{weights} based on their PoW (for instance, a key with two unique PoW-ed messages is weighed two times than another key with one unique message).
+These PoW-ed enclave public keys are included in the blockchain, and the key subset selection procedure is then applied on the set of public keys with \emph{weights} based on their PoW (for instance, a key with two unique PoW-ed messages has twice the weight of another key with one unique message).
 %
 This adaption, with appropriate protocol parametrization, guarantees that the majority of weighted public keys are controlled by honest parties regardless of the fraction of honest keys.
 

content/ledger-extend-policy/main.tex

@@ -23,7 +23,7 @@ \section{Ledger Functionality with Parametric Extend Policy}
 %
 To improve accessibility, we mark in \revisedText{blue} the differences compared with the original \textsf{ExtendPolicy} in~\cite{C:BMTZ17}.
 
-Upon receiving a proposed block from the adversary, \textsf{ExtendPolicy} iterates all transactions; for each transaction \tx, its \emph{order} and validity with respect to the current state and buffer is evaluated.
+Upon receiving a proposed block from the adversary, \textsf{ExtendPolicy} iterates over all transactions; for each transaction \tx, its \emph{order} and validity with respect to the current state and buffer is evaluated.
 %
 If \tx turns out to be a valid transaction and extends the ledger following the fair-order policy, the algorithm goes for the next transaction; otherwise, it aborts and returns default blocks from \textsf{DefaultExtension}.
 %

content/preliminaries/contd.tex

@@ -31,7 +31,7 @@ \section{Preliminaries (Cont'd)}
 
 In order to limit the adversary on making a certain number of queries per round, we adopt a functionality wrapper \cite{C:BMTZ17} that wraps the corresponding resource to capture such restrictions.
 %
-Note that since now \funcGRO is shared among different sessions, the adversary can ask the environment to make queries on behalf.
+Note that since now \funcGRO is shared among different sessions, the adversary can ask the environment to make queries on his behalf.
 %
 Hence, our wrapper \wrapper{\funcGRO} also puts restrictions on queries that are made by the environment.
 

content/protocol-details/further-discussions.tex

@@ -15,7 +15,7 @@ \subsection{Further Discussions}
 %
 This translation is immediate: the \twoforone PoW can be replace by using two independent VRF evaluations, one for extending the PoS chain and the other for generating profile blocks.
 %
-This replacement is provably equivalent and has been seen wide usage (see, e.g.,~\cite{TCC:FGKR20} for more discussion).
+This replacement is provably equivalent and has seen wide usage (see, e.g.,~\cite{TCC:FGKR20} for more discussion).
 %
 On the other hand, in PoS the simulation for chain extending is ``for free'', and since the enclaves are clock-oblivious they should not decrypt transactions using the ``progression'' on a PoS chain.
 %

content/protocol-details/transaction-encryption.tex

@@ -149,7 +149,7 @@ \subsection{Transaction Encryption from Trusted Hardware}
 
 We then consider a function $f_{\mathsf{select}}(\mathcal{S}, m, \ticket)$ which, taking a set $\mathcal{S}$, a threshold $m \in \mathbb{N}^+$ and $\ticket \in \{0, 1\}^\kappa$ as parameters, outputs an element in $\mathcal{S}$.
 %
-Formally, let $\binom{\mathcal{S}}{m}$ denote the the (ordered) set of all $m$-combinations of $\mathcal{S}$ (when $|\mathcal{S}| < m$, $f_{\mathsf{select}} $ returns $\mathcal{S}$ directly), we define the selection function as
+Formally, let $\binom{\mathcal{S}}{m}$ denote the (ordered) set of all $m$-combinations of $\mathcal{S}$ (when $|\mathcal{S}| < m$, $f_{\mathsf{select}} $ returns $\mathcal{S}$ directly), we define the selection function as
 %
 \begin{equation*}
 	f_{\mathsf{select}} = \binom{\mathcal{S}}{m} \bigg[\ticket \mod \Big|\binom{\mathcal{S}}{m} \Big| \bigg].
@@ -165,7 +165,7 @@ \subsection{Transaction Encryption from Trusted Hardware}
 %
 By randomly selecting an element in $\binom{\mathcal{S}}{m}$, the probability that the chosen $m$-combination contains no honest public key is negligible with respect to the security parameter $\kappa$.
 %
-Furthermore, since only a ticket that is associated with a settled block will be used by parties to select public keys (otherwise the encrypted transaction will be considered illegitimate), the total number of tickets that are eligible to use throughout an execution running for $L = \poly(\kappa)$ rounds is polynomially bounded by $\kappa$ and $n$ where $n$ is the number of enclaves.
+Furthermore, since only a ticket that is associated with a settled block will be used by parties to select public keys (otherwise the encrypted transaction will be considered illegitimate), the total number of valid tickets throughout an execution running for $L = \poly(\kappa)$ rounds is polynomially bounded by $\kappa$ and $n$ where $n$ is the number of enclaves.
 %
 Refer to~\cref{lemma:good-block-tickets} for the formal analysis of this scheme.
 

content/security-analysis/blockchain-security.tex

@@ -43,7 +43,7 @@ \subsection{Blockchain Security Properties}
 \begin{lemma}
 	[Majority of honest profile blocks]
 	\label{lemma:good-profile-blocks}
-	If the properties as in~\cref{lemma:blockchain-properties} are not violated during the execution, then in an execution of \protocFairLedger over a lifetime of $L = \poly(\kappa)$ rounds, for any segmentation of the blockchain of $\PBWindowLen = \Theta(\CPLen)$ consecutive blocks, the majority of the profile blocks included are produced by honest parties.
+	If common prefix, chain growth and chain quality properties (with the same parameters as those in~\cref{lemma:blockchain-properties}) are not violated during the execution, then in an execution of \protocFairLedger over a lifetime of $L = \poly(\kappa)$ rounds, for any segmentation of the blockchain of $\PBWindowLen = \Theta(\CPLen)$ consecutive blocks, the majority of the profile blocks included are produced by honest parties.
 \end{lemma}
 
 

content/security-analysis/composable-guarantees.tex

@@ -1,7 +1,7 @@
 \subsection{Composable Guarantees}
 \label{subsec:composable-guarantees}
 
-\cref{subsec:blockchain-security-properties} shows that when the simulator jointly builds the blockchain with the black-box adversary, bad events regarding the violation of good blockchain properties, namely \badCP, \badCQ, \badCG and \badProfile, happens with negligible probability.
+\cref{subsec:blockchain-security-properties} shows that when the simulator jointly builds the blockchain with the black-box adversary, bad events regarding the violation of good blockchain properties, namely \badCP, \badCQ, \badCG and \badProfile, happen with negligible probability.
 %
 We next prove that the simulator \simulator can simulate the transaction encryption mechanism well, by showing that all bad events \badTicket, \badNIZK and \badDec happen with negligible probability.
 %
@@ -49,7 +49,7 @@ \subsection{Composable Guarantees}
 	%
 	For each random subset selection, the probability that no honest key is selected is bounded by $(1 - p)^m < \exp(-\Omega(\polylog\kappa))$, by selecting $n \cdot \poly(\kappa)$ we get $\Pr[E] = 1 - (1 - \exp(-\Omega(\polylog\kappa)))^{n \cdot \poly(\kappa)} = \exp(-\Omega(\polylog(\kappa)) + \ln n)$ which is negligible in $\kappa$.
 
-	Now it suffices to show that by replacing the random number with $\fPRF(\mathsf{key}, h)$, for each ticket there is still at least one key controlled by honest party get selected.
+	Now it suffices to show that by replacing the random number with $\fPRF(\mathsf{key}, h)$, for each ticket there is still at least one honest key that gets selected.
 	%
 	This can be proved by a reduction to the indistinguishability experiment of the underlying pseudorandom function \fPRF which we omit here (note that while each enclave possesses her own key, since the total number of the enclaves are polynomially bounded this does not hurt the argument).
 \end{proof}