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

@@ -30,7 +30,7 @@ recent testnet:
 
 <!--
 Do we want to maintain screenshots inside the web extension docs?
-The image files will become out of data quickly, requiring maitnenance, and bloat the repo.
+The image files will become out of data quickly, requiring maintenance, and bloat the repo.
 -->
 
 <picture>

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.
 
 <picture>

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
 

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

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
+[omr]: https://eprint.iacr.org/2021/1256