Fix typos in docs (#1077)

This fixes a couple of minor typos.

Author: ValarDragon

docs/lifecycle_of_a_transaction_technical.md

@@ -48,7 +48,7 @@ Check out [transaction_payload.mli](../src/lib/coda_base/transaction_payload.mli
 
 (TODO: @ihm can you correct any details I mess up here)
 
-We use [Schnorr signatures](https://en.wikipedia.org/wiki/Schnorr_signature). A [Schnorr signature](https://en.wikipedia.org/wiki/Schnorr_signature) is an element in a [group](https://en.wikipedia.org/wiki/Group_(mathematics). Our group is a point on an [eliptic curve](https://en.wikipedia.org/wiki/Elliptic_curve). So what is a signature? Open up [signature lib's checked.ml](../src/lib/signature_lib/checked.ml) and scroll to `module Signature` within `module type S`. It's a non-zero point on a curve, aka a pair of two `curve_scalar` values. To sign we give a [private key](#private-key) and a message, we can verify a signature on a message with a [public key](#public-key).
+We use [Schnorr signatures](https://en.wikipedia.org/wiki/Schnorr_signature). A [Schnorr signature](https://en.wikipedia.org/wiki/Schnorr_signature) is an element in a [group](https://en.wikipedia.org/wiki/Group_(mathematics). Our group is a point on an [elliptic curve](https://en.wikipedia.org/wiki/Elliptic_curve). So what is a signature? Open up [signature lib's checked.ml](../src/lib/signature_lib/checked.ml) and scroll to `module Signature` within `module type S`. It's a non-zero point on a curve, aka a pair of two `curve_scalar` values. To sign we give a [private key](#private-key) and a message, we can verify a signature on a message with a [public key](#public-key).
 
 This is the first time we see heavily functored code, so see [functors](style_guide.md#functors) if you're confused. This is also the first time we see custom SNARK circuit logic, see [custom SNARK circuit logic](style_guide.md#snark-checked) for more.
 
@@ -80,7 +80,7 @@ A transaction is valid if:
 
 1. The signature is valid w.r.t. the public key of the sender
 2. The sender has enough balance to pay out the fee and the amount
-3. The reciever has enough room for the amount s.t. there won't be an overflow
+3. The receiver has enough room for the amount s.t. there won't be an overflow
 4. The [account nonce](#account-nonce) matches the nonce inside the transaction.
 
 When we apply a transaction we also cons it onto the [receipt chain](#receipt-chain-hash), and increment the account nonce.
@@ -120,7 +120,7 @@ After a break, we'll be ready to dive into the daemon code.
 
 The coda daemon is defined inline in [coda.ml](../src/app/cli/src/coda.ml). Search for the `daemon` function to see the CLI flags we use there. The daemon is optionally auto-started by the client if it doesn't already exist. We get configuration from a JSON configuration file (try first from `-f`, then from `$XDG_CONFIG_DIR/coda/daemon.json`, then from `/etc/coda/daemon.json`). We do a lot of setup here which leads up to invoking `Coda_main.Coda.Make` and then `Run`ing it. The details of those are described below.
 
-When we have the `Run` modulle, we can make an instance of the coda daemon at the value level, and set up any background processes and services.
+When we have the `Run` module, we can make an instance of the coda daemon at the value level, and set up any background processes and services.
 
 <a name="main"></a>
 ## Main
@@ -194,10 +194,10 @@ A diff consists of
 
 There are two primary operations in ledger builder.
 1. Creating a diff :
-    To include a transaction from the transaction pool, the proposer needs to include snarks generated by its own snark-workers (or buy it from someone) which certifies some of the transactions added in previous blocks. The number of snarks needs to be twice the number of transaction being included in th block (an invariant of the aux data structure). These proofs are included in the diff along with the transactions and coinbase.
+    To include a transaction from the transaction pool, the proposer needs to include snarks generated by its own snark-workers (or buy it from someone) which certifies some of the transactions added in previous blocks. The number of snarks needs to be twice the number of transaction being included in the block (an invariant of the aux data structure). These proofs are included in the diff along with the transactions and coinbase.
     The diff is then included in the external transition and  broadcasted to the network.
 
-2. Applying a diff: Diffs from the node itself (Internal transitions) or form the network (External transitions) are then used to update the ledger builder by applying the transactions to the ledger and updating the parallel scan state with the proofs. Applying a diff may produce a proof for a sequence of transactions that were included in the previous blocks.
+2. Applying a diff: Diffs from the node itself (Internal transitions) or from the network (External transitions) are then used to update the ledger builder by applying the transactions to the ledger and updating the parallel scan state with the proofs. Applying a diff may produce a proof for a sequence of transactions that were included in the previous blocks.
 
 ## Ledger
 

src/lib/snarky/src/curves.ml

@@ -842,7 +842,7 @@ module Make_weierstrass_checked
     let sigma_count = (n + 1) / 2 in
     (* = ceil (n / 2.0) *)
     (* We implement a complicated optimzation so that in total
-       this costs roughly (1 + 3) * (n / 2) constaints, rather than
+       this costs roughly (1 + 3) * (n / 2) constraints, rather than
        the naive 4*n + 3*n. If scalars were represented with some
        kind of signed digit representation we could probably get it
        down to 2 * (n / 3) + 3 * (n / 3).