Update README.md

README.md

@@ -7,25 +7,25 @@ There are only two main state elements in the secret contract.
 They use three types for their keys and values: authOut, ref and u__.
 (we may change the name of authOut as it is confusing)
 
-##### balances
+##### `balances`
  A mapping from each user's authOout to their balance (u___)
 
-##### paymentRefs
+##### `paymentRefs`
  A mapping from every payment ref that every user has created, to the authOut of the user that created it.
 
-###### the ref type
+###### the `ref` type
  This may be extended in future work. 
 
  The underlying type should be something we can compare easily in secret contracts. For simpilcity we should limit it to 32 bytes. I propose string (but if something else is easier, we could choose any 32 byte type and cast it in Solidity and the frontend).
 
-###### the authOut type
+###### the `authOut` type
  will be exentded in future work to include different types of auth.
- for now, an authOut will represent a password. The password does not even need to be encrypted since it will be encypted for transport from the frontend, and encrypted in storage in the secret contract transparenty due to the TEE.
+ for now, an `authOut` will represent a password. The password does not even need to be encrypted since it will be encypted for transport from the frontend, and encrypted in storage in the secret contract transparently due to the TEE.
  However, for appearances sake, it would be nice to encrypt it ourselves in storage, 
- Therefore the type of authOut could be string, but may be better being bytes32 - so that we can cast various different types of auth into it now and later.
+ Therefore the type of `authOut` could be `string`, but may be better being `bytes32` - so that we can cast various different types of auth into it now and later.
 
 ###### the balances type
- is not even its own type, will jus tbe an unsigned integer. u32 is overkill, but it is also standard for balances so we may as well use it.
+ is not even its own type, will just be an unsigned integer. `u32` is overkill, but it is also standard for balances so we may as well use it.
 
 
 #### secondary state elements
@@ -45,16 +45,16 @@ They use three types for their keys and values: authOut, ref and u__.
 
 #### types used for input output but not stored in state
 
-##### address
+##### `address`
  will be accepted  by withdrawTo function
 
-##### pubkey / Option(pubkey)
+##### `pubkey` / `Option(pubkey)`
 
-secp1k256 - allows a sender of funds who wants a receipt to receive that receipt encrypted with their pubkey
+secp1k256 - allows a sender of funds who wants a receipt to (optionally) receive that receipt encrypted with their pubkey
 
 ##### messaging types used by secret contracts
- such as handle, which specifies which function is being called.
- I have not looke dintoi these in detail
+ such as `handle`, which specifies which function is being called.
+ I have not looked into these in detail
 
 
 
@@ -68,8 +68,8 @@ We do not use usernames. We can, as future work, modularly update authOut so tha
 
 ##### aprovals, permissions, roles
 There are no approvals, permissions or roles.
-The only fucntion that requires any authentication is withdrawTo, and the authentiaction is solely on the bassin if the authOut. If the user provides the correct authOut to map to a blanace, then they have full control of the whole of the balance.
+The only fucntion that requires any authentication is `withdrawTo`, and the authentication is solely on the basis of the `authOut` provided when calling that function. If the user provides the correct `authOut` to map to a `balance`, then they have full control of the whole of the balance.
 
 
 
-
+