diff --git a/syllabus/1-Cryptography/5-Basic_Signatures-slides.md b/syllabus/1-Cryptography/5-Basic_Signatures-slides.md
index e07cae6fc..91e1aeaa5 100644
--- a/syllabus/1-Cryptography/5-Basic_Signatures-slides.md
+++ b/syllabus/1-Cryptography/5-Basic_Signatures-slides.md
@@ -46,9 +46,9 @@ See the Jupyter notebook and/or HackMD cheat sheet for this lesson.
## Hash Functions
-There are two lessons dedicated to hash functions.
But they are used as part of all signing processes.
+There are two lessons dedicated to hash functions.
But they are used as part of all signing processes.
-For now, we only concern ourselves with using Blake2.
+For now, we only concern ourselves with using Blake2.
---
@@ -58,12 +58,11 @@ As mentioned in the introduction,
it's often more practical to sign the has
Therefore, the sign/verify API may be _used_ like:
-
+- `fn sign(sk, H(msg)) -> signature;`
+- `fn verify(pk, H(msg), signature) -> bool;`
-- `fn sign(sk, H(msg)) -> signature;`
-- `fn verify(pk, H(msg), signature) -> bool;`
-
+Notes:
Where `H` is a hash function (for our purposes, Blake2).
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.
The receiver will carry out the instructions since the message contains a valid signature.
-
-
-- Since we assume that channels are insecure, all messages should be considered intercepted.
-- The "receiver", for blockchain purposes, is actually an automated system.
-
+- Since we assume that channels are insecure, all messages should be considered intercepted.
+- The "receiver", for blockchain purposes, is actually an automated system.
Notes:
diff --git a/syllabus/1-Cryptography/7-Hash_Based_Data_Structures-slides.md b/syllabus/1-Cryptography/7-Hash_Based_Data_Structures-slides.md
index 4b96410d3..d73ce4566 100644
--- a/syllabus/1-Cryptography/7-Hash_Based_Data_Structures-slides.md
+++ b/syllabus/1-Cryptography/7-Hash_Based_Data_Structures-slides.md
@@ -10,9 +10,13 @@ duration: 1 hour
## Comparison to
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
+- A pointer tells you where to find it
+- We can not have cycles of hashes.
+
+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,
+- 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.
+
+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.
+- For storage, it is best to read consecutive data so high $r$ is better.
+
+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!!
+
---