deploy: 61900ff303

print.html

@@ -207,7 +207,7 @@ We denote: <code>x = Poseidon(message), and y = A(x)</code>. </p>
 <p>Thus, if the same epoch user sends more than one message, their polynomial and, therefore, their secret (<code>a_0</code>) can be recovered.</p>
 <p>Of course, we somehow must prove that our <code>share = (x, y)</code> is valid (that this is really a point on our <code>polynomial = A(x)</code>), as well as we must prove other things are valid too, that's why we use zkSNARK. An explanation of the zk-circuits can be found in the next topic.</p>
 <h2 id="slashing"><a class="header" href="#slashing">Slashing</a></h2>
-<p>As it's been said, if a user sends more than one message, everyone else will be able to recover his secret, slash him and take his stake.</p>
+<p>As it's been said, if a user sends more than one message, everyone else will be able to recover his secret, slash them and take their stake.</p>
 <h2 id="some-important-notes"><a class="header" href="#some-important-notes">Some important notes</a></h2>
 <p>There are also <code>nullifier</code> and <code>rln_identifier</code>, which can be found in the <strong>RLN</strong> protocol/circuits.</p>
 <p>So, <code>rln_identifier</code> is just a random value that's unique per <strong>RLN</strong> app. It's used for additional cross-application security - to protect the user secrets from being compromised if they use the same credentials across different <strong>RLN</strong> apps. If <code>rln_identifier</code> is not present, the user uses the same credentials and sends a message in two different <strong>RLN</strong> apps using the same epoch, then their secret key can be revealed. Adding the <code>rln_identifier</code> field, we obscure the nullifier, so this kind of attack cannot happen. The only kind of attack that is possible is if we have an entity with a global view of all messages, and they try to brute-force different combinations of x and y shares for different nullifiers.</p>

protocol_spec.html

@@ -159,7 +159,7 @@ We denote: <code>x = Poseidon(message), and y = A(x)</code>. </p>
 <p>Thus, if the same epoch user sends more than one message, their polynomial and, therefore, their secret (<code>a_0</code>) can be recovered.</p>
 <p>Of course, we somehow must prove that our <code>share = (x, y)</code> is valid (that this is really a point on our <code>polynomial = A(x)</code>), as well as we must prove other things are valid too, that's why we use zkSNARK. An explanation of the zk-circuits can be found in the next topic.</p>
 <h2 id="slashing"><a class="header" href="#slashing">Slashing</a></h2>
-<p>As it's been said, if a user sends more than one message, everyone else will be able to recover his secret, slash him and take his stake.</p>
+<p>As it's been said, if a user sends more than one message, everyone else will be able to recover his secret, slash them and take their stake.</p>
 <h2 id="some-important-notes"><a class="header" href="#some-important-notes">Some important notes</a></h2>
 <p>There are also <code>nullifier</code> and <code>rln_identifier</code>, which can be found in the <strong>RLN</strong> protocol/circuits.</p>
 <p>So, <code>rln_identifier</code> is just a random value that's unique per <strong>RLN</strong> app. It's used for additional cross-application security - to protect the user secrets from being compromised if they use the same credentials across different <strong>RLN</strong> apps. If <code>rln_identifier</code> is not present, the user uses the same credentials and sends a message in two different <strong>RLN</strong> apps using the same epoch, then their secret key can be revealed. Adding the <code>rln_identifier</code> field, we obscure the nullifier, so this kind of attack cannot happen. The only kind of attack that is possible is if we have an entity with a global view of all messages, and they try to brute-force different combinations of x and y shares for different nullifiers.</p>