Deploying to gh-pages from @ d20391b 🚀

syllabus/1-Cryptography/2-Addresses-slides.html

@@ -113,12 +113,18 @@
 
 </pba-col>
 </pba-cols>
-</script></section><section  data-markdown><script type="text/template">
+
+
+<aside class="notes"><p>Question to ask:
+Does anyone know what a BIP is?</p>
+</aside></script></section><section  data-markdown><script type="text/template">
 ## Mnemonic to Secret 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.
+For the Math peoples, what is a secret key?<!-- .element: class="fragment" data-fragment-index="0" -->
+
+The secret key is a scalar value from the scalar field of the base field from which an elliptic curve is defined over. Not a phrase! <!-- .element: class="fragment" data-fragment-index="1" -->
 
-BIP39 applies 2,048 rounds of the SHA-512 hash function<br /> to the mnemonic to derive a 64 byte key.
+BIP39 applies 2,048 rounds of the SHA-512 hash function<br /> to the mnemonic to derive a 64 byte key.<!-- .element: class="fragment" data-fragment-index="2" -->
 </script></section><section  data-markdown><script type="text/template">
 ## Portability
 
@@ -164,6 +170,8 @@
 ```
 
 <aside class="notes"><p>It hasn&#39;t been covered yet, but some addresses even go <em>extra fancy</em> and include an error correcting code in the address.</p>
+<p>Question for class:
+What is a checksum?</p>
 </aside></script></section><section  data-markdown><script type="text/template">
 ## SS58 Address Format
 
@@ -199,12 +207,16 @@
 </script></section><section  data-markdown><script type="text/template">
 ## Hard Derivation
 
-Hard derivation requires the secret key and derives new child secret keys.
 
-Typical "operational security" usages should favor hard derivation over soft derivation because hard derivations avoid leaking the sibling keys, unless the original secret is compromised.
+Hard derivation requires the secret key and derives new child secret keys.<!-- .element: class="fragment" data-fragment-index="0" -->
 
-Always do hard paths first, then conclude in soft paths.
-</script></section><section  data-markdown><script type="text/template">
+Always do hard paths first, then conclude in soft paths.<!-- .element: class="fragment" data-fragment-index="1" -->
+
+<aside class="notes"><p>Typical &quot;operational security&quot; usages should favor hard derivation over soft derivation because hard derivations avoid leaking the sibling keys, unless the original secret is compromised.</p>
+<pre><code>DONT MENTION THIS BUT FOR NOTES!!
+- Because you cannot derive a parent key from a child key with hard derivation but with soft you can
+</code></pre>
+</aside></script></section><section  data-markdown><script type="text/template">
 ## Hard Derivation in Wallets
 
 Wallets can derive keys for use in different consensus systems while only needing to back up one secret plus a pattern for child derivation.
@@ -225,6 +237,10 @@
 
 <aside class="notes"><p>Hard keys: Take a <em>path</em> (data like a name/index), concatenate with the original key, and hash it for a new key.
 They reveal nothing about keys above them, and only with the <em>path</em> between it and children could they be recovered.</p>
+<ul>
+<li>use <code>sha3sum -N 256</code> for a 32byte output and hash type in two things and press ctrl D</li>
+<li>use inspect on the two private keys see that they are completely different public keys non-linkable</li>
+</ul>
 </aside></script></section><section  data-markdown><script type="text/template">
 ## Soft Derivation
 
@@ -239,7 +255,6 @@
 ## Soft Derivation
 
 - Note that these generate new addresses, but use the same secret seed.
-- We can also use the same paths, but only using the Account ID from `//polkadot`. It generates the same addresses!
 </script></section><section  data-markdown><script type="text/template">
 ## Soft Derivation in Wallets