diff --git a/content/cryptography/addresses/slides.md b/content/cryptography/addresses/slides.md
index 87e56c1..44ba6c0 100644
--- a/content/cryptography/addresses/slides.md
+++ b/content/cryptography/addresses/slides.md
@@ -57,6 +57,8 @@ Notes:
 
 It turns out that converting from hex/base64 to base58 can in theory take n^2 time!
 
+The number of bits of a character is log2(Base) so for base58 it is log2(58) ~ 5.8
+
 ---
 
 # Mnemonics and Seed Creation
@@ -114,11 +116,9 @@ _The first 5 words of the [BIP39 English dictionary](https://github.com/bitcoin/
 
 ## Mnemonic to Secret Key
 
-Of course, the secret key is a point on an elliptic curve, not a phrase.
-
-BIP39 applies 2,048 rounds of the SHA-512 hash function<br />to the mnemonic to derive a 64 byte key.
+The secret key is a scalar value from the scalar field of the base field which the elliptic curve is defined over. Not a phrase.
 
-Substrate uses the entropy byte array from the mnemonic.
+BIP39 applies 2,048 rounds of the SHA-512 hash function<br /> to the mnemonic to derive a 64 byte key.
 
 ---
 
@@ -126,6 +126,9 @@ Substrate uses the entropy byte array from the mnemonic.
 
 Different key derivation functions affect the ability to use the same mnemonic in multiple wallets as different wallets may use different functions to derive the secret from the mnemonic.
 
+Notes:
+i.e. May hash to a different base field because of a different elliptic curve
+
 ---
 
 ## Cryptography Types
@@ -140,7 +143,14 @@ We will go more in depth in future lectures!
 
 Notes:
 
+These are digital signature schemes. ECDSA can use any elliptic curve but
+in the case of bitcoin it use secp256k1
+
+Sr25519 and Ed25519 uses the same which is Curve25519
+
 You may have learned RSA in school. It is outdated now, and requires _huge_ keys.
+RSA-4096: A 4096-bit RSA key is 512 bytes
+sr25519 is 32 bytes
 
 ---
 
@@ -150,6 +160,9 @@ An address is a representation of a public key, potentially with additional cont
 
 Notes:
 
+A public key is a point on a defined elliptic curve more specifically
+the secret scalar value multiplied times a fixed base point on some curve G
+
 Having an address for a symmetric cryptography doesn't actually make any sense, because there is no
 public information about a symmetric key.
 
diff --git a/content/cryptography/basic-signatures/slides.md b/content/cryptography/basic-signatures/slides.md
index 429aa95..e07cae6 100644
--- a/content/cryptography/basic-signatures/slides.md
+++ b/content/cryptography/basic-signatures/slides.md
@@ -12,10 +12,12 @@ duration: 1 hour
 
 Signature libraries should generally all expose some basic functions:
 
-- `fn generate_key(r) -> sk;` <br /> Generate a `sk` (secret key) from some input `r`.
-- `fn public_key(sk) -> pk;` <br /> Return the `pk` (public key) from a `sk`.
-- `fn sign(sk, msg) -> signature;` <br /> Takes `sk` and a message; returns a digital signature.
-- `fn verify(pk, msg, signature) -> bool;` <br /> For the inputs `pk`, a message, and a signature; returns whether the signature is valid.
+<ul>
+<li class="fragment"><code>fn generate_key(r) -> sk;</code> <br />Generate a <code>sk</code> (secret key) from some input <code>r</code>.</li>
+<li class="fragment"><code>fn public_key(sk) -> pk;</code> <br /> Return the <code>pk</code> (public key) from a <code>sk</code>.</li>
+<li class="fragment"><code>fn sign(sk, msg) -> signature;</code> <br /> Takes <code>sk</code> and a message; returns a digital signature.</li>
+<li class="fragment"><code>fn verify(pk, msg, signature) -> bool;</code> <br /> For the inputs <code>pk</code>, a message, and a signature; returns whether the signature is valid.</li>
+</ul>
 
 Notes:
 
@@ -72,10 +74,12 @@ This means the verifier will need to run the correct hash function on the messag
 
 Signatures provide many useful properties:
 
-- Confidentiality: Weak, the same as a hash
-- Authenticity: Yes
-- Integrity: Yes
-- Non-repudiation: Yes
+<ul>
+<li class="fragment"><strong>Confidentiality: </strong> Weak, the same as a hash</li>
+<li class="fragment"><strong>Authenticity: </strong> Yes</li>
+<li class="fragment"><strong>Integrity: </strong> Yes</li>
+<li class="fragment"><strong>Non-repudiation: </strong> Yes</li>
+</ul>
 
 Notes:
 
@@ -85,10 +89,11 @@ If a hash is signed, you can prove a signature is valid _without_ telling anyone
 
 ## Signing Payloads
 
-Signing payloads are an important part of system design.<br />
-Users should have credible expectations about how their messages are used.
-
-For example, when a user authorizes a transfer,<br />they almost always mean just one time.
+<ul>
+<li class="fragment">Signing payloads are an important part of system design.</li>
+<li class="fragment">Users should have credible expectations about how their messages are used.</li>
+<li class="fragment">For example, when a user authorizes a transfer, they almost always mean just one time.</li>
+</ul>
 
 Notes:
 
@@ -135,9 +140,11 @@ Examples:
 
 <pba-flex center>
 
-- Monotonically increasing account nonces
-- Timestamps (or previous blocks)
-- Context identifiers like genesis hash and spec versions
+<ul>
+<li class="fragment">Monotonically increasing account nonces</li>
+<li class="fragment">Timestamps (or previous blocks)</li>
+<li class="fragment">Context identifiers like genesis hash and spec versions</li>
+</ul>
 
 ---
 
@@ -147,18 +154,22 @@ Examples:
 
 ## ECDSA
 
-- Uses Secp256k1 elliptic curve.
-- ECDSA (used initially in Bitcoin/Ethereum) was developed to work around the patent on Schnorr signatures.
-- ECDSA complicates more advanced cryptographic techniques, like threshold signatures.
-- Nondeterministic
+<ul>
+<li class="fragment">Commonly uses Secp256k1 elliptic curve.</li>
+<li class="fragment">ECDSA (used initially in Bitcoin/Ethereum) was developed to work around the patent on Schnorr signatures.</li>
+<li class="fragment">ECDSA complicates more advanced cryptographic techniques, like threshold signatures.</li>
+<li class="fragment">Non-Deterministic</li>
+</ul>
 
 ---
 
 ## Ed25519
 
-- Schnorr signature designed to reduce mistakes in implementation and usage in classical applications, like TLS certificates.
-- Signing is 20-30x faster than ECDSA signatures.
-- Deterministic
+<ul>
+<li class="fragment">Schnorr signature designed to reduce mistakes in implementation and usage in classical applications, like TLS certificates.</li>
+<li class="fragment">Signing is 20-30x faster than ECDSA signatures.</li>
+<li class="fragment">Deterministic</li>
+</ul>
 
 ---
 
diff --git a/content/cryptography/hash-based-data-structures/slides.md b/content/cryptography/hash-based-data-structures/slides.md
index e7611af..4b96410 100644
--- a/content/cryptography/hash-based-data-structures/slides.md
+++ b/content/cryptography/hash-based-data-structures/slides.md
@@ -34,18 +34,15 @@ Each block has the hash of the previous one.
 
 A binary Merkle tree is a binary tree using hashes to connect nodes.
 
-Notes:
-
-Ralph Merkle is a Berkeley alum!
-
 ---
 
 ## Proofs
 
-- The root or head hash is a commitment to the entire data structure.
-- Generate a proof by expanding some but not all hashes.
-
-_Crucial for the trustless nature of decentralised cryptographic data systems!_
+<ul>
+<li class="fragment">The root or head hash is a commitment to the entire data structure.</li>
+<li class="fragment">Generate a proof by expanding some but not all hashes.</li>
+<li class="fragment"><i>Crucial for the trustless nature of decentralised cryptographic data systems!</i></li>
+</ul>
 
 ---
 
diff --git a/content/cryptography/hashes/slides.md b/content/cryptography/hashes/slides.md
index a5b3a22..4d90b7d 100644
--- a/content/cryptography/hashes/slides.md
+++ b/content/cryptography/hashes/slides.md
@@ -20,12 +20,15 @@ We often want a succinct representation of some data<br />with the expectation t
 
 <pba-flex center>
 
-1. Accept unbounded size input
-1. Map to a bounded output
-1. Be fast to compute
-1. Be computable strictly one-way<br />(difficult to find a pre-image for a hash)
-1. Resist pre-image attacks<br />(attacker controls one input)
-1. Resist collisions<br />(attacker controls both inputs)
+<section>
+    <p class="fragment">Accept unbounded size input</p>
+    <p class="fragment">Map to a bounded output</p>
+    <p class="fragment">Be fast to compute</p>
+    <p class="fragment">Be computable strictly one-way<br />(difficult to find a pre-image for a hash)</p>
+    <p class="fragment">Resist pre-image attacks<br />(attacker controls one input)</p>
+    <p class="fragment">Second pre-image resistance: Given an input and output<br />(resisting second pre-image attacks).</p>
+    <p class="fragment">Resist collisions<br />(attacker controls both inputs)</p>
+</section>
 
 </pba-flex>
 
@@ -266,9 +269,11 @@ e.g., a 256 bit hash output yields 2^128 security
 
 It should be difficult for someone to partially (for a substring of the hash output) find a collision or "second" pre-image.
 
-- Bitcoin PoW is a partial pre-image attack.
-- Prefix/suffix pre-image attack resistance reduces opportunity for UI attacks for address spoofing.
-- Prefix collision resistance important to rationalize costs for some cryptographic data structures.
+<section>
+    <p class="fragment">Bitcoin PoW is a partial pre-image attack.</p>
+    <p class="fragment">Prefix/suffix pre-image attack resistance reduces opportunity for UI attacks for address spoofing.</p>
+    <p class="fragment">Prefix collision resistance important to rationalize costs for some cryptographic data structures.</p>
+</section>
 
 ---