additional pre crypto slides

syllabus/1-Cryptography/5-Basic_Signatures-slides.md

@@ -58,12 +58,11 @@ As mentioned in the introduction,<br />it's often more practical to sign the has
 
 Therefore, the sign/verify API may be _used_ like:
 
-<pba-flex center>
-
 - `fn sign(sk, H(msg)) -> signature;` <!-- .element: class="fragment" data-fragment-index="0" -->
 - `fn verify(pk, H(msg), signature) -> bool;` <!-- .element: class="fragment" data-fragment-index="1" -->
 
-</pba-flex>
+
+Notes:
 
 Where `H` is a hash function (for our purposes, Blake2).<br />
 This means the verifier will need to run the correct hash function on the message.
@@ -83,7 +82,12 @@ Signatures provide many useful properties:
 
 Notes:
 
-If a hash is signed, you can prove a signature is valid _without_ telling anyone the actual message that was signed, just the hash.
+Question what do each of these mean?
+
+- Confidentiality - If a hash is signed, you can prove a signature is valid _without_ telling anyone the actual message that was signed, just the hash.
+- Authenticity: Authenticity assures that the data comes from a verified source.
+- Integrity assures that the data has not been changed in an unauthorized manner.
+- Non-Repudiation provides evidence that can be used to prove the involvement of parties in a communication, preventing them from denying their actions.
 
 ---
 
@@ -118,12 +122,9 @@ Note that signing and encryption are _not_ inverses.
 Replay attacks occur when someone intercepts and resends a valid message.<br />
 The receiver will carry out the instructions since the message contains a valid signature.
 
-<pba-flex center>
-
-- Since we assume that channels are insecure, all messages should be considered intercepted.
-- The "receiver", for blockchain purposes, is actually an automated system.
 
-</pba-flex>
+- Since we assume that channels are insecure, all messages should be considered intercepted. <!-- .element: class="fragment" data-fragment-index="0" -->
+- The "receiver", for blockchain purposes, is actually an automated system. <!-- .element: class="fragment" data-fragment-index="1" -->
 
 Notes:
 

syllabus/1-Cryptography/7-Hash_Based_Data_Structures-slides.md

@@ -10,9 +10,13 @@ duration: 1 hour
 
 ## Comparison to<br />Pointer Based Data Structures
 
-- A hash references the _content_ of some data;
-- A pointer tells you where to find it;
-- We can not have cycles of hashes.
+- A hash references the content of some data <!-- .element: class="fragment" data-fragment-index="0" -->
+- A pointer tells you where to find it <!-- .element: class="fragment" data-fragment-index="1" -->
+- We can not have cycles of hashes. <!-- .element: class="fragment" data-fragment-index="2" -->
+
+Notes:
+ - Q: point 3 why cant we have a cycle of hashes?
+ - Answer: Properties of the hash function as long as we hash different stuff we will always reference something specific and different.
 
 ---
 
@@ -64,6 +68,7 @@ Collision resistance: we reasonably assume only one preimage for each hash,<br /
 
 Notes:
 
+What could happen if the hash function breaks in this structure?
 Explain what could happen when this fails.
 
 ---
@@ -172,10 +177,14 @@ Additionally, if the size of a value is particularly large, it is replaced with
 
 ## Hash Trie
 
-- Inserting arbitrary (or worse, user-determined) keys into the Patricia tree can lead to highly unbalanced branches, enlarging proof-sizes and lookup times.
-- Solution: pre-hash the data before inserting it to make keys random.
-- _Resistance against partial collision is important._
-- Could be a Merkle trie or regular.
+- Inserting arbitrary (or worse, user-determined) keys into the Patricia tree can lead to highly unbalanced branches, enlarging proof-sizes and lookup times.<!-- .element: class="fragment" data-fragment-index="1" -->
+- Solution: pre-hash the data before inserting it to make keys random.<!-- .element: class="fragment" data-fragment-index="2" -->
+- Resistance against partial collision is important.<!-- .element: class="fragment" data-fragment-index="3" -->
+- Could be a Merkle trie or regular.<!-- .element: class="fragment" data-fragment-index="4" -->
+
+Notes:
+- Q: Why would pre-hashing the data make the keys random? A: Because each piece of data should be unique! it is a good selection scheme.
+    Talk about how to determine keys in bitcoin state tree
 
 ---
 
@@ -188,8 +197,12 @@ What radix $r$ is best?
 
 ...but:
 
-- Higher branching at high levels of the tree can give smaller batch proofs.
-- For storage, it is best to read consecutive data so high $r$ is better.
+- Higher branching at high levels of the tree can give smaller batch proofs. <!-- .element: class="fragment" data-fragment-index="0" -->
+- For storage, it is best to read consecutive data so high $r$ is better. <!-- .element: class="fragment" data-fragment-index="1" -->
+
+Notes:
+Q: Why would higher branching at high levels of the tree give smaller batch proofs?
+A: Less nodes are needed in order to prove various parts of the tree
 
 ---
 
@@ -227,6 +240,14 @@ Notes:
 - Not as balanced as a binary tree but close
 - Can update the peak nodes alone on-chain
 
+
+Applications:
+
+- Stateless Client can very efficiently prove the end parts of the tree allowing for a client which doesnt need to store the whole blockchain just a few latest nodes. 
+- Look at the structure if each leaf is a block then if previous stuff is pruned that is fine because you still carry around the hash or peak of a selection of blocks
+- Lightclients, efficiently see whether a transaction is included in a block without needing the entire the entire blockchain history 
+    We use this in polkadot for our bridging!!
+
 ---
 
 <!-- .slide: data-background-color="#4A2439" -->