From d82f2a9cf769247874ecdcd52907c2df81127475 Mon Sep 17 00:00:00 2001 From: hattizai <150505746+hattizai@users.noreply.github.com> Date: Tue, 9 Jan 2024 01:09:09 +0800 Subject: [PATCH] chore: fix docs typos (#3587) * Update extension.md Signed-off-by: hattizai <150505746+hattizai@users.noreply.github.com> * fix typos in governance.md Signed-off-by: hattizai <150505746+hattizai@users.noreply.github.com> * fix typos in ideal.md Signed-off-by: hattizai <150505746+hattizai@users.noreply.github.com> * fix typos in sender-receiver.md Signed-off-by: hattizai <150505746+hattizai@users.noreply.github.com> * fix typos in threshold-encryption.md Signed-off-by: hattizai <150505746+hattizai@users.noreply.github.com> --------- Signed-off-by: hattizai <150505746+hattizai@users.noreply.github.com> --- docs/guide/src/extension.md | 2 +- docs/guide/src/pcli/governance.md | 4 ++-- .../src/crypto/flow-encryption/threshold-encryption.md | 4 ++-- docs/protocol/src/crypto/flow/ideal.md | 2 +- docs/protocol/src/crypto/fmd/sender-receiver.md | 4 ++-- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/guide/src/extension.md b/docs/guide/src/extension.md index 2cc267c4dc..f4acb5b945 100644 --- a/docs/guide/src/extension.md +++ b/docs/guide/src/extension.md @@ -30,7 +30,7 @@ recent testnet: diff --git a/docs/guide/src/pcli/governance.md b/docs/guide/src/pcli/governance.md index 0596cba343..e10bbc9a5c 100644 --- a/docs/guide/src/pcli/governance.md +++ b/docs/guide/src/pcli/governance.md @@ -98,9 +98,9 @@ slashed (but regardless of whether it passes or fails), the deposit will then be proposer at the end of voting. From the proposer's point of view, the lifecycle of a proposal begins when it is -_submitted_ and ends when it the deposit is _claimed_. During the voting period, the proposer may +_submitted_ and ends when the deposit is _claimed_. During the voting period, the proposer may also optionally _withdraw_ the proposal, which prevents it from passing, but does not prevent it -from being slashed. This is usually used when a proposal has been superceded by a revised +from being slashed. This is usually used when a proposal has been superseded by a revised alternative. diff --git a/docs/protocol/src/crypto/flow-encryption/threshold-encryption.md b/docs/protocol/src/crypto/flow-encryption/threshold-encryption.md index 2400580367..e39cbed3d9 100644 --- a/docs/protocol/src/crypto/flow-encryption/threshold-encryption.md +++ b/docs/protocol/src/crypto/flow-encryption/threshold-encryption.md @@ -160,7 +160,7 @@ ciphertext ($c_i$). To aggregate a given $v_e, v_e'$, simply add each limb: $$v_{agg} = v_e + v_e' = [c_0+c_0', c_1+c_1', c_2+c_2', c_3+c_3'] = \cdots = v_q + v_q' = v + v'$$ -This holds due to the homomorphic property of ElGamal cipertexts. +This holds due to the homomorphic property of ElGamal ciphertexts. The block producer aggregates every $v_{ei}$, producing a public transcript of the aggregation. The transcript can then be publicly validated by any validator @@ -250,7 +250,7 @@ where $\lambda_{i}$ is the lagrange coefficient (for x=0) at $i$, defined by $$\lambda_{0,i} = \prod_{n \in S, n \neq i} \frac{n}{n - i}$$ -where $S$ is the set of all participant indicies. +where $S$ is the set of all participant indices. Then, compute the resulting decryption by taking diff --git a/docs/protocol/src/crypto/flow/ideal.md b/docs/protocol/src/crypto/flow/ideal.md index fd7e0ee2d6..b1ff556e0c 100644 --- a/docs/protocol/src/crypto/flow/ideal.md +++ b/docs/protocol/src/crypto/flow/ideal.md @@ -149,7 +149,7 @@ participants (decryptors) must be able to verify that counterparty participants (other decryptors) are contributing to the DKG honestly, without the use of a trusted dealer. This can be achieved using something similar to [Feldman's Verifiable Secret Sharing][feldman] protocol, where each participant shares a -commitment to their share which is visable to all other participants. In +commitment to their share which is visible to all other participants. In addition, our DKG must be able to tolerate *rogue-key attacks*: that is, it must tolerate the instance where a validator maliciously chooses their share based on the value of the other validator's shares in order to cancel out other diff --git a/docs/protocol/src/crypto/fmd/sender-receiver.md b/docs/protocol/src/crypto/fmd/sender-receiver.md index 88dd05532f..3056c89367 100644 --- a/docs/protocol/src/crypto/fmd/sender-receiver.md +++ b/docs/protocol/src/crypto/fmd/sender-receiver.md @@ -72,7 +72,7 @@ R-FMD constructions in the original paper. Unlike R-FMD, the false positive rate is set by the sender, so `CreateClue` takes both the false positive rate $p$ and the receiver's clue key. Because the -false postive rate is set by the sender, there is no separation of capability +false positive rate is set by the sender, there is no separation of capability between the root key and a detection key, so `KeyGen` outputs a clue key and a detection key, and `Extract` disappears. @@ -94,4 +94,4 @@ Retrieval_][omr] paper of Zeyu Liu and Eran Tromer; we `CreateClue` and `Examine rather than `Flag` and `Test` flag ciphertexts. [macaroons]: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41892.pdf -[omr]: https://eprint.iacr.org/2021/1256 \ No newline at end of file +[omr]: https://eprint.iacr.org/2021/1256