[skip ci] deploy gh-pages

RFC-0385_StableCoins.html

@@ -353,9 +353,9 @@ <h3 id="key-assumptions-and-requirements"><a class="header" href="#key-assumptio
 <li>The <code>issuer</code> has the following &quot;administrator&quot; powers:
 <ol>
 <li>Create and authorise new accounts.</li>
-<li>Issue new tokens. The new tokens are credited to the <code>issuer</code>'s account. The transactions are i the clear so
+<li>Issue new tokens. The new tokens are credited to the <code>issuer</code>'s account. The transactions are in the clear so
 that anyone can verify the total circulating supply of the stablecoin.</li>
-<li>Redeem (burn) existing tokens. The burnt tokens are debited from the <code>issuer</code>'s account. These transactnios
+<li>Redeem (burn) existing tokens. The burnt tokens are debited from the <code>issuer</code>'s account. These transactions
 are in the clear.</li>
 <li>Have access to the full list of account ids.</li>
 <li>Blacklist an account. Blacklisted accounts are not allowed to send, or receive, tokens.</li>
@@ -385,7 +385,7 @@ <h3 id="key-assumptions-and-requirements"><a class="header" href="#key-assumptio
 <li>However, they <em>are</em> able to, and MUST verify that
 <ol>
 <li>no coins are created or destroyed in the transaction, i.e. the sum of the parties' balances before and after
-the transfer are equal.</li>
+the transfer are equal,</li>
 <li>the transfer value is positive,</li>
 <li>the sender has a positive balance after the transaction,</li>
 <li>the sender has authorised the transaction,</li>
@@ -395,7 +395,7 @@ <h3 id="key-assumptions-and-requirements"><a class="header" href="#key-assumptio
 <li>the receiving party is not on the blacklist.</li>
 </ol>
 </li>
-<li>If any of the conditions in 3 are not met, the transaction is invalid and the validator node MUST reject the
+<li>If any of the conditions in 2 are not met, the transaction is invalid and the validator node MUST reject the
 transaction.</li>
 </ol>
 <h2 id="implementation"><a class="header" href="#implementation">Implementation</a></h2>
@@ -408,9 +408,8 @@ <h2 id="implementation"><a class="header" href="#implementation">Implementation<
 <li>The issuer can carry out confidential transfers by first transferring tokens from the
 cleartext issuer account to another, standard account controlled by the issuer, and then performing a confidential
 transfer from there to the final destination account.</li>
-<li>Balances are stored in Pedersen commitments. The blinding factor is updated after every transaction and is a
-function of a shared secret between the account holder and the issuer, and a public nonce, that is stored in the
-account metadata.</li>
+<li>Balances are stored in Pedersen commitments, the masks of which are known only to account holders.</li>
+<li>Balances are also verifiably encrypted to the issuer.</li>
 <li>Users create a new account by interacting with the issuer. The issuer provides an account id that can be compared
 against a blacklist for the purposes of determining whether the account is valid or not. The issuer may choose to
 conduct a KYC procedure out-of-band as part of the account creation process.</li>
@@ -420,10 +419,6 @@ <h2 id="implementation"><a class="header" href="#implementation">Implementation<
 <li>Spending authority rests solely with the account owner and required knowledge of the account private key.</li>
 <li>Transfers are done in two-steps, via the issuance of an e-cheque by the sender, followed by the claiming of the
 e-cheque by the recipient.</li>
-<li>Issuers are able to view account balances by holding a shared encryption key with every user. This key is used to
-encrypt the memo field of the account. The issuer can decrypt the memo field and determine the value of the
-transfer. Every account also possesses an equivalence proof, which shows that the balance commitment is equal to
-the value in the memo field.</li>
 </ul>
 <p>The remainder of this section describes the implementation in more detail.</p>
 <div class="note">

print.html

@@ -10090,9 +10090,9 @@ <h3 id="key-assumptions-and-requirements"><a class="header" href="#key-assumptio
 <li>The <code>issuer</code> has the following &quot;administrator&quot; powers:
 <ol>
 <li>Create and authorise new accounts.</li>
-<li>Issue new tokens. The new tokens are credited to the <code>issuer</code>'s account. The transactions are i the clear so
+<li>Issue new tokens. The new tokens are credited to the <code>issuer</code>'s account. The transactions are in the clear so
 that anyone can verify the total circulating supply of the stablecoin.</li>
-<li>Redeem (burn) existing tokens. The burnt tokens are debited from the <code>issuer</code>'s account. These transactnios
+<li>Redeem (burn) existing tokens. The burnt tokens are debited from the <code>issuer</code>'s account. These transactions
 are in the clear.</li>
 <li>Have access to the full list of account ids.</li>
 <li>Blacklist an account. Blacklisted accounts are not allowed to send, or receive, tokens.</li>
@@ -10122,7 +10122,7 @@ <h3 id="key-assumptions-and-requirements"><a class="header" href="#key-assumptio
 <li>However, they <em>are</em> able to, and MUST verify that
 <ol>
 <li>no coins are created or destroyed in the transaction, i.e. the sum of the parties' balances before and after
-the transfer are equal.</li>
+the transfer are equal,</li>
 <li>the transfer value is positive,</li>
 <li>the sender has a positive balance after the transaction,</li>
 <li>the sender has authorised the transaction,</li>
@@ -10132,7 +10132,7 @@ <h3 id="key-assumptions-and-requirements"><a class="header" href="#key-assumptio
 <li>the receiving party is not on the blacklist.</li>
 </ol>
 </li>
-<li>If any of the conditions in 3 are not met, the transaction is invalid and the validator node MUST reject the
+<li>If any of the conditions in 2 are not met, the transaction is invalid and the validator node MUST reject the
 transaction.</li>
 </ol>
 <h2 id="implementation-1"><a class="header" href="#implementation-1">Implementation</a></h2>
@@ -10145,9 +10145,8 @@ <h2 id="implementation-1"><a class="header" href="#implementation-1">Implementat
 <li>The issuer can carry out confidential transfers by first transferring tokens from the
 cleartext issuer account to another, standard account controlled by the issuer, and then performing a confidential
 transfer from there to the final destination account.</li>
-<li>Balances are stored in Pedersen commitments. The blinding factor is updated after every transaction and is a
-function of a shared secret between the account holder and the issuer, and a public nonce, that is stored in the
-account metadata.</li>
+<li>Balances are stored in Pedersen commitments, the masks of which are known only to account holders.</li>
+<li>Balances are also verifiably encrypted to the issuer.</li>
 <li>Users create a new account by interacting with the issuer. The issuer provides an account id that can be compared
 against a blacklist for the purposes of determining whether the account is valid or not. The issuer may choose to
 conduct a KYC procedure out-of-band as part of the account creation process.</li>
@@ -10157,10 +10156,6 @@ <h2 id="implementation-1"><a class="header" href="#implementation-1">Implementat
 <li>Spending authority rests solely with the account owner and required knowledge of the account private key.</li>
 <li>Transfers are done in two-steps, via the issuance of an e-cheque by the sender, followed by the claiming of the
 e-cheque by the recipient.</li>
-<li>Issuers are able to view account balances by holding a shared encryption key with every user. This key is used to
-encrypt the memo field of the account. The issuer can decrypt the memo field and determine the value of the
-transfer. Every account also possesses an equivalence proof, which shows that the balance commitment is equal to
-the value in the memo field.</li>
 </ul>
 <p>The remainder of this section describes the implementation in more detail.</p>
 <div class="note">