Merge pull request #899 from privacy-scaling-explorations/chore/branc…

…h-consolidation

chore(repo): branch consolidation

.github/workflows/checks.yml

@@ -2,7 +2,7 @@ name: Checks
 
 on:
   push:
-    branches: [master, dev]
+    branches: [dev]
   pull_request:
 
 concurrency:

.github/workflows/circuit-build.yml

@@ -2,7 +2,7 @@ name: Circuit
 
 on:
   push:
-    branches: [master, dev]
+    branches: [dev]
   pull_request:
 
 concurrency:

website/versioned_docs/version-v0.x/faq.md

@@ -10,23 +10,23 @@ sidebar_position: 6
 
 ### If the coordinator censors messages
 
-If the coordinator censors a message `N` by excluding it from the final vote tally, the logic in `processMessage()` will prevent them from processsing message `N+1` or any future message until they do so.
+If the coordinator censors a message `N` by excluding it from the final vote tally, the logic in `processMessage()` will prevent them from processing message `N+1` or any future message until they do so.
 
 ### If a user submits a message with an invalid signature
 
 The coordinator should verify the message's signature off-chain and if it is invalid, set the no-op flag to true and pass it into the state transition proof circuit. If the coordinator does not do this, they will fail to generate a valid proof anyway.
 
 ### If an adversarial miner bribes a user and controls the `randomLeaf` value passed into the state transition snark
 
-This adversary does not know the value of the other leaves of the state tree, so even if the coordinator updates leaf 0 with the adversary's entropy, the adversary cannot tell if the processed commmand is invalid.
+This adversary does not know the value of the other leaves of the state tree, so even if the coordinator updates leaf 0 with the adversary's entropy, the adversary cannot tell if the processed command is invalid.
 
 ### User creates a command that the snark cannot process
 
-The the system must be designed and built in a way such that this cannot happen.
+The system must be designed and built in a way such that this cannot happen.
 
 ### If a briber locks the user's key in trusted hardware
 
-Assuming that the locked key is not the user's initial public key, the briber has no way to tell if the user has not already changed their key. This scenario is therefore the same as that in which the user gives a public key to a briber witout trusted hardware.
+Assuming that the locked key is not the user's initial public key, the briber has no way to tell if the user has not already changed their key. This scenario is therefore the same as that in which the user gives a public key to a briber without trusted hardware.
 
 > [name=kobi]
 > I don't think the reasoning works, for example for a user with trusted hardware:
@@ -38,11 +38,11 @@ Assuming that the locked key is not the user's initial public key, the briber ha
 
 > [name=barry] I think that the attack is where you lock the initial key in trusted hardware. The solution is to use https://www.vitalik.ca/general/2019/10/01/story.html
 
-### Deposit my public key and i will pay you
+### Deposit my public key and I will pay you
 
 > [name=barry] This is the most serious attack IMO. The deposit stake is weak prevention for this.
 
-### If an attacker fills up the message tree with a such a large number of commands that the coordinator cannot afford to generate enough proofs to process them all
+### If an attacker fills up the message tree with such a large number of commands that the coordinator cannot afford to generate enough proofs to process them all
 
 Each user should be allowed to publish at no cost as many messages as there are vote options, plus a small number (e.g. 2). Each subsequent message should cost the user an increasing amount of ETH. When the coordinator processes the message, the contract should return the ETH to the user. As such, the majority of non-malicious users will not have to pay any more than the gas costs to vote, and spammers must put up capital to attack the coordinator.
 
@@ -54,7 +54,7 @@ Each user should be allowed to publish at no cost as many messages as there are
 1. It is impossible for a coordinator to find a collision in message decryptions. i.e. they cannot decrypt a message to a different command.
 2. It is impossible for a user to create a message that the coordinator is not able to process.
 3. It is impossible for a user to create a message such that the coordinator is unable to create a zk-SNARK proof of a state root transition.
-4. No-one but the coordindator can trustlessly bribe someone.
+4. No-one but the coordinator can trustlessly bribe someone.
 
 ## III: Desired features not described in this specification
 
@@ -64,4 +64,4 @@ Each user should be allowed to publish at no cost as many messages as there are
 
 ## IV: Quadratic and sybil-resistant million-dollar-homepages
 
-Another use case for MACI is a [million-dollar-homepage](http://www.milliondollarhomepage.com/) style bulletin board where users can post and quadratically vote on images. A user who owns a [POAP](https://www.poap.xyz/) token from a real-life event can sign up and receive 2 ^ 32 voting tokens per week. To add a picture to the board, they have to burn 1 ETH, which disincentivises spam. The visual prominance of size of each picture scales with the sum of square roots of the votes that it receives.
+Another use case for MACI is a [million-dollar-homepage](http://www.milliondollarhomepage.com/) style bulletin board where users can post and quadratically vote on images. A user who owns a [POAP](https://www.poap.xyz/) token from a real-life event can sign up and receive 2 ^ 32 voting tokens per week. To add a picture to the board, they have to burn 1 ETH, which disincentivises spam. The visual prominence of size of each picture scales with the sum of square roots of the votes that it receives.

website/versioned_docs/version-v0.x/introduction.md

@@ -106,7 +106,7 @@ The following steps are needed to sign and encrypt a message:
 
 ## Glossary
 
-Some terms in this specification are similar to one another but should not be used interchangably. This glossary should help to resolve such ambiguities.
+Some terms in this specification are similar to one another but should not be used interchangeably. This glossary should help to resolve such ambiguities.
 
 | Term             | Meaning                                                                                                                                                                                                                    |
 | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

website/versioned_docs/version-v1.x/contracts.md

@@ -235,7 +235,7 @@ function mergeMaciStateAqSubRoots(uint256 _numSrQueueOps, uint256 _pollId)
     }
 ```
 
-If the subtrees have not been merged on the MACI contract's `stateAq`, then it will merge it by calling `mergeStateAqSubroots`. It accets two parameters:
+If the subtrees have not been merged on the MACI contract's `stateAq`, then it will merge it by calling `mergeStateAqSubroots`. It accepts two parameters:
 
 - `_numSrQueueOps` - the number of operations required
 - `_pollId` - the id of the poll

website/versioned_docs/version-v1.x/primitives.md

@@ -114,7 +114,7 @@ A verifying key is used to validate a zk-SNARK proof. Each unique permutation of
 
 #### Private Keys
 
-MACI's private keys allow users to send and decrypt messages. This key translates to a scalar point on the Baby Jubjub ellpitic curve. All keys are serialized with the prefix `macisk`.
+MACI's private keys allow users to send and decrypt messages. This key translates to a scalar point on the Baby Jubjub elliptic curve. All keys are serialized with the prefix `macisk`.
 
 #### Public Keys
 
@@ -155,7 +155,7 @@ To decrypt a message using $k_s$ is expressed as
 
 $[p, R8[0], R8[1], cm_s]$ = ${poseidonDecrypt}(M, k_s[0], k_s[1], cm_n, 7)$
 
-To unpack $p$ to it's original five parameters, it must be seperated into 50 bit values from the parent 250 bit value. To extract 50 bits at byte $n$, we:
+To unpack $p$ to its original five parameters, it must be separated into 50 bit values from the parent 250 bit value. To extract 50 bits at byte $n$, we:
 
 1. initialise 50 bits
 2. shift left by $n$ bits