Specify client_ttl details in name entry (#528)

* Specify `client_ttl` details in name entry

* Fix typos

AENS.md

@@ -153,11 +153,11 @@ state. This value MUST NOT be further than 180000 blocks (Note: used to be
 50000 before Iris protocol upgrade) into the future.
 
 ***client_ttl***: a suggestion as to how long any clients should
-cache this information. (***TODO***: should have a reasonable
+cache pointers. Measured in seconds. (***TODO***: should have a reasonable
 upper limit, e.g. 86400 seconds, and probably a different
 name to not be confused with the general TTL for transactions)
 
-This entry is only relevant for clients and has no conensus
+This entry is only relevant for clients and has no consensus
 impact.
 
 ***pointers***: a dictionary with all the values this entry
@@ -229,9 +229,9 @@ to commit to a name and after the commitment has been accepted into the
 chain, reveal the name to finish the process.
 
 A commitment should be binding, i.e. the claimant cannot change
-the value they commited to without changing the actual commitment
+the value they committed to without changing the actual commitment
 and hiding, so that a malicious miner learns nothing about the value
-the claimant has commited until they chose to reveal that value. This
+the claimant has committed until they chose to reveal that value. This
 prevents malicious miners from front running, i.e. upon seeing a
 claim transaction, including their own claim request for the same
 name instead of the original claimant's one.
@@ -534,7 +534,7 @@ From Ceres hardfork, a new pointer target type is introduced:
 ```
 
 The `transfer` transaction MUST be signed by the owner
-of the name entry to be transfered.
+of the name entry to be transferred.
 
 
 ### Revoke
@@ -588,7 +588,7 @@ give the name to.
 These sub-labels allow for further customisation and also for users to
 associate with particular namespaces, e.g. a cryptographic cat breeding
 game might associate a name entry with every of its cats such as
-`unicorn.kitty.test` and then transfering that name to the person, who
+`unicorn.kitty.test` and then transferring that name to the person, who
 adopts the cat. The authorization policies for these will need some
 flexibility seeing as the owner of a namespace might want to prevent
 or allow users creating sub-sub-labels, e.g. the owner of `unicorn.kitty.test`

GOSSIP.md

@@ -162,9 +162,9 @@ attack where most of the good peers are unreachable augmenting the probability
 of only hostile node getting selected.
 
 If a peer changes its IP address but not its key, the new address will **never**
-be updated through gossip. This is to prevent an hostil node from gossiping
+be updated through gossip. This is to prevent a hostile node from gossiping
 bad addresses for known good nodes and making them unreachable. The peer will be
-removed after the normal retry policy is exausted; then the new address will be
+removed after the normal retry policy is exhausted; then the new address will be
 added through the usual gossip exchanges.
 
 The peer retry counter and last retry time (initialized to '0' and 'infinity'),

channels/OFF-CHAIN.md

@@ -705,7 +705,7 @@ Message code: 12
 This is an acknowledgement of a preceding `deposit_created` message (see
 above). Upon receipt of a mutually authenticated state, the receiver verifies
 that it is indeed the state resulting from the proposed deposit operation. The
-`channel_deposit_tx` is then pushed to the chain, and the requisit number of
+`channel_deposit_tx` is then pushed to the chain, and the requested number of
 confirmations (`minimum_depth`) are awaited. Once confirmation has been
 received, a `deposit_locked` message is sent, with the hash of the
 `channel_deposit_tx` transaction.
@@ -807,7 +807,7 @@ Message code: 16
 This is an acknowledgement of a preceding `withdraw_created` message (see
 above). Upon receipt of a mutually authenticated state, the receiver verifies
 that it is indeed the state resulting from the proposed withdrawal operation.
-The `channel_withdraw_tx` is then pushed to the chain, and the requisit number
+The `channel_withdraw_tx` is then pushed to the chain, and the requested number
 of confirmations (`minimum_depth`) are awaited. Once confirmation has been
 received, a `withdraw_locked` message is sent, with the hash of the
 `channel_withdraw_tx` transaction.

channels/ON-CHAIN.md

@@ -118,7 +118,7 @@ account](../generalized_accounts/README.md) the channel create
 will also create an extra entry in the contract state tree, containing a frozen
 authentication state that will be used for off-chain authentication and
 verification in off-chain updates (potentially eventually enforced on-chain)
-of this particular channel.  A more detailed explaination can be found
+of this particular channel.  A more detailed explanation can be found
 [here](./authentication.md)
 
 #### Requirements
@@ -211,7 +211,7 @@ Serialization defined [here](../serializations.md#channel-withdraw-transaction)
 
 The `to` account MUST be a participant in the target channel. The `amount`
 MUST be less than or equal to the sum of the channel balance with regard to the
-`channel_reserve` ammounts, i.e. channels cannot create coins out of thin air
+`channel_reserve` amounts, i.e. channels cannot create coins out of thin air
 but also a minimum of `channel_reserve` must remain locked in the channel. The
 fee is paid by the `to` account and that account should hold enough coins to
 pay the fee, i.e., the fee is subtracted before the withdrawn coins arrive.
@@ -270,7 +270,7 @@ If this transaction is valid then it sets:
 ### `channel_set_delegates`
 
 In order to make channels both secure and trustless even when one party goes
-offline, a participant can deleate the right to produce certain transactions
+offline, a participant can delegate the right to produce certain transactions
 to other third parties.
 Delegates are set initially in the `channel_create_tx` and, since the `iris`
 hardfork, can be updated with `channel_set_delegates_tx`. It acts similarly to
@@ -375,7 +375,7 @@ considered closed and allow no further modifications. The on-chain persisted
 channel object is removed from the on-chain state trees.
 
 `channel total >=
-  transcation initiator_amount_final + responder_amount_final + fee`
+  transaction initiator_amount_final + responder_amount_final + fee`
 
 
 ### `channel_close_solo`

channels/authentication.md

@@ -13,7 +13,7 @@ different implications this has on channels.
 We express consent in a provable and a cryptographically safe manner. From now
 on we will call it authentication. In the context of channels we can have
 both unilateral and mutual authentication, depending if just one or the two
-parties had expressed their consent. Assumption is if both parties agreeed
+parties had expressed their consent. Assumption is if both parties agreed
 upon a transaction, it had been valid at least at some point of time.
 
 ### Basic and generalized methods
@@ -30,7 +30,7 @@ Currently there are two different authentication methods:
   being used instead of private key. This smart contract has a state and it is
   updated by on-chain transactions. It is not updated by off-chain ones but
   since the authentication method MUST be valid in the future, a static
-  version of the authentication method is used. More detailed explaination for
+  version of the authentication method is used. More detailed explanation for
   Generalized Accounts can be found [here](../generalized_accounts/README.md).
 
 Since a participant can upgrade their account from a `basic` to `generalized`
@@ -48,7 +48,7 @@ using the private key.
 
 #### Participant upgrades their account after channel creation
 
-If a participant upgades their account after the `channel_create_tx` is being
+If a participant upgrades their account after the `channel_create_tx` is being
 included, one MUST use the new authentication method for all on-chain
 transactions. Off-chain on the other hand are signed as if the account is
 being `basic`, as it was at channel creation time.

channels/state.md

@@ -60,9 +60,9 @@ time:
 * `round` is being used to order different channel states - the greater the
   `round`, the newer the state
 
-* `state_hash` is the root of the State Channel's MPTree of MPTerees
+* `state_hash` is the root of the State Channel's MPTree of MPTrees
 
-A transaction that has all three defines the channnel's state at a certain
+A transaction that has all three defines the channel's state at a certain
 point of time. This is only valid when this transaction is authenticated by
 both participants. The only exception is the `channel_force_progress_tx` that
 has all three elements but is unilaterally authenticated. It is worth noting

consensus/README.md

@@ -210,8 +210,8 @@ PROTOCOL_VERSION: 2 (Minerva release) or greater
 ```
 
 - an optional info field is added to the key header
-- the presense of the info field MUST be marked by setting the info field flag to 1
-- the absense of the info field MUST be marked by setting the info field flag to 0
+- the presence of the info field MUST be marked by setting the info field flag to 1
+- the absence of the info field MUST be marked by setting the info field flag to 0
 - the info field, if present, is uninterpreted, but included in the block hash (i,e., it is under consensus).
 
 Block/header [serialization format](../serializations.md#key-blockheader)
@@ -275,7 +275,7 @@ Each (on-chain) transaction has the following fields:
 *Note*: There is also a node configurable minimum gas price - this is the
 minimum gas price a node accepts and is not under consensus. This value is
 higher than or equal to the minimal gas price as dictated by consensus. For
-contract transactions (Create, Call, GAAttach, GAMeta), the minumum applies to
+contract transactions (Create, Call, GAAttach, GAMeta), the minimum applies to
 both the `Fee` and the `GasPrice`.
 
 #### Spend transaction
@@ -331,7 +331,7 @@ Please refer to the [dedicated document](../AENS.md).
 
 Please refer to the [dedicated document](../channels/ON-CHAIN.md).
 
-#### Generalized account attach transation
+#### Generalized account attach transaction
 
 Please refer to the [dedicated document](../generalized_accounts/README.md).
 
@@ -405,7 +405,7 @@ algorithm. Solutions take the form of arrays length `l`, where `l` is the length
 (`PROOFSIZE`) of the cycle in the bipartite graph. The size of the graph is denoted
 by [`the 2-log of the graph size, which is the size in bits of the node identifiers`](https://github.com/tromp/cuckoo/blob/488c03f5dbbfdac6d2d3a7e1d0746c9a7dafc48f/src/cuckoo.h#L11) `EDGEBITS`. The difficulty
 of a graph with `M` nodes and `N` edges is based on the ratio `M/N`, with the standard
-implementation being fixed at `M/N = 1/2`. Please refer to the [whitepaper](https://github.com/tromp/cuckoo/blob/master/doc/cuckoo.pdf?raw=true) for more details. These indices are refered to as `micrononces`, not
+implementation being fixed at `M/N = 1/2`. Please refer to the [whitepaper](https://github.com/tromp/cuckoo/blob/master/doc/cuckoo.pdf?raw=true) for more details. These indices are referred to as `micrononces`, not
 to be confused with the nonce included in the header itself.
 This graph is generated by hashing every edge `i in (0..N)` twice with a keyed hash
 function `h` ([SipHash](https://131002.net/siphash/)). The `key` used for these operations

consensus/locking.md

@@ -4,5 +4,5 @@ We want a predictable inflation so there MUST not be any coin burning. In order
 to achieve this whenever there is a need for coins burning, we are locking
 those excess coins. This leads to a deterministic total amount of coins and
 thus - to a predictable inflation. This works as sending all to be locked
-coins to a predifined address that nobody has a private key for. Those coins
+coins to a predefined address that nobody has a private key for. Those coins
 are unspendable at this point.

contracts/contract_state_tree.md

@@ -70,5 +70,5 @@ correlate the call with the transaction in the block that did the
 call.
 
 The call object in the state tree contains the return value of a contract call transaction.
-For the contract create transaction the return value of the inital call is set to
+For the contract create transaction the return value of the initial call is set to
 the empty byte array.

contracts/fate.md

@@ -483,8 +483,8 @@ Writing to the accumulator pushes a value to the stack.
 | `CALLER` | Arg0 | Arg0 := The address that signed the call transaction. | {} | address | `FATE_01` |
 | `BLOCKHASH` | Arg0 Arg1 | Arg0 := The blockhash at height. | {integer} | variant | `FATE_01` |
 | `BENEFICIARY` | Arg0 | Arg0 := The address of the current beneficiary. | {} | address | `FATE_01` |
-| `TIMESTAMP` | Arg0 | Arg0 := The current timestamp. Unrelaiable, don't use for anything. | {} | integer | `FATE_01` |
-| `GENERATION` | Arg0 | Arg0 := The block height of the cureent generation. | {} | integer | `FATE_01` |
+| `TIMESTAMP` | Arg0 | Arg0 := The current timestamp. Unreliable, don't use for anything. | {} | integer | `FATE_01` |
+| `GENERATION` | Arg0 | Arg0 := The block height of the current generation. | {} | integer | `FATE_01` |
 | `MICROBLOCK` | Arg0 | Arg0 := The current micro block number. | {} | integer | `FATE_01` |
 | `DIFFICULTY` | Arg0 | Arg0 := The current difficulty. | {} | integer | `FATE_01` |
 | `GASLIMIT` | Arg0 | Arg0 := The current gaslimit. | {} | integer | `FATE_01` |

generalized_accounts/ga_explained.md

@@ -17,7 +17,7 @@ For plain old accounts (POA) transaction integrity comes down to two things;
 (1) the origin of the transaction - only the owner of an account may produce
 transactions originating from the account, and (2) a transaction can only be
 included once - i.e. it is not possible to include the same SpendTx twice to
-get double payment. (1) is achieved by [crypotographic
+get double payment. (1) is achieved by [cryptographic
 signing](https://en.wikipedia.org/wiki/Digital_signature), æternity uses
 [EdDSA](https://en.wikipedia.org/wiki/EdDSA) signatures with
 ([Curve25519](https://en.wikipedia.org/wiki/Curve25519)). (2) is normally
@@ -99,7 +99,7 @@ used to sign this hash.
 ### Caveat - producing the right hash
 
 It is trivial to produce the hash in the contract, `Crypto.blake2b((h, n))` -
-but it is not as straigthforward to do it _outside_ the contract. After all it
+but it is not as straightforward to do it _outside_ the contract. After all it
 is the Sophia ABI encoded tuple of a hash and an integer that is hashed. It
 isn't impossible to figure this out, but there is an easier way... *Protip:*
 Using the `dry-run` functionality we can call the contract off-chain and use
@@ -136,4 +136,4 @@ contract PayForExample =
 ```
 
 Note: in a realistic use-case it is probably advisable to have an admin
-interface so that you can add (and remore) allowed users later on, etc.
+interface so that you can add (and remove) allowed users later on, etc.

node/api/README.md

@@ -62,7 +62,7 @@ Channels provide means for off-chain transactions with functionality of
 on-chain dispute resolution.  Channels require persisted connections to
 æternity nodes. Each participant in a channel uses one's own trusted node. For
 persistence of this connection, WebSockets are used.  Channels have on-chain
-state that persists who the participants are and the total amout of coins put
+state that persists who the participants are and the total amount of coins put
 into the channel.  Each channel also has an off-chain state representing the
 latest distribution of the balance of the channel. It can be updated - each new
 state is co-signed by both parties and only then it becomes the latest valid

node/api/channel_ws_api.md

@@ -87,7 +87,7 @@ Roles:
 }
 ```
 
-### Sender authenticates off-chain state responsse
+### Sender authenticates off-chain state response
 
  * **method:** `channels.update`
  * **params:**

node/api/channels_api_usage.md

@@ -137,7 +137,7 @@ off-chain consensus being dependent on it could lead to a fragile system with
 a lot of mismatching state hashes of off-chain updates. In order to improve
 this there is an optional functionality of setting `block_hash` that defines
 the on-chain environment that the update is to be executed in. We call this
-shared view of the chain _a pinnned environment_. When a participant wants to
+shared view of the chain _a pinned environment_. When a participant wants to
 start a new round of updates, one can optionally specify a pinned environment
 to execute in. This is how the participant communicates to the other party
 what one considers to be a block hash that is safe enough to base an off-chain
@@ -161,7 +161,7 @@ In order to use a channel, it must be opened. Both parties negotiate parameters
 
 ### Websocket protocol
 
-The channel websocket api currently supports one protocol: [`json-rpc`](https://www.jsonrpc.org/specification). `legacy` protocol was removed. Choosen protocol has to be specified with the `protocol` option.
+The channel websocket api currently supports one protocol: [`json-rpc`](https://www.jsonrpc.org/specification). `legacy` protocol was removed. Chosen protocol has to be specified with the `protocol` option.
 
 In the examples below, the `json-rpc` protocol is used.
 
@@ -487,7 +487,7 @@ be known, the `fsm_id` is also included for convenience.
 #### Authenticated channel_create_tx
 The responder FSM reports to its client that it received the authentication
 reply, and now has a co-authenticated `channel_create_tx`. It relies on the
-initiator to push the co-authenticed transaction to the mempool:
+initiator to push the co-authenticated transaction to the mempool:
 
 ```javascript
 {
@@ -533,7 +533,7 @@ a `channel_changed` event in an `on_chain_tx` report:
 }
 ```
 
-### Mininum-depth confirmation
+### Minimum-depth confirmation
 A block height timer is started and it ends after `minimum_depth + 1` confirmations. Default value for
 it is 4, so 5 blocks need to be mined. As a result, each party will receive
 two kinds of confirmation.

node/api/contract_api_usage.md

@@ -50,7 +50,7 @@ TODO => http compiler & other tools
 TODO => http compiler & other tools
 
 ### Call
-TODO stil relevant?
+TODO still relevant?
 
 ### Dry-run
 [/debug/transactions/dry-run](https://api-docs.aeternity.io#/internal/DryRunTxs)

oracles/oracle_life_cycle.md

@@ -30,7 +30,7 @@ the chain.
 Bob pays a fee for submitting the transaction. The fee is collected by
 the miner.
 
-Bob pays a fee posting a query to the oracle. The fee is transfered to
+Bob pays a fee posting a query to the oracle. The fee is transferred to
 the oracle's account.
 
 The query transaction contains:

oracles/oracle_transactions.md

@@ -84,7 +84,7 @@ transaction, signing it with the oracle account's private key.
 The response transaction is invalid if the TTL from the query has
 expired.
 
-The oracle pays the fee of the response transaction. The mininimum fee
+The oracle pays the fee of the response transaction. The minimum fee
 is determined by the response TTL from the query and the size of the
 response.
 

serializations.md

@@ -404,7 +404,7 @@ object (to which tag and version need to be prepended) are:
 , <code>       :: binary()
 , <log>        :: binary(),
 , <active>     :: bool(),
-, <referers>   :: [id()],
+, <referrers>  :: [id()],
 , <deposit>    :: int()
 ]
 ```
@@ -1187,7 +1187,7 @@ FATE contracts uses a recursive BNF like definition.
 There are serialisations (RLP, FATE), sequences of serializations (`S1, S2, ...`),
 sequences of bytes (`<< .... >>`) and sequences of bits (`<<< ... >>>`).
 
-Fate Code uses both RLP enodings and pure byte arrays (or binary) encodings.
+Fate Code uses both RLP encodings and pure byte arrays (or binary) encodings.
 In the description here we write `RLP(X)` for the RLP encoding of `X`, where
 X is a name of an encoding described above or below in the description of
 the FATE encoding. We write `<X, Y>` for a byte array made of the sequence of
@@ -1648,7 +1648,7 @@ ListElements ::=
 The function map_size gives the number of key value pairs in the map.
 The key value pairs are serialized in key order with the smallest
 key in the order given by the FATE data order. Each pair is
-serialized toghether, first the key and then the value.
+serialized together, first the key and then the value.
 
 There must not be any duplicate keys in the map.