Update simple-scripts.md

Making some minor content edits.

doc/reference/simple-scripts.md

@@ -3,51 +3,51 @@
 From the Shelley era onwards, Cardano has supported scripts and script
 addresses.
 
-Cardano is designed to support multiple script languages, and most features
-relating to scripts work the same irrespective of the script language (or
+Cardano is designed to support multiple script languages, and most features that are
+related to scripts work the same irrespective of the script language (or
 version of a script language).
 
-The Shelly era supports just a single, very simple, script language. It can be
-used for multi-signature addresses. The Allegra era extended the simple script
+The Shelley era supports a single, simple script language, which can be
+used for multi-signature addresses. The Allegra era (token locking) extends the simple script
 language with a feature to make scripts conditional on time. This can be used
 to make addresss with so-called "time locks", where the funds cannot be
 withdrawn until after a certain point in time.
 
-The Alonzo era will add support for a whole new language script language:
+The Alonzo era will add support for a whole new script language:
 Plutus core.
 
-This reference covers only the existing simple script language.
+Please note that this reference covers only the existing simple script language.
 
 ## Script addresses
 
 In general, addresses (both payment addresses and stake addresses) specify the
 _authorisation conditions_ that must be met for the address to be used. For
-payment addresses that means the authorisation conditions for funds to be
-withdrawn. For stake addresses that means the authorisation conditions for
-setting a delegation choice or withdrawing rewards.
+payment addresses, this means the authorisation conditions for funds to be
+withdrawn. For stake addresses, this means the authorisation conditions for
+setting a delegation choice or rewards withdrawal.
 
-Both payment and stake addresses come in two flavours: single-key based or
-script based. The key-based addresses use a single cryptographic key per
+Both payment and stake addresses come in two flavours: *single-key based* or
+*script based*. The key-based addresses use a single cryptographic key per
 address. The authorisation condition to use the address is that one holds the
 secret (signing) part of the cryptographic key (for that address) and thus be
 able to make a cryptographic signature for that key.
 
 The script-based addresses use a script per address. The authorisation
 condition to use the address is that the _evaluation_ of the script for the
 address results in success. The script expresses the authorisation conditions
-and evaluation of the script tests if those conditions are met. For example, a
+and evaluation of script tests if those conditions are met. For example, a
 very simple script might express the condition that one holds a particular
 cryptographic signing key. The script would express that condition by testing
 if the transaction has a cryptographic signature from the appropriate
-cryptographic verification key. Such a script would of course be exactly
+cryptographic verification key. Such a script would, of course, be exactly
 equivalent to an ordinary single-key based address: the authorisation
-conditions would be the same! Thus we can see that single-key based address are
+conditions would be the same! Thus, we can see that single-key based addresses are
 in some sense just a (very common) special case and that script addresses are
 the general case.
 
 When using an address (payment or stake) in a transaction, the transaction must
 contain the information needed to show that the authorisation conditions for the
-use of the address are met. This information is known as a transaction witness.
+use of the address are met. This information is known as a *transaction witness*.
 We say that it _witnesses_ the validity of the transaction using the address.
 The addresses themselves have a _credential_ which is information sufficient to
 check that a witness is the right witness.
@@ -64,38 +64,38 @@ addresses:
 
 + **Script credential** - a script credential is the hash of the script.
 
-  The transaction witness for a script credential is the script itself. For the
-  very simple script language introduced in the Shelley era there are no other
-  inputs. Scripts in the Plutus language (once that is available) will require
+  The transaction witness for a script credential is the script itself. There are no 
+  other inputs for the very simple script language introduced in the Shelley era. 
+  Scripts in the Plutus language (once that is available) will require
   additional inputs which will also form part of the witness.
 
 ## Multi-signature scripts
 
 In Shelley and later eras, multisig scripts are used to make script addresses
 where the authorisation condition for a transaction to use that address is that
-the transaction have signatures from multiple cryptographic keys. Examples
+the transaction has signatures from multiple cryptographic keys. Examples
 include M of N schemes, where a transaction can be authorized if at least *M*
 distinct keys, from a set of *N* keys, sign the transaction.
 
 As with all scripts, the transaction witness for a multisig script address
 includes the script itself. The multisig language is so simple that this is
 the entire witness: there are no other script data inputs. Although the script
 itself is the witness, the script has _conditions_ that must be satisfied. The
-conditions for the multisig scripts are that the transaction has other ordinary
-key witnesses. Which combination of key witnesses are acceptable is of course
+conditions for multisig scripts are that the transaction has other ordinary
+key witnesses. Which combination of key witnesses are acceptable is, of course,
 determined by the script.
 
 The multisig script language is an expression language. Its scripts form an
 expression tree. The evaluation of the script produces either `true` or `false`.
 
-In BNF notation, the script expressions follow the following abstract syntax
+In BNF notation, the script expressions follow the following abstract syntax:
 ```
 <script> ::= <RequireSignature> <vkeyhash>
            | <RequireAllOf>     <script>*
            | <RequireAnyOf>     <script>*
            | <RequireMOf> <num> <script>*
 ```
-Note that is is of course recursive. There are no constraints on the nesting or
+Note that it is recursive. There are no constraints on the nesting or
 size, except that imposed by the overall transaction size limit (given that
 the script must be included in the transaction in a script witnesses).
 
@@ -105,7 +105,7 @@ In more detail, the four multisig constructors are:
 
   This expression evaluates to `true` if (and only if) the transaction also
   includes a valid key witness where the witness verification key hashes to the
-  given hash. In other words this checks that the transaction is signed by a
+  given hash. In other words, this checks that the transaction is signed by a
   particular key, identified by its verification key hash.
 
 + RequireAllOf: has a list of multisig sub-expressions.
@@ -128,11 +128,11 @@ In more detail, the four multisig constructors are:
 
 ## Time locking
 
-In the Allegra and later eras the simple multisig script language above is
-extended with two additional terms for expressing conditions on the time.
+In the Allegra and later eras, the simple multisig script language above is
+extended with two additional terms for expressing any time conditions.
 
 This extension can be used to make script addresses where it is not possible
-to spend from them until after a certain time. Or in combination with the
+to spend from them until after a certain time. Or, in combination with the
 existing features, one could make a script where up until a certain time one
 group of keys (perhaps M-of-N) is allowed to spend, but after a time another
 group of keys is allowed instead.
@@ -141,7 +141,7 @@ On the Cardano blockchain, time is expressed via slot numbers, since time slots
 correspond to time. The extra constructors allow expressing that the current
 time slot number must be before a certain slot, or after a certain slot.
 
-The BNF notation for the abstract syntax is
+The BNF notation for the abstract syntax is:
 ```
 <script> ::= <RequireSignature>  <vkeyhash>
            | <RequireTimeBefore> <slotno>
@@ -160,8 +160,8 @@ range of slots in which they are valid; the range of slots in which they may be
 included into blocks on the blockchain. The transaction can specify the first
 slot in which the transaction can become valid, and the first slot in which the
 transaction becomes invalid. This is a "half-open" interval: the lower bound is
-inclusive and the upper bound is exclusive. Both the lower and upper ends of
-this interval is optional, in which case the interpretation is zero or positive
+inclusive and the upper bound is exclusive. Both the lower and the upper ends of
+this interval are optional, in which case the interpretation is zero or positive
 infinity respectively.
 
 With this in mind, we can understand the interpretation of the new expressions:
@@ -185,7 +185,7 @@ With this in mind, we can understand the interpretation of the new expressions:
 One might reasonably wonder why use this two-stage check via the validity
 interval rather than more straightforwardly check the actual slot time. The
 reason is to give deterministic script evaluation, which becomes crucial for
-Plutus scripts. In this context by deterministic we mean that the result of the
+Plutus scripts. In this context, by *deterministic* we mean that the result of the
 script evaluation depends only on the transaction itself and not any other
 context or state of the system. This property is less crucial for this simple
 script language, but it is better if all the languages behave the same in this